6月29日，阿里巴巴研發效能部與PMI、Teambition聯合舉辦的阿里巴巴研發效能實踐日將在杭州西溪園區舉行，活動聚焦敏捷精益項目管理?；顒釉斍榧皥竺牲c我前往。

項目管理的目的是什么？面對工作中的各種不確定性，如何利用數據幫助項目管理？又有哪些數據是項目經理需要關注的？這里分享一篇飛豬技術部高級項目管理專家姚澍的文章，希望給你帶來一些啟發。

掃描上述二維碼或點我直達 免費領！

前言

項目管理是起源于20世紀中期美國的航空項目，經過大量專業的項目管理從業人士總結出來的一門學科，并且隨著時間發展在不斷演進、更新，比如，在2018最新的PMBOK第六版中就提出了敏捷適應型的項目管理方法、拉動式的進度規劃、新型項目經理價值等等。當下，全球IT公司中都在廣泛使用LeSS、SaFe、精益、DevOps，這些新穎的方法論都集中關注在高效的產品開發或生產階段，依然無法完全取代更系統化的項目管理。

項目管理的目的

經常聽到周邊的同學說，項目經理一沒權威、二沒前途，誰都不愿意做項目經理，因為干不好就要背鍋?，F實中，看到的很多項目經理項目計劃拍腦袋，執行過程拍胸脯，項目戰報拍馬屁，最后草草收尾、拍拍手走人。似乎因為帶著“管理”兩個字，讓大家誤以為這是一個務虛的官僚主義行為，絲毫不考慮當中的科學性、知識體系、方法論，最后學敏捷只學會了站會、學精益只學會了畫看板、學DevOps只學會了刷臉好辦事。

為什么要有項目？為什么要項目管理？我們在管理什么？難道只是為了運動式的完成一項任務？難道只是為了每年績效好考核？我們經常被身在其中的身份制約了視野，總是想著用多快好省的方法達到目的，結果在不知不覺當中，就走入了小巷之中。在那個窄巷當中行走，不是進，就是退，甚至無法轉身。只有跳出自己的小巷思維、凌空躍起再去審視局面時，才能看到還有很多其他的選擇和出路。這時，才會自然的去追問：為什么要立項？項目里為什么要有這些需求？哪些產品特性需要改變？研發團隊的開發活動如何分解？誰在關鍵路徑上？要花費多少工時？如何保證所有研發活動最后能按時按質量交付？如何保證產品上線后實現業務目標？如何監控過程中的風險、問題？最后項目的投資回報比如何？是否完成了企業的財年目標？財報中咱們今年將是虧還是盈？

這樣一系列追問下來，是不是慢慢感覺自帶CEO視角了？ 對，沒錯。項目就是企業的日?；顒拥慕M織方式，在質疑要不要立項時就分辨了哪些是臨時任務哪些是每日例行，就能識別出企業最核心的關鍵任務，采用合適的方法管理項目和日常。

初創企業里，團隊很小，7、8個人一間房、通訊靠喊的時代，溝通、管理成本是相對較小的，確定優先級就可以直接執行了，甚至也沒什么好失去的。然而團隊體量上去之后，稍有疏忽，沉沒成本太大，會直接影響企業存亡。

項目管理鐵三角里的幾個因素：范圍、成本、工期、質量，都和企業的關注高度吻合，企業管理核心也就自然落到了關鍵項目的管理上。

為何要數字化管理項目

互聯網公司要面對很多不確定的用戶、對手、市場，面對未知，我們怎么辦？只有兩個方法：

• 試驗，在小范圍快速實現產品原型，灰度測試或者A/B測試收取反饋，結合運營效果快速反饋，在下一個迭代優化、改進。
• 度量，準確定義度量維度，精確、及時收集數據，運用數據分析暴露問題、驗證試驗結果，從而持續優化。

度量離不開數據，我見過很多項目經理，在描述自己帶過的項目規模時，說不出準確的數字：多少團隊成員、多大項目范圍（代碼行、特性數量、開發工時），多長的項目周期，多少項目成本，怎樣的業務目標？很多人甚至分不清楚OPEX和CAPEX，更不用說ROI。因為缺少談數字的環境，缺少對數字的敏感，沒有鼓勵和培養人人習慣用數字分析來系統性思考的內部環境，導致大部分的技術甚至PD只會埋頭干活，鮮少追問為什么，溝通時也用大量的篇幅主觀、模糊的描述項目進展，造成理解偏差、溝通低效。

為什么要習慣在工作中談數字呢？

