2023 Agile Kaohsiung 3月聚會：探索與交付之間的愛恨糾葛
•
0 likes•33 views
使用敏捷開發方法的目的是為了做出有價值的產品，然而，在實際產品開發流程中，很容易忽略花在產品探索（Discovery）與交付（Delivery）的比例分別佔了多少？這樣的比重分配對於產品發展過程是如何造成影響？身為一個產品開發與管理人員，又該如何辨識與調整工作內容中屬於探索與交付的部份？ 對於參與這場分享的你而言，可以建立對於產品探索與產品交付的基本瞭解，藉此作為安排開發工作分配的一個檢視面向。 若你的角色即是產品負責人，或是產品經理、專案經理、開發團隊人員或主管等在工作中會對產品開發流程造成影響的人，也可參考此分享內容，試著思考自身與團隊在探索與交付兩方面分別做了哪些事情？為什麼要做這些事？有沒有偏重或忽略了其中一方？造成哪些問題？以及如何改善這些狀況？
Recommended
More Related Content
Similar to 2023 Agile Kaohsiung 3月聚會：探索與交付之間的愛恨糾葛
Similar to 2023 Agile Kaohsiung 3月聚會：探索與交付之間的愛恨糾葛 (20)
More from Jenson Lee
2023 Agile Kaohsiung 3月聚會：探索與交付之間的愛恨糾葛
- 1. 產品探索與交付 一種基於假設與價值導向的產品思維 Jenson Lee @ Agile Kaohsiung 2023.3.31
- 2. 高雄敏捷社群（AGILE KAOHSIUNG） 高雄敏捷社群是由一群在地的敏捷實踐者所組成，期待藉由 經驗分享和技術交流，促進高雄與周圍地區的產業進化。 南台灣最大敏捷社群 透過敏捷改變高雄及南部地區的產業文化 平衡南北資訊落差與社群交流活動不均的情況
- 4. 關於台灣敏捷協會 ● 協助台灣各大企業進行敏捷變革轉型 ● 主辦 第一屆 ACT 台灣敏捷大賞 2022 ● 主辦 Agile Summit 台灣敏捷高峰會 2022 ● 主辦 Regional Scrum Gathering (RSG) Taipei 2021 ● 主辦 Agile Tour Taipei / Hsinchu / Taichung / Kaohsiung 敏捷之旅 台北/ 新竹/台中/高雄 2018/2019/2020
- 5. Jenson Lee Agile Product Coach 電商 / 平台 / 交通 / 行動應用 / 安控 / 人資 CSM / CSPO 台灣敏捷協會理事 台北/高雄敏捷社群志工
- 10. 決定要建構什麼 Build the right thing 把東西建構出來 Build the thing right 探索 交付
- 11. 如何決定建構什麼？
- 12. 如何交付？
- 13. SCRUM GUIDE 裡對於 PO 的定義 Product Owner 負責將把 Scrum Team 的工作所打造出來的產品價值最大化。 如何做到這一點可能 會依組織、Scrum Teams 和個人的不同而有極大的差異。 Product Owner 也負責對 Product Backlog 進行有效的管理，包括: ● 開發並明確的描述溝通 Product Goal; ● 創造並清楚的描述溝通 Product Backlog items; ● 對 Product Backlog items 進行排序;和， ● 確保 Product Backlog 是透明的、可見的與可理解的。
- 14. SCRUM 沒有告訴我的事 身為一個 Product Owner，我需要排序 Product Backlog Items，但我要怎麼決定呢？ 使用者是誰？ 他們的問題是什麼？ 開發哪些功能可以帶來最大價值？ 如何在產品開發流程中獲得這些資訊？
- 15. 產品風險 Value 價值風險：會有人想用嗎？ Usability 使用風險：顧客知道怎麼用嗎？ Feasibility 建構風險：團隊可以打造出來嗎？ Viability 市場風險：可以帶來商業價值嗎？ Source:《產品專案管理全書》by Marty Cagan
- 16. 探索 交付
- 17. 探索 交付 界定問題
- 18. 界定問題 解決什麼問題？ 哪些人有這個問題？ 他現在怎麼應對這問題？ 你的產品或服務如何幫助他解決這個問題？ 這個問題需要被解決嗎？ 相關活動 To B To C 人物誌 Persona △ O 同理心地圖 Empathy Map △ O 用戶旅程地圖 Customer Journey Maps △ O 競品研究 O O 產品和服務的起源通常都是為了解決一個問題，進而創造出行為上的改變。因此， 設定目標對象（Target Audience）或做出客戶區隔，了解他們既有或可能會有的 問題，以及解決這個問題之後會達到怎樣的目標，就是對於產品最初的思考方向。
- 19. 探索 交付 提出假設
- 20. 提出假設 可能的解決方案是什麼？ 機會與成本？ 如何及要花多久時間驗證？ 相關活動 To B To C 影響地圖 Impact Mapping O O 商業畫布 Business Canvas O O 決策樹 Decision Trees O O 五個為什麼 5 Whys O 利害關係人地圖 O △ 根據對於問題的理解與想像對應而提出的想法，必須將其視為一種假設。基於蒐集 而來的資訊、對於市場和領域知識的理解、以及組織與產品想要達到的目標，提出 一套解決方案，並對應於此方案設定驗證的方式。
- 21. 探索 交付 打造原型
- 22. 打造原型 我們最擔心、最需要被驗證的 風險是什麼？ 如何驗證？ 如何打造最小可測試原型？ Minimum Viable Prototype 相關活動 To B To C 可用性測試 Usability Test △ O 設計衝刺 Design Sprint O O Mechanical Turk △ O 對於解決方案初步打造原型，目的是產生討論、回饋與提供可用來測試的工具。這 個階段的產出物應該是在考量目標、資源、價值與風險的前提下，能夠最有效率進 行驗證的「最小可測試原型」（Minimum Viable Prototype）
- 23. 探索 交付 選擇方案
- 24. 選擇方案 為什麼要選擇這個方案？ 符合我們的目標嗎？ 最小可行 / 可驗證市場產品是什麼？ Minimum Viable Product 相關活動 To B To C 使用者故事對照 User Story Mapping △ O 精鍊會議 Refinement Meeting O O 事件風暴 Event Storming O O 根據探索過程獲得的知識與資訊，並考量組織目標、價值與所能帶來的影響等綜合 評估後，選擇與排序進到開發流程的項目。同時也在選擇與排序的過程中評估所需 花費的資源，以及與相關單位產生討論與對話，藉此創造共識與對齊目標。
- 25. 探索 交付 建構產品
- 26. 建構產品 如何建構正確的產品 / 功能？ 建構的最主要挑戰是什麼？ 如何確保產品的品質？ 相關活動 To B To C 每日站立會議 Daily Scrum O O 自動化測試 Test Automation O O 持續整合 / 持續交付 CI / CD O O 在決定待開發的項目內容、以及開發團隊對於項目有理解與共識後，對待開發的內 容進行分析、設計、實作、測試與佈署。在敏捷的框架中，這個過程應該要是持續 迭代與交付有價值的，並兼具品質、可維護與可擴充的產出物。
- 27. 探索 交付 蒐集回饋
- 28. 蒐集回饋 蒐集到的回饋符合我們的假設嗎？ 這些資料如何幫助我們改善？ 下一步是什麼？ 相關活動 To B To C 數據追蹤與分析 O O 問卷調查 O 淨推薦指數 Net Promoter Score O O 在交付產品、服務或功能到市場 / 客戶 / 使用者手上之後，對於可觀測與主動 / 被 動蒐集到的資料進行分析和解讀，作為驗證假設與衡量價值的指標，並提供組織與 團隊進行下一步行動所需的資訊。
- 30. 探索 交付 蒐集 回饋 建構 產品 選擇 方案 打造 原型 提出 假設 界定 問題 階段 定義 界定 問題 設定目標對象或做出客戶區隔，了解他們既有或可能會 有的問題，以及解決這個問題之後會達到怎樣的目標。 提出 假設 將對應問題提出的解決方案視為一種假設，並對應於此 方案設定驗證的方式。 打造 原型 在考量目標與資源後，打造為了產生討論與回饋的最小 可測試產品原型（Min Testable Prototype）。 選擇 方案 對組織目標、價值與所能帶來的影響做出綜合評估，根 據測試結果、選擇與排序進到開發流程的項目。 建構 產品 對待開發項目進行分析、設計、實作、測試與佈署，持 續迭代與交付有價值、品質、可維護與可擴充的產出物。 蒐集 回饋 分析和解讀產品數據，作為驗證假設與衡量價值的指標， 並提供組織與團隊下一步行動所需的資訊。
- 31. 應對產品風險 價值風險：會有人想用嗎？ 使用風險：顧客知道怎麼用嗎？ 建構風險：團隊可以打造出來嗎？ 市場風險：可以帶來商業價值嗎？ 「界定問題」 「打造原型」 「建構產品」 「蒐集回饋」
- 32. 排序 PRODUCT BACKLOG ITEMS 產品最主要想解決、也是使用者最在意的問題是什麼？ 能夠帶來最大商業價值、同時也最需要驗證的假設是什麼？ 經過原型驗證、最明確清晰可加進產品裡的功能是什麼？ 技術與架構上的挑戰、最需要被克服的建構風險是什麼？ 根據數據與市場回饋、最能幫助我們邁向目標的利基點是什麼？
- 34. 使命 願景 價值觀
- 35. 使命 Mission = what, how, why & for whom 我們專注的事情是什麼？（我們不做什麼？） 願景 Vision = where 我們要去哪裡？⽬標是什麼？ 價值觀 Values = the set of beliefs and principles that guide our way to the goal 指引我們前往⽬標的共同信念與原則 As-Is To-Be 現況 ⽬標
- 36. APPLE 使命 Mission 藉由創新的硬體、軟體與服務，帶給客戶最佳的使用者體驗。 To bringing the best user experience to its customers through its innovative hardware, software, and services. 願景 Vision 我們創造這世界上最佳的產品，這件事永遠不會改變。 We believe that we are on the face of the earth to make great products and that’s not changing. 核心價值觀 Core Values 包容與多元 Inclusion and Diversity 教育 Education 無障礙使用 Accessibility 環境 Environment 供應商責任 Supplier Responsibility 隱私與安全 Privacy and Security
- 37. NIKE 使命 Mission 竭盡所能地提昇人類潛能 Do everything possible to expand human potential. 願景 Vision 為世上所有運動員帶來鼓舞與創新 To bring inspiration and innovation to every athlete in the world. 價值觀 Values 激勵 Inspiration 創新 Innovation 每個運動員 Every athlete in the world 真實 Authentic 連結 Connected 與眾不同 Distinctive
- 39. 使命 願景 價值觀
- 40. 使命 願景 價值觀 北極星指標
- 41. 產品指標 / 北極星指標 Source: 產品指標框架使用方法 by Peter Su
- 42. 北極星指標 使命 願景 價值觀
- 43. 探索與交付不平衡的一些跡象 n 功能蔓延（feature creep），各單位不斷提出需求，很難說出 “No” n 工作內容和目標（goals / KPI）無關，或是根本不知道目標… n 每天都被無止盡的會議佔滿，沒有足夠時間深入思考 n PM 被開發團隊追著跑，得要不斷產出 user story / task 來讓 RD 有事情做 n 無法交付有品質的產品 n 無法交付能產生價值的產品
- 44. 探索 交付 太多探索、太少交付 §無法有效創造價值 / 沒賺錢 §活在空中樓閣（castle in the air），逐 漸失去動力 §紙上談兵，無法驗證概念是否可行 §缺乏對於商業模式高風險部分的檢驗 §對於市場反應的經驗不足 太多交付、太少探索 §團隊不知道開發產品 / 功能的原因 §即使做出來的東西看起來不錯，但結 果不如預期 §和市場與使用者漸行漸遠 §會產生很多開發資源的浪費 §產品毛利下降
- 49. PROBLEM SPACE VS. SOLUTION SPACE 問題空間：透過產品去滿足的使用者需求 方案空間：開發出來的產品 >>>>>> 產品探索 >>>>>> 產品交付 Source:《The Lean Product Playbook》by Dan Olsen
- 53. 藉由 探索 最大化價值，而不是以 交付 提昇產出 Source: Henrik Kniberg
- 56. 建立持續探索與 持續交付的流程 開始進行探索， 而不是找到 最正確的方案 探索與交付都是 團隊一起的工作 最後的一些提醒 Continuous Discovery and Delivery Start to Discover Teamwork
- 57. Creator of Lean Canvas & Author of Running Lean《精實執行》