POLYV敏捷項目管理

本文主要介紹POLYV半年來的敏捷項目管理實踐經驗，融合了以往十多年研發過程管理經驗，采取了雙班車制度，有效推進客戶高商業價值的需求落地；同時也介紹了PM工具箱，確保研發過程的風險控制，讓客戶價值得到落地。

POLYV產品線

從官網幫助中心入手，簡單把產品線分為：點播、直播兩大類，還提供API、SDK技術支持，并擁有國家專利級別的Playsafe?視頻版權保護技術及三套CDN加速，致力為用戶提供穩定、安全、快速的企業級云視頻服務。

cdn.xitu.io/2018/11/12/16705418ba0e24a7?w=600&h=317&f=jpeg&s=56859">

為了確保客戶商業價值的收益轉化，在項目管理中，既沒有采用繁重的CMMI成熟度，也沒有生搬硬套的敏捷宣言，而是根據團隊特性制定規則，圍繞客戶商業價值高的需求，進行快速迭代、過程風險控制、交付反饋，把資源合理化利用，做恰到好處的質量標準。

PM敏捷體系介紹

為了確保客戶商業價值的收益轉化，在項目管理中，既沒有采用繁重的CMMI成熟度，也沒有生搬硬套的敏捷宣言，而是根據團隊特性制定規則，圍繞客戶商業價值高的需求，進行快速迭代、過程風險控制、交付反饋，把資源合理化利用，做恰到好處的質量標準。

項目管理中經典的戴明環PDCA實踐：

P（Plan）   --計劃，確定方針和目標，確定活動計劃；

D（Do）     --執行，實地去做，實現計劃中的內容；

C（Check）--檢查，總結執行計劃的結果，注意效果，找出問題；

A（Action）--行動，對總結檢查的結果進行處理，成功的經驗加以肯定并適當推廣、標準化；失敗的教訓加以總結，以免重現，未解決的問題放到下一個PDCA循環。

業界通用的敏捷方案

Scrum

Scrum是一種敏捷軟件開發的方法學，用于迭代式增量軟件開發過程。Scrum在英語是橄欖球運動中列陣爭球的意思。

極限編程（XP）

極限編程（eXtreme Programming），是一種全新的、輕量級的、靈巧的軟件開發方法，是一種軟件工程方法學。它強調程序設計團隊與業務專家之間的緊密協作、面對面的溝通（比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好的適應需求變化的代碼編寫和團隊組織方法，更注重軟件開發中人的作用。

看板

看板管理，是豐田生產模式中的重要概念，指為了達到JIT(Just in Time, 及時生產)方式控制現場生產流程的一種工具。幾乎每個學習豐田TPS（Toyota Production System）的企業都會不自覺的把看板當作第一個引入的模式，因為它直觀有效。

PM敏捷管理架構

POLYV的PM管理所采用的框架，是精益和敏捷軟件開發三種不同風格的輕度重疊，在此基礎上根據團隊業務特性優化形成。

PM管理職責

產品經理和項目經理有本質區別的，絕不是等同。

簡單來說，產品經理把客戶的商業價值需求，轉化為研發可理解的任務，這也是艱難的過程，如何表述可研發，可測試性；

而項目經理盡一切整合研發資源，把高商業價值的任務推進落地，關注過程管理，風險控制，雖然在敏捷開發中沒有定義項目經理，但確是很重要角色，敏捷開發要因地制宜，不能照搬來水土不服，適合團隊特性定制的才是硬道理。

項目經理會更加專業業務和教練兩個方向，不斷探索。無論敏捷Scurm，XP，還是看板，都只是形式、流程，客戶的關鍵商業價值目標要把握，從需求到運營階段落到實處，簡潔用六個字概括職責：管什么，怎么管，PM管理職責的要點有：

• 根據產品的質量等級定義和相應測試策略，在過程中跟蹤、反饋商業價值高優先級需求的研發過程落地情況

• 項目計劃跟蹤執行，打通產品、市場、研發、測試、運維生產線的溝通，識別風險和解決團隊所遇到的問題，區分輕重緩急，組織和協調項目中各項活動，基于要事第一的原則推動解決問題

• 服務于產品、研發、測試、運營團隊，使項目順利地、有品質的交付， 并提供研發過程質量數據分析

那么不同段次的PM，將圍繞管理職責展開不同層次的工作，這就是PM的相關成熟度定義。