• 數字是量化的目標。企業運作是有詳細細節規劃的，比如，財年的業務目標、成本預算，應該層層分解，落實到各個項目、各個節點當中去，甚至要能反向推導，這樣才能預測月度、季度的運營結果。同時，在過程當中能作為組織行為的基準線，讓大家自覺針對目標及時調整行為。
• 數字更客觀，能更準確描述細節。數字比感覺更可靠，人往往容易被自己的情緒、偏見、誤解欺騙，會對事實作出錯誤的判斷。論據越客觀、越細致，才越能經得起推敲，不管是用來決策還是溝通，都遠勝于簡單的拍腦袋。
• 數字是驅動力。項目經理的核心價值應該在數據分析上，能從大量的、有效的數據當中發現趨勢，識別風險或者機會，及時調整項目策略，保障項目目標達成。遺憾的是，現實中大多數項目經理都干的是初級的信息、事實收集工作。不是說信息收集不重要，而是應該建立起通用的、自動化的、可視化的數據大盤，把精力投入到收集完之后如何整合，如何解讀，如何決策。

哪些數據是項目經理必須關注的

如下表所示，項目的不同階段的關注重點不一樣，相應的要有高效的手段挖掘出有用的信息。

注：文中提到的Aone是阿里一站式研發協作平臺，對外叫云效，下同

事實上，AONE已經能基本提供收集以上所有信息的功能。很多大型的IT企業一直不遺余力的在尋找合適的工具管理各類信息，因為歷史遺留問題，不得不花費大量的時間、精力打通所有的信息通道，遷移、整合數據，而AONE已經幫助我們彎道超車，實現了完整的需求產生、生產、集成、發布、部署。在飛豬，我們更進一步，針對特定的應用場景，基于AONE的數據，二次開發，用魔法石生成了重點項目的定制化項目數據大盤。

飛豬項目數據大盤實踐

那么數據大盤包含了哪些內容呢？

首先，從19財年業務策略開始梳理重點戰役結構，用一張圖畫出各戰役之間的關聯（以下為示意圖），并明確負責的項目經理和產品經理，形成第一級的項目目錄。重點在：

• 分清楚項目發起人和項目集經理。我們經常容易把這兩個角色弄混，一個項目會出現好幾個管理者，在不同場合項目經理的名字不一樣。項目經理是第一責任人，必須是直接指揮、跟蹤、匯報項目的執行人，明確其唯一性和權威性并廣而告之很重要，能加速問題解決和減少溝通誤解。
• 整合項目結構，合并相關聯的，并廣泛溝通。
• 目標明確再立項。

設定統一的項目里程碑規范。以前項目的里程碑計劃很隨意，可有可無，大小不一。容易造成：顆粒度太小，外部干系人看不懂；顆粒度太大，缺少對項目組內的指導。現在采用統一的M系列里程碑定義，明確項目考核的時間點和標準，嚴格執行重要里程碑（M1&M4）的評審制度，有效的管理干系人期望，并隨時度量下一個里程碑的可實現性。這樣的好處是：

• 用統一的術語規范的項目執行的質量標準。
• 里程碑評審增加項目執行的嚴肅性和完整性，做到有始有終，防止虎頭蛇尾，幫助持續改進。
• 增加溝通有效性，項目的評審結果和跟蹤直觀、易讀、統一。

整理AONE項目空間，明確產品線、項目組合、項目集、項目的結構關系。需求、測試、缺陷、發布全部落入AONE，在魔法石生成對應的報表結構，層層鉆取細節信息。

• 在飛豬產品線下設置子產品線，所有需求都直接在對應的子產品線下創建，遵循統一的規范模版，這樣才能保證所有需求屬性一致，方便魔法石度量。
• 所有重要項目在PMO注冊、創建，不允許私建項目。簡化項目結構，只允許兩層項目歸屬關系，避免過深的項目結構帶來的責任不明確。
• 由PMO組織重點項目例會，項目集經理向項目發起人匯報項目狀態，方便及時調整策略、暴露問題，解決沖突，同步信息。

建設項目經理的責任制，要求項目經理必須對項目整體表現給出信心判斷，依據AONE里的項目健康度信息形成項目晴雨表，紅綠燈直觀表現出項目的健康狀態。要注意的是：

• 項目狀態是項目經理的主觀判斷，是報告里為數不多的非客觀評價，但不能省略，整體判斷項目健康狀態，同時也給出責任人的承諾
• 項目的趨勢比單點狀態更重要。對持續告警的項目，要開始專項治理。

針對需求管理，首先明確不同角色的責任和合作方式。清晰的項目邊界是成功的關鍵。項目啟動初期，應該花大量的時間和精力明確需求范圍、優先級、技術方案，而不是盲目開工，毫無紀律的邊討論邊干活，不斷返工，最后越做越困惑。比如，下面的兩個實例，

• 項目A，對各類需求范圍的管理都很嚴格，需求總量只出不進，每月評審上線效果，在后期果斷丟棄低優先級的需求保證項目按時完結。
• 而項目B，各類需求都在緩慢增長，實際表現就是項目做的像日常，未來沒有規劃，想到什么就做什么，目標不明確。

使用按優先級分類的需求累積流圖，識別項目核心交付內容，通過日常監管防止項目邊界蔓延，做到有始有終，清空桌面再結項。

