ProductTank Taipei #10 - 敏捷轉型：找到團隊的敏捷之道
張士杰 Gogolook 資深產品經理
以 PM 角度來看轉型 Agile 的歷程，與那些踩過的坑
開會晚了遲到些覺得懊惱，聽 Sharon 說才剛開場，錯過不多，坐下時正聽到士杰講述團隊由 Kanban 轉型到 Scrum 的困境，原本插單開發的任務追蹤導向專案做法，無法加入時間軸的概念，對團隊成員來說無緊迫感或目標性，且僅透過看板任務追蹤，無法看到願景、設計故事的全貌，導致團隊目標喪失。
從 Task 到 User story
User story 用以溝通使用者價值／商業價值，以及驗收標準。在討論跟選擇 Story 時，著重使用者的問題解決，而非僅僅專注在技術細節或功能上。要謹記「使用者的目的是什麼？他要解決的問題是什麼？」而拆解跟執行 Story 時，根據目的，討論有效率且有效的做法，盡快到達目的的節點，若僅需要 task 1，就要省去不必要的 task 2。且在定義 user story 時要謹慎，以產品核心價值為導向，環繞策略設計 story，而非漫天發想，會造成產品定位不清，且設計定位不明的後果。進一步定義產品策略：
- Why - 商業價值為何？
- Who - 誰可以協助完成此商業價值？
- How - 有如何完成這個商業價值？
- What - 這些步驟要用什麼方法執行/完成？
透過此架構，可以讓 user story 對應到實際的目標，「以終為始」，每個 sprint 透過 impact map 驅動。而每一季都與 stakeholder 溝通目標，並與團隊一起打造 impact mapping，排出任務目標的優先順序，找出對目標效益大、成本小的任務，並釐清哪些角色可以幫助專案？哪些角色會阻撓專案並進而排除？讓團隊清楚專案與產品脈絡。
Impact map makes your product assumptions visible (and testable).
每個 sprint 需要透過檢驗，若找到目標達成率較高的 sprint，就要果斷確認投入方向，以取得最大效益的成果。在 Gogolook，開發流程的轉型花費了兩年，但確保團隊慢慢進步，往目標邁進。
不要用戰術上的勤勞，去掩蓋戰略上的懶惰
透過思考全局的路線圖，訂定目標與進攻策略，找到最容易成功的路！並妥善安排 Release plan，根據 impact map 路徑的優先順序往回逆推，先考量最有效益的 story，再排序發布時間點，同時審視既有資源。
定義不同類型的 Story，有效運用有限時間與資源：
- Product - 規格明確，直接 impact 結果，直接投入
- Infra - 產品基礎設施，是未來投資
- Bug - 明顯錯誤，需要修復
- Study - 有價值，但不明確，需使用有效方法驗證
- A/B testing
- User research / Interview / Kano
- POC (Proof of Concept), 技術可行性驗證
向上管理軟實力
- 主動溝通目標與產品路線圖，而非上對下接單
- 主動溝通下一個 sprint 的優先順序，而非討論何時做完
- 要插單，先比較價值定義
有效溝通軟技能
- 有效率的開會
- 清楚的文件和 spec
- 解決方案的溝通，目標結果 > 現況 > 做法 > 資源分配 > 時程
Retrospective meeting 很重要！
流程改變不會一蹴可幾，要有耐心，讓子彈飛一會兒（這是我個人也很愛的一個小心法）。進步來自於紮實的自省與改善執行，磨合過程中一定會遇到衝突，但只要對事不對人，就可以專注在問題解決上，「PM 被打臉是信任的表現」，愛之深，才會責之切。
採用敏捷前，要先釐清「要解決什麼問題？」，如此才能從瓶頸下手，精確解決問題，方法都是工具，不要把手段（導入流程）當成目的，並關注團隊的回饋進行調整，記得隨時回頭看看自己是否與公司策略、產品策略同調。
士杰的敏捷書單分享：
- 《Impact Mapping》
- 《看板實戰 Kanban》
- 《讓我們一起做決定？》
- 《Product Roadmaps 》
葉力維 91APP 資深產品經理
我的 91APP 敏捷修羅道
91APP 提供 B2B2C 的解決方案，由於業務牽涉到線上線下的串聯，因此產品任務週期迭代快速，在敏捷的推廣上一直都不遺餘力，且從最高主管 top-down，調整全公司團隊思維，由上而下推廣敏捷流程。
葉力維說：「我其實不是敏捷專家，我是被敏捷專家。」身為 91APP 第一批導入敏捷流程的「白老鼠」，他要跟大家分享這些年「活下來」的心路歷程。
加不加班與敏捷無關，只跟所處的公司、產業競爭樣態以及每個人對於公司的投入程度有關
- 葉力維
- 敏捷不是跑百米賽跑，是馬拉松！by 91APP 敏捷教練
- 跑敏捷不會從此幸福美滿，但是更可能完成目標
- 敏捷是種心態，跑敏捷不等於變快，但是可以透過縮短開發迭代週期來加速產品交付
- 由下而上的敏捷不容易成功，除了敏捷方法外，組織、產品架構、技術架構，甚至獎勵、升遷都應該有相對應的配套
Sprint 0 - 91APP 的困境與變革
91APP 在 2016 年經歷了高速的公司規模與業績成長，逐漸出現困境，包含：市場的需求太多太快、純電商遇到成長天花板。而在原本的 waterfall 專案流程，導致專案迭代緩慢，每個需求的變更都勞師動眾，產品端與研發端的諜對諜，讓時間在討價還價中流逝。
為了及早治療，91APP 找了一小群人組成「跨職能團隊」，維持團隊在同一個地點工作，並授權團隊單獨完成任務，找彼此有信任基礎的成員形成團隊，降低摩擦造成的成本或傷害，並想辦法透過外訓或小任務成就，凝聚團隊意識。
Sprint 1 一個敏捷各自解讀
敏捷的起手式，便是「讓團隊的工作透明」，但透明說來簡單，做起來很難。力維建議「看板是讓團隊工作透明化的最佳工具」，且看板要能動態隨工作流程變化，每張貼紙 (Job / User story) 都要明確定義 DoD (Definition of Done)
推薦閱讀：Ruddy 老師的部落格_看板方法入門
而 91APP 在起手式遇到的困境，則是：
- 人人有看書，解讀各不同
- 大家都想追求共識，但主管各下指導棋
- 沒有共識，就更容易有摩擦
- 團隊容易被各種鳥事擊破
Sprint 2 讓專業的來
91APP 為了展現自己的決心，於是聘請人資長周旺敦，旺哥有非常深厚的 RD 背景，對 RD 有一定的說服力，且所站位置有一定的高度和份量，因此對敏捷流程的導入起了決定性的作用，因為「敏捷會失敗，通常是主管不夠敏捷」。
如果我們想不到其他更好的方法，那就先認真徹底地把敏捷玩過一遍
- 旺哥聘請 Scrum Master (Aglie Coach)，讓團隊分工更明確，步驟清楚。有敏捷專家在團隊的好處，是提供成員全面且一致的敏捷課程，並拉齊團隊的敏捷知識水平，讓大家在同一頁上，對方法有較相近的解讀，不再各自詮釋，浪費溝通成本。
Sprint 3 團隊重組
2017 年底，在第一個跨職能團隊 (CRM team) 展現出不錯的成效後，91APP 將 150 人的產品研發團隊重組為 8 條產品線以及 1 個維運團隊 (CRM、官網、APP、導流、金物流、大馬、ERP、OSM)。
在辦公室內，每個團隊都有自己的白板，用看板方法來管理工作與討論工作，做 user story mapping，而白板更讓站立會議更加聚焦，同時讓進度、瓶頸一目了然，例如：在同一條路上有一堆貼紙，一定有問題！
工具上，導入微軟的敏捷管理工具 VSTS，協助團隊更快地管理 PBI，更方便地視覺化和量化管理。但不論工具或團隊組成規模，都須要推廣各團隊間敏捷知識的經驗傳承與分享，透過這些分享和幹譙，可以讓團隊成員截長補短，更試著正面思考，扶持前進。
Sprint 4 91APP 的 Aglie Way
- Aglie 分支很多，重點不是 Scrum 而是 Aglie，從此沒有 Scrum master 只有 Aglie coach！
- 產品才是本質，Aglie 只是方法，不要本末倒置
- 不限定團隊採用何種方式運作
而人生永遠都有 deadline，不會因為敏捷就沒有，市場不等人，如果「手術成功但病人掛了」是沒有意義的。Deadline 迫使大家更具焦，可以搭配 MVP 一起服用。
敏捷團隊是自組織，但自組織不會天然成型，要怎麼判斷團隊是不是一個自組織呢？
心態
- 重視目標
- 願意互相協作、幫忙團隊
- 願意主動且心態正面的 feedback
技能
- 自我時間管理
- 能不能發現自己的問題，覺知自己卡在某個狀態
- 有沒有辦法自我解決問題，以及發現自己是不是能解決問題
- 會不會 call help，call help 的時間點掌握（這點很重要！）
團隊成立初期的症頭，包括 Domain Know-how 不足、成員腦子裡的 DoD 都不同（不是寫完作業/程式/需求回饋就完成了，要是 user story 完成才算做完），而腦海中欠缺全貌也搞不清楚目標，這點可以透過 User story mapping 來克服，有必要時每個 Sprint 都可以複習一次。而初期團隊很容易欠缺團隊意識，有時候可以安排已上手的暗樁，或是找 Aglie Coach 來輔導。
Aglie Coach 的價值是，建立團隊的敏捷思維和能力，並引導團隊成為一個自組織。背地裡，推著團隊協助 PO (Project Owner)，必要時，幫助團隊跟 PO 溝通，好的 Aglie Coach 必須手腕高超，有軟有硬，不過 Aglie Coach 在台灣是稀缺資源...很難 hire 到。
力維的推薦閱讀：
Sprint 5 現場的困境
- 敏捷名詞的濫用，例如 RD 說：「這個 bug 存在已久，請 PO 說明解決這個 bug 有什麼價值？」但 bug 就是 bug，只有分嚴重程度哪有分什麼價值...
- Refinement、Planning 傻傻分不清楚 - Refinement 是透過輪廓拿 feedback，Planning 是透過細節進行實作，而分不清楚的狀況是起因於對領域知識的不足。
- Silo 穀倉效應 - 各產品線分工越明確，最後對防守範圍就會很謹慎，很容易在跨團隊的協作工作中，將非自身領域的 PBI 先擺後進。
- 主管對敏捷的過度承諾，遲緩反應 - 對仍分屬各部門的團隊成員，以 waterfall 的標準審視 KPI。
Sprint N 主管們的敏捷
為了避免發生：「大家都很敏捷了，但是老闆一個決策就可以全部推翻。」這種慘劇...把這本書放到老闆桌上吧！然後把老闆關起來敏捷一下。
One PBI - 企業需要一份超越團隊 PBI 的 One PBI，各團隊的 PBI 都應以此為依據，此 PBI 論述的是企業目標與價值主張。
- 老闆要為 One PBI 背書
- 任何開發順序的衝突，皆已回到 One PBI 為依據
- One PBI 可以改動，視企業面對當下的市場場景而定
10 個企業級團隊施行敏捷化失敗的原因（網路資料）
- 產品的願景不夠明確
- 混淆的商業指標
- 開發團隊持續受到干擾
- 團隊沒有 dedicated
- 團隊沒有在同一地點工作
- 團隊太大
- 技術債太多
- 同時間做太多事
- 軟體的交付期太長
- 企業的其餘單位對我們在推行敏捷無感
如何在企業轉型終成為贏家？唯有持續不斷的學習
- Ruddy 老師
Comments
Post a Comment