飛豬項目管理數字化實踐

6月29日，阿里巴巴研發效能部與PMI、Teambition聯合舉辦的阿里巴巴研發效能實踐日將在杭州西溪園區舉行，活動聚焦敏捷精益項目管理。活動詳情及報名可點我前往。

項目管理的目的是什麼？面對工做中的各類不肯定性，如何利用數據幫助項目管理？又有哪些數據是項目經理須要關注的？這裏分享一篇飛豬技術部高級項目管理專家姚澍的文章，但願給你帶來一些啓發。

前言

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

項目管理的目的

常常聽到周邊的同窗說，項目經理一沒權威、二沒前途，誰都不肯意作項目經理，由於幹很差就要背鍋。現實中，看到的不少項目經理項目計劃拍腦殼，執行過程拍胸脯，項目戰報拍馬屁，最後草草收尾、拍拍手走人。彷佛由於帶着「管理」兩個字，讓你們誤覺得這是一個務虛的官僚主義行爲，絲絕不考慮當中的科學性、知識體系、方法論，最後學敏捷只學會了站會、學精益只學會了畫看板、學DevOps只學會了刷臉好辦事。

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

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

初創企業裏，團隊很小，七、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工做的傾力支持，老是容忍並及時知足需求方提出的各類瑣碎、奇葩、緊急的要求，衷心感謝！！

本文做者：雲效鼓勵師

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。