測試計劃可以使用甘特圖，測試過程中要有定期（每日/每周）進展推進圖。項目后半段的時候，往往是測試的白熱化階段，有些項目可能需要用日會結合缺陷報告重點推進，識別出阻塞測試的缺陷，是否需要組織特殊小分隊集中解決難題，是否需要不斷升級警告直到團隊的高層領導桌面上，要能結合進展明確指出問題以及解決辦法，而不要羅列繁瑣的細節。

缺陷分析，在宏觀上，要能指出質量問題是否收斂，解決速度是否夠快，識別重點問題集中區；微觀上要就重點問題清單，點對點分析原因、找出解決方案、給出實施計劃。缺陷不僅僅是質量風險，也是工作量，不管是修復問題，還是提出新需求，都是整個項目的新增工作量。實際上，缺陷也是可以預測的，根據千行缺陷率、改動代碼行數、修復工時、合適的數據預估模型，就能更合理的估計產品上線時間，而不是總倒排工期。做到符合一定質量標準的產品才允許上線，杜絕只開發不測試、只測試不修復、無紀律上線等一系列嚴重影響用戶體驗的行為。

風險管理一直是項目管理的難點。首先，我們只能管理看得到的風險，有些風險也不可避免的會實現，更不用說那些完全無法預測的風險。其次，風險管理更考驗項目經理個人的經驗和敏銳。AONE提供了風險管理的功能，但“重風險識別，輕用風險應對分析”的現象還是比較普遍。AONE中提供的風險匯總視圖（下圖左）只能單維度的展現風險嚴重性，缺少可能性指標，于是我們在數據大盤里加上了風險矩陣（下圖右），按嚴重性、可能性劃分出9宮格，把注意力集中在矩陣右上角，一目了然。

人力資源投入是大家都很感興趣的一個話題。AONE暫時不提供相關統計，我們只能另外開發小工具，由團隊TL每月填寫各項目參與人員的數量。資源分配可以宏觀上幫助研發團隊規劃項目投入，不僅僅對過去的資源投入分析總結，更重要是可以整體上預計未來的資源分配是否能支持業務需求。

理論上，大家填好AONE里的需求工時估計，計算出來的工作總量應該是最準確的資源耗費成本，也可以生成項目的工作量燃盡圖，以此能準確的預測項目實際上線、驗收的日期。但實際執行中面臨挑戰太大，需求拆分不明確導致工時估計落實困難，而不得不折中由TL來匯總人力資源分配信息。

經過半年的項目規范、數據運營落地實踐，從S1半年的項目需求交付周期回顧，我們發現:

• 強管控的需求交付周期明顯短于平均值。
• 交付周期中占比較大的是需求分析階段，表征就是項目前期需求、目標不明確，導致后期開發趕工，測試壓縮，最后的結果自然就不夠好。
• AONE的使用規范統一化非常重要，對需求的跟蹤、更新不及時就會造成數據偏差。在使用好項目例會同步信息的同時，通過關聯代碼和需求自動匯總狀態變化信息，讓數據更準確。

項目管理體系的未來

我經常被問到PMO是干什么的？很多人直接把PMO和過程改進、提高研發效能相等，我覺得PMO應該承擔的責任是：首先，協助分解戰略，合理部署資源，把關項目立項，整合項目結構。其次，建立系統的適配的管理規范，拉通上下游，讓研發團隊如同工廠生產線一般有質量、有效率的交付產品；最后，賦能項目經理，提高管理水平。優化、提效應該是一以貫之的持續改進。

經過半年的數據建設，飛豬技術部運行的項目已經逐漸規范，完成了兩個重點戰役的M4驗收，明確了項目邊界，逐步培養項目經理們的數據意識，倡導大家追問業務目標，量化過程指標，每個迭代都及時收集業務反饋，保證用戶價值在運營、產品、技術、客滿團隊之間的順利傳遞，并形成閉環。當然，我們依然面臨巨大的挑戰：

• 用戶價值的追問、傳遞必須持之以恒的堅持下去。
• 日常需求和弱管控的項目開發支持不夠。
• AONE中沉淀了大量的數據，需要人性化的自動收集和分析焦點問題。
• 項目的迭代規劃、定期演示尚未制度化。
• 項目經理賦能不夠，只有越來越多的優秀項目經理成長起來，才能更廣泛的保證系統健康運行。

這半年，有成功交付上線的項目，也有目標不明確業務效果不明顯而被叫停的項目，我們為成功喝彩，也為挫敗反思，至少我們已經邁出了第一步。希望有一天能真正實現項目的可視化、可度量、可預測，希望有更多的人有熱情投身項目管理。未來的路還很長，我們還需努力。

在此文結尾，不得不提到龍幽、歐旋兩位數據挖掘專家過去5個月中對PMO工作的傾力支持，總是容忍并及時滿足需求方提出的各種瑣碎、奇葩、緊急的要求，衷心感謝！！

?

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的飞猪项目管理数字化实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。