ProductTank Taipei #10 筆記:敏捷開發與轉型(上)

Tin
·
·
IPFS
·
由 Gogolook 負責 Whoscall 的資深產品經理 張仕杰,以及 91APP 負責 CRM 解決方案相關的資深產品經理 葉力維,分享在各企業中推動敏捷開發的心路歷程,並不藏私的分享其中的訣竅。

這次的 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 敏捷修羅道」也歡迎閱讀,謝謝!

CC BY-NC-ND 2.0 授权

喜欢我的作品吗?别忘了给予支持与赞赏,让我知道在创作的路上有你陪伴,一起延续这份热忱!