本文主要介紹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分佈模塊
燃盡圖健康率
卡頓出現持續時長，佔比總體時間
開發過程中，任務變更的統計
團隊工作效率
個人工作效率完成百分比
團隊工作效率完成百分比
統計個人開發速率
總結
水因地而制流，兵因敵而制勝。 故兵無常勢，水無常形；能因敵而制勝者，謂之神。-《孫子兵法》
項目管理無章法，就談不上圍繞客戶商業價值高的需求，進行快速迭代、過程風險控制、交付反饋，把資源合理化利用，做恰到好處的質量標準，而整個研發過程中，除了客戶商業價值，人也是活動中的重要因素之一。我們的核心成員曾分別服務於網易、騰訊、搜狐、優酷等互聯網巨頭企業，踩過許多坑，有相當豐富的解決問題的經驗，犯錯不害怕，關鍵是自省機制很重要，不再犯同樣的錯誤，確保過程質量風險透明反饋、資源分配合理，質量恰到好處，客戶價值得到實現。
微信公衆號：樂少黑板報