PM成熟度

基于PM管理職責，把PM成熟度分為六段：

從第一段至第六段，都是圍繞：管什么，怎么管的職責，那么為了更好地盡職盡責，做PM還得有技術活三板斧：懂項目、懂業務、懂人。

PM三板斧絕活

• 懂項目

項目管理中，最經典的鐵三角：

時間、成本、范圍：三者之間要形成一個閉環管理，相互關聯、制約、提升、促進，做到三者缺一不可的高效平衡：就像一個等邊三角形，為了保持平衡性，其中任何一邊有變動，另外兩條邊也會隨之發生適應性變化。而質量是三角形中心的核心元素，也是項目三角形的“眼睛”，項目三角形的任何一個邊發生變化都會影響項目質量，項目質量與三個邊也相互約束。

所謂質量，是指產品上市后給社會帶來的損失。-田口玄一

任何一方的尺寸不合適，都會影響最終交付商業價值的質量，當目標的偏離值小于公差范圍，那就是離目標值越近，這個損失就越小。

• 懂業務

• 有開發經驗的人員，不論做PM，還是測試，都有優勢

• 從高商業價值的業務角度出發，引導產品、研發團隊和參與規劃、定義項目，提煉出項目，化被動為主動

• 推動全員清楚地知道為什么立項這個項目，明白幫助客戶實現的商業價值

• 掌握業務領域相關知識，還包括對實現其業務需求的產品方案的了解，知道使用哪些技術棧來實現，以及對技術實現過程中的難點和重點需要有清晰的把握

• 使用風險工具集，分析業務進度卡頓的地方，給相關負責人做決策分析帶來依據

• 懂人

懂人并不是說具備讀心術的技能，而是掌握團隊成員的技能優缺點，以及對事情把握的判斷深淺程度，基于歷史數據篩選分析，識別研發過程風險，能夠根據成員特性，找出解決風險的策略，推進實施。

除了懂項目、懂業務、懂人，PM絕活還有不少，比如這些軟技能：

Scrum敏捷過程管理

項目管理并不能直接提升產品質量，同樣投入再多測試也不能提升產品質量，產品在轉化為研發任務的制造過程中已經決定了質量。

項目管理有一個很重要的觀點：事前預防、事中控制、事后分析。

制定Scurm敏捷過程管理框架，也是為了貫徹這個觀點，打通從需求階段出發、研發階段、發布階段、運營階段環節，把控過程反饋、識別風險，調整計劃，做好擁抱變化，把質量偏差控制到最小可接受范圍，實現客戶的商業價值需求落地。

概覽：雙班車制

在整個敏捷迭代周期中，分為：快速班車和版本班車。

例如：三周迭代中，每周都可以發布來自市場、客戶迫切需求，剩下的按照版本班車的迭代步伐進行。這樣子的好處，在確保客戶高商業價值需求得到實現的同時，也快速把版本需求迭代前行，更好為客戶服務，體現價值。

需求階段

關注點：以交付價值為導向，推進高商業價值需求進入研發池。

Sprint會議前

• PM參與產品需求評估，識別客戶高商業價值的需求，轉化為研發迭代任務

• 組織參與當前迭代的研發成員提供有效可用工時，并且錄入系統以供評估分析

• 組織上一次迭代總結會議，提供QA數據（工作效率統計、質量維度數據）分析過程問題

Sprint會議中

• 組織評估研發、測試任務工時，消除需求、工時含混性

• 推動產品、研發、測試相關人員將商業價值高的需求放入研發池

• 根據定版的迭代任務，定義質量等級，協助測試指定驗收準則

研發階段

關注點：透明化、可視化、盡早暴露問題

日常站立會

• 組織團隊成員自發參與每日晨會，分享信息，提出路障

• 燃盡圖問題反饋、風險識別、各端進度反饋；

• 會后重大問題跟蹤、反饋

日常風險控制

日常問題反饋：

• 重大問題、任務調整，拉上產品人員一起討論決定

• 日常運營客戶問題識別風險，推動研發、測試解決

任務調整：

• 保持原有飽和度，工時緊張的情況下，插入新任務，則移出優先級低的

• 超過原計劃，必須插隊的任務，也沒有考慮移出的，則項目周期會發生延長變化的可能性

風險評估：

• 根據產品的質量等級定義和相應測試策略，跟蹤反饋商業價值高優先級需求的研發過程落地情況

• 提供風險識別，打通產品、市場、研發、測試、運維生產線的溝通，解決要事第一的優先級

燃盡圖風險反饋

• 曲線居高不下：看看哪里出問題，誰可以幫忙解決？

• 曲線下降太快：是否路障消除、任務評估不準確，實際更加樂觀，能否加快測試，

• 警惕：前松后緊，前面圖形樂觀，后面爆發風險

信心指數反饋

• 根據已知風險點評估當前團隊信心，是否能夠順利消除路障，達成目標

倒計時

• 項目距離交付的緊迫感，全員聚焦時間可用，關注當前整體進展

發布階段

關注點：現地現物

驗收機制

• 組織全員參與BugBash大掃除

• 組織產品相關人員參與客戶價值驗收

發布過程

• 協助研發、測試人員制定checklist，用于線上檢查

• 組織測試參與需求覆蓋線上確認，明確發布階段關注重點

運營階段

關注點：持續改善

• 收集技術支持反饋當前發布版本的狀況，客戶商業價值實現的反饋程度,快速響應推動解決

• 團隊全員參與，總結當前版本迭代遇到的問題，形成有效措施落地執行，避免重現

PM工具箱

迭代看板

在敏捷迭代過程中，不同角色的關注重點不同，分為需求看板和敏捷看板。

需求看板

產品人員無需關心研發任務細節，僅關注大的方面，需求總體進度如何，缺點是對細節不了解，需要進一步查看敏捷看板，以及跟PM溝通。

PM看板

作為實施敏捷PM框架的核心人員，PM關注全局：需求、研發任務進度詳情，包括各類開發類型任務進度、bug進度等等。

研發看板

實際就是PM看板，隱藏了需求部分，將關注點落到具體研發任務上。

風險檢查表

PM工具箱常備檢查表，從業務風險、技術風險、過程風險提供基礎檢查點，可以根據每次Sprint總結的問題反饋，轉化為新的風險關注點，補充到檢查表中，以下從工具箱提取部分列舉

業務風險檢查表

• 產品商業價值定義不清晰

• 需求不清晰，完成產品定義含混的部分比期望需要更多的時間

• 與競爭對手搶時間，犧牲了質量定義

技術風險檢查表

• 開發自測不充分

• 功能點可測試性差

• 代碼設計復雜

• 使用不熟悉的技術，沒有額外的調研時間

• CodeReview不充分

過程風險檢查表

• 士氣低下，溝通不到位

• 客戶商業價值需求，信息傳遞不一致

• 任務估算樂觀過度，未留夠緩沖時間，例如日常會議、學習分享

• 進度更新不及時，導致項目總體進度看似沒進展

• 新增任務沒有通知PM、測試，需求覆蓋不完整

• 人員負責多個項目，上下文切換成本高，導致項目進展有拖延

• 設備不到位，開發環境出問題

數據分析

通過收集過程數據，從四個維度來評估項目質量，包括：項目完成率、Bug生產率、燃盡圖健康率、團隊生產效率：

下面列舉一下簡化的指標

項目完成率

• 總體完成率=迭代總完成工作量/迭代總工作量

• 計劃完成率=完成計劃工作量/計劃工作量

Bug生產率

• bug生產率=迭代新增bug工作量/迭代總完成工作量

• bug分布階段：需求、開發、測試

• bug分布模塊

燃盡圖健康率

• 卡頓出現持續時長，占比總體時間

• 開發過程中，任務變更的統計

團隊工作效率

• 個人工作效率完成百分比

• 團隊工作效率完成百分比

• 統計個人開發速率

總結

水因地而制流，兵因敵而制勝。 故兵無常勢，水無常形；能因敵而制勝者，謂之神。-《孫子兵法》

項目管理無章法，就談不上圍繞客戶商業價值高的需求，進行快速迭代、過程風險控制、交付反饋，把資源合理化利用，做恰到好處的質量標準，而整個研發過程中，除了客戶商業價值，人也是活動中的重要因素之一。我們的核心成員曾分別服務于網易、騰訊、搜狐、優酷等互聯網巨頭企業，踩過許多坑，有相當豐富的解決問題的經驗，犯錯不害怕，關鍵是自省機制很重要，不再犯同樣的錯誤，確保過程質量風險透明反饋、資源分配合理，質量恰到好處，客戶價值得到實現。

微信公眾號：樂少黑板報