ProductTank Taipei #10 筆記：敏捷開發與轉型（上）

這次的 ProductTank Taipei 主題為「敏捷開發與轉型」，由 Gogolook 負責 Whoscall 的資深產品經理 張仕杰，以及 91APP 負責 CRM 解決方案相關的資深產品經理 葉力維，分享在各企業中推動敏捷開發的心路歷程，並不藏私的分享其中的訣竅。

ProductTank Taipei #10 2018 July@Pic collage

（在開始前想先說聲：因為本人不是專業的 PM ，以下內容若有誤植，可能在理解過程中有落差，請多見諒。歡迎留言糾錯，期待未來可以越來越好，謝謝！）

張仕杰：「以 PM 角度來看轉型 Agile 的歷程，與那些踩過的坑」

張仕杰分為兩大面向，分享在 Gogolook 改善開發流程過程的兩大面向，第一為「Agile 運行的詳細旅程」第二則為「想推動 Agile 的 PM 該注意什麼」。

Agile 運行的詳細旅程

Gogolook 在使用 Agile 進行開發流程改革，嘗試過 Kanban、Scrum、Sprint、Impact Mapping 等方式，共經歷 2 年的時間。大致可以分為以下四個步驟：

1.凝結共識：點出問題

邀請 team member 說出目前有什麼問題，了解組織可以怎麼去改進。當進行討論時，對改進的目標有共識，之後討論解決方式也會更關注。（第二位分享者葉力維，也特別提及此共識建立的重要性。）

當時便發現主要的兩個問題為「時程延誤」、「需求不定時提出」造成團隊在開發上無法順利推進。

2.使用 Kanban：讓項目透明

理解團隊問題後，張仕杰開始帶動團隊使用 Kanban 此工具，幫助 team member 可以明確地看到現在插單的狀況、每位夥伴現在手上的 task 有哪些。

在 Kanban 的使用上，該團隊透過不同顏色的 post it 來區別 task 的狀況，例如紅色為插單，各方格以人為區隔，所以當「紅色 」、或是「某一格（人）」的 post it 明顯很多，就可以知道大概是有問題了，這時便需要即時資源的調配與問題解決。

但 Kanban 有一個缺點就是，沒有時間感。在不斷產生以及走流程的過程中，team member 可能會有一種看不到盡頭感，或是不知道何時該推進感。

3.轉型使用 Scrum：聚焦目標

在發現 Kanban 較無時間感的缺點後，開始使用 Scrum，進行兩週的 sprint 開發。他分享將「Task 變成 User Story」的三大重點分別為

• 溝通使用者價值：身為一個特定角色，他想要特定功能，來完成特定事情會是什麼？
• 開發的商業價值：story 有沒有辦法解決他的問題？（重點不是技術或是細節，而是問題的解決與否）是否為最有效的作法？
• 成果驗收的標準：如何評斷問題是否解決？

4.使用 Impact Mapping (reference）

在 Scrum 的進行中，團隊發現一個新的問題，在不斷 sprint 的奔跑過程中，好像不太知道奔跑的盡頭，以及整體跑步的路線，到底是什麼。因此就有了目前運行較為適用的 Impact mapping，透過 Why Who How What 進行開發的路徑優先順序的評估。

四個類別概述如下：

• why：目標為何？（商業價值是什麼？）
• who：誰來做這件事情？
• how：如何達成這件事情？（who 可以怎麼影響 why 的達成）
• what：該用哪些步驟/行動來達成？

張仕杰實際運行以終為始，展開 Impact map的步驟為：

1. 每一季一開始，先確認溝通目標—— Impact map 的長相為何
2. 進行路徑的優先順序排列（評斷標準：目標效益、成本大小、阻礙多寡等）
3. 使用 sprint 去開發 map 中的「what」（行動）
4. 使用季度一開始的假設，去驗證最後的實際產出，評斷是否 impact 和當初 map 規劃相同

透過 Impact mapping 團隊有在開發上明顯的準時許多，速度也加快，可以即時知道是否有解決使用者的需求，快速去做調整。

想推動 Agile 的 PM 該注意什麼

關於 Agile 的推動，張仕杰進一步分享自己身為 PM 在其中六個學習，以及小技巧們。

1. 假設與驗證的過程很重要：建議可以使用「產品路線圖 > sprint 行動執行> 驗證假設」三階段的方式，去評估目標是否達成，去思考路徑策略並評估哪一種路徑最容易成功。
2. 安排你的 release plan：張仕杰提供五種優先排序的方式供參考
3. A. 使用 impact map 的優先順序往回逆推
4. B. 先考量最有效益的 story
5. C. 用發佈時間點來排序
6. D. 思考需要的資源、是否需要進行研究與實驗（建議實驗可以放在最前面做）
7. E. 張仕杰自己的小技巧，定義 Story 類別以及該採取的行動
8.  a. Product：規格明確，有直接 impact 結果 > 直接做
9.  b. Infra：基礎設施 > 是一種未來的投資
10.  c. Bug ：明顯錯誤 > 需要修復
11.  d. Study：價值有，但還不明確 > 用有效的方法驗證（e.g. A/B Test, User Research, POC 等）
12. 向上管理：主動和上級說明產品路線，並確認插件的價值是什麼
13. 有效率的溝通：有效率的開會、文件要清楚（e.g. spec）、使用同一套的溝通架構不斷精進（張仕杰的溝通架構：溝通結果 > 現況 > 作法 > 誰做、何時做）
14. 多費心在自省會議（retrospective）：建議觀察一開始不順利的東西，那多是最嚴重的問題、最需要解決。每次 retro 後可以挑一個 task 去改進，重點要讓參與者感到每次都有在改進。同時，retro 你的 retro也會是很關鍵，例如：為什麼有人不提建議等。
15. 採用敏捷前，先問自己「要解決什麼問題」：先從瓶頸開始，找出問題。

最後張仕杰也分享，有各種方式可以達到敏捷開發的效果，最重要的是從公司的策略去找到最適合的方式。

第一次寫 PM 相關的學習，若有解讀錯誤以及撰寫錯誤請多指教，下半場「我的 91 app 敏捷修羅道」也歡迎閱讀，謝謝！