本文主要介紹POLYV半年來的敏捷專案管理實踐經驗，融合了以往十多年研發過程管理經驗，採取了雙班車制度，有效推進客戶高商業價值的需求落地；同時也介紹了PM工具箱，確保研發過程的風險控制，讓客戶價值得到落地。
POLYV產品線
從官網幫助中心入手，簡單把產品線分為：點播、直播兩大類，還提供API、SDK技術支援，並擁有國家專利級別的Playsafe®視訊版權保護技術及三套CDN加速，致力為使用者提供穩定、安全、快速的企業級雲視訊服務。
為了確保客戶商業價值的收益轉化，在專案管理中，既沒有采用繁重的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分佈模組
燃盡圖健康率
- 卡頓出現持續時長，佔比總體時間
- 開發過程中，任務變更的統計
團隊工作效率
- 個人工作效率完成百分比
- 團隊工作效率完成百分比
- 統計個人開發速率
總結
水因地而制流，兵因敵而制勝。 故兵無常勢，水無常形；能因敵而制勝者，謂之神。-《孫子兵法》
專案管理無章法，就談不上圍繞客戶商業價值高的需求，進行快速迭代、過程風險控制、交付反饋，把資源合理化利用，做恰到好處的質量標準，而整個研發過程中，除了客戶商業價值，人也是活動中的重要因素之一。我們的核心成員曾分別服務於網易、騰訊、搜狐、優酷等網際網路巨頭企業，踩過許多坑，有相當豐富的解決問題的經驗，犯錯不害怕，關鍵是自省機制很重要，不再犯同樣的錯誤，確保過程質量風險透明反饋、資源分配合理，質量恰到好處，客戶價值得到實現。
微信公眾號：樂少黑板報