6月29日，阿裡巴巴研發效能部與PMI、Teambition聯合舉辦的阿裡巴巴研發效能實踐日将在杭州西溪園區舉行，活動聚焦靈活精益項目管理。活動詳情及報名可 點我前往
。
項目管理的目的是什麼？面對工作中的各種不确定性，如何利用資料幫助項目管理？又有哪些資料是項目經理需要關注的？這裡分享一篇飛豬技術部進階項目管理專家姚澍的文章，希望給你帶來一些啟發。
前言
項目管理是起源于20世紀中期美國的航空項目，經過大量專業的項目管理從業人士總結出來的一門學科，并且随着時間發展在不斷演進、更新，比如，在2018最新的PMBOK第六版中就提出了靈活适應型的項目管理方法、拉動式的進度規劃、新型項目經理價值等等。當下，全球IT公司中都在廣泛使用LeSS、SaFe、精益、DevOps，這些新穎的方法論都集中關注在高效的産品開發或生産階段，依然無法完全取代更系統化的項目管理。
項目管理的目的
經常聽到周邊的同學說，項目經理一沒權威、二沒前途，誰都不願意做項目經理，因為幹不好就要背鍋。現實中，看到的很多項目經理項目計劃拍腦袋，執行過程拍胸脯，項目戰報拍馬屁，最後草草收尾、拍拍手走人。似乎因為帶着“管理”兩個字，讓大家誤以為這是一個務虛的官僚主義行為，絲毫不考慮當中的科學性、知識體系、方法論，最後學靈活隻學會了站會、學精益隻學會了畫看闆、學DevOps隻學會了刷臉好辦事。
為什麼要有項目？為什麼要項目管理？我們在管理什麼？難道隻是為了運動式的完成一項任務？難道隻是為了每年績效好考核？我們經常被身在其中的身份制約了視野，總是想着用多快好省的方法達到目的，結果在不知不覺當中，就走入了小巷之中。在那個窄巷當中行走，不是進，就是退，甚至無法轉身。隻有跳出自己的小巷思維、淩空躍起再去審視局面時，才能看到還有很多其他的選擇和出路。這時，才會自然的去追問：為什麼要立項？項目裡為什麼要有這些需求？哪些産品特性需要改變？研發團隊的開發活動如何分解？誰在關鍵路徑上？要花費多少工時？如何保證所有研發活動最後能按時按品質傳遞？如何保證産品上線後實作業務目标？如何監控過程中的風險、問題？最後項目的投資回報比如何？是否完成了企業的财年目标？财報中咱們今年将是虧還是盈？
這樣一系列追問下來，是不是慢慢感覺自帶CEO視角了？ 對，沒錯。項目就是企業的日常活動的組織方式，在質疑要不要立項時就分辨了哪些是臨時任務哪些是每日例行，就能識别出企業最核心的關鍵任務，采用合适的方法管理項目和日常。
初創企業裡，團隊很小，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工作的傾力支援，總是容忍并及時滿足需求方提出的各種瑣碎、奇葩、緊急的要求，衷心感謝！！