「天下武功，唯快不破」，這句話用在互聯網世界里格外適合。互聯網產品模式講求快速迭代、小步快跑，業務和協同團隊的快速變化是常態。

[[315765]]

然而，要想真正在一個研發周期內每個需求執行不失控、成本和風險能控制、項目質量有保障，除了產品寫需求文檔、開發寫代碼改 BUG、測試寫用例和 BUG 匯報驗證外，通常還有很多非常重要而細碎的事情要做，比如：項目經理創建需求溝通群、組織站會、產品經理編寫上線周知通知運營和客服人員等，其中有些工作是重復的，需求相關的信息也比較多，通常散落在各個地方后期難以查找。

對于 PMO 和開發組長而言，則需要在多需求并行的情況下快速地發現某些高風險需求并重點關注和推進。如何提升需求執行效率和降低并行需求管理成本呢?本文將分享馬蜂窩交酒 PMO 團隊是如何通過用自研 的 PMO 系統驅動過程管理的方式，來降低項目管理的人力成本。

Part.1 背景介紹

馬蜂窩大交通和酒店研發團隊采用雙周 PK 和雙周迭代模式。為了助力高效、透明的研發流程，團隊成立初期就確立了使用工具來進行研發項目全周期管理的方式。通過對比后最終選擇了 TAPD 作為產研流程的管理工具，主要是因為 TAPD 具有配置和操作簡便、支持移動辦公、項目間隔離性強等優勢。

1.1 需求狀態和分類

需求分為三類：日常、項目和線上問題。目前主要使用 TAPD 的「需求」功能管理需求，「迭代」功能管理迭代，日常類需求的迭代周期為 2 周，項目類需求的迭代周期為 4 周。

日常和項目需求的狀態均有以下九種：

圖 1：需求狀態

1.2 PMO 的日常

1. 組織項目實施

線下的研發流程其實是個很龐大的矩陣圖，橫軸為需求的 9 種階段，縱軸為 5 種不同角色——項目經理(PM)、產品經理、開發、測試、PMO，矩陣圖明確地規定了對于一個需求而言不同角色在不同階段應該做的事情。在需求處于不同狀態時，5 種不同角色都有很多細碎的事情要做，比如：

• 準備階段：「待實施」狀態時，PM 需要為需求相關人員組建企業微信群，實現信息及時互通。
• 開發階段：進入到「開發中」后，PM 需要每天組織站會并發送站會紀要到需求的企業微信群。
• 測試階段：到「測試中」以后，測試需要每天發送測試日報到企業微信群。
• 上線后：需求狀態轉為「已上線」后，產品經理需要發送上線周知郵件;轉到「線上效果跟進」，產品經理需要發送線上效果跟進郵件。

這些事情中有很多是重復性很強的工作，比如拉微信群等。上述這些不同的信息也會因產生的時間不同、同步的方式不同而非常分散，有的通過郵件，有的是微信群，后期查找起來非常困難。

2. 項目質量控制

對于 PMO、開發經理和開發總監而言，同時需要管控多個并行需求的實施質量，就需要能快速地獲取到項目執行中的風險，比如：

• 每天有哪些項目未通過站會溝通，需要逐個在企業微信群查找并與 TAPD 中的需求做對比。
• 有哪些需求發生延期提測或者延期上線，需要逐個在 TAPD 中查找項目的提測和上線狀態，非常繁瑣而且容易遺漏。

除了需求的落地和多個需求并行管控外，每周產品經理們都需要向上級匯報本周的需求上線情況，每周每個業務線都有需求上線。多業務線和多負責人使得周報收集和匯總的工作量非常大，有時候難免會有些內容遺漏，也不能保證在固定時間發送。

1.3 PMO 系統設計目標

基于上述在需求管理、風險控制和日常工作中存在的一些問題，交酒 PMO 團隊規劃并實現了 PMO 系統，以期高效實現需求從實施到上線的全過程管理。PMO 系統的主要目標和定位如下：

1. 信息全部需求相關信息統一在 TAPD 中錄入和管理，包括站會紀要、測試日報、上線周知等。
2. 支持多業務線，不同業務線的迭代開始時間和迭代周期、不同業務線對應的郵件組、企業微信群均可配置。
3. 流程提效，包括自動創建企業微信群，從 TAPD 中查詢站會紀要、測試日報等信息并發送到企業微信群，從 TAPD 中查詢上線周知信息并自動發送郵件等。
4. 并行需求管理和風險管控。
5. 知識沉淀和管理，包括流程文檔、PM 知識分享等。
6. 向上匯報，多業務線的產品經理們在 TAPD 填寫了不同需求的上線周知后，系統自動匯總本周全部上線的需求和上線周知，定時向業務總負責人發送周報。

Part.2 主要功能及實現

2.1 整體設計

PMO 系統將過程管理與 PMO 理論相結合，基于 TAPD 的 API 和企業微信 API 獲取遠端數據進行項目的數據擴展，可以同時支持多業務線的項目過程管理。

PMO 系統的核心就是進行關鍵信息的收集和高效的處理。具體來說，每個業務線在項目實施的不同階段，都會通過創建企業微信群的方式實現實時的溝通和管理。通常來說分為如下幾類：

1. 短期群——需求企業微信群：該需求變為「待實施」后創建，需求上線一定時間后群可以解散;群成員包括該需求的產品經理和產品組長、開發人員和開發組長、測試人員和組長、研發總監;后面簡稱為「需求群」。
2. 長期群——雙周 PK 企業微信群：該業務線參加 PK 會議的全部開發組長和全部產品;后面簡稱為「雙周 PK 群」。

另外，我們將每個業務線的郵件組分為研發組和產品組兩個大組。

所有需求相關信息都由需求相關人員錄入到 TAPD 中，PMO 系統自動從 TAPD 中拉取信息并做處理。

PMO 系統主要分為數據收集和數據處理兩個部分，整體流程圖如下：

圖 2：PMO 系統流程圖

2.2 主要功能實現

PMO 系統實現的功能主要包括：

1.對實施過程進行管理和風險控制，實現迭代管理和需求管理

2.向上管理，拉取一定周期內多業務線上線的需求，并定時給業務負責人發送周報

3.數據支持，按項目、迭代、季度、人的維度進行工時統計

4.知識沉淀和管理，包括流程文檔、PM 知識分享等

下面我們來看具體的實現方式。

2.2.1 實施過程管理

對實施過程的管理主要分為迭代管理和需求管理。迭代管理主要是幫助 PMO 和管理人員進行并行需求管理和風險控制，需求管理則聚焦對需求實施流程進行提效。

1. 迭代管理

(1) 需求 PK 前后信息匯總

剛剛實行 PK 會議的時候，有些參與 PK 的需求錄入到 TAPD 的時間很晚，與會人員對參加 PK 的需求不是很了解，產品人員花費了很多時間在 PK 會議中講需求，最長的一次 PK 會議甚至開了 3 個小時。

為了解決這個問題，PMO 系統采用開啟數據收集定時任務的方式，通過 TAPD API 統一獲取待 PK 類型的需求，并在 PK 前一天下午固定時間發送到「待 PK」需求列表，幫助參與 PK 會議的開發、測試人員盡早了解這些需求，提升 PK 會議的效率。并且規定超過固定時間未錄入到 TAPD 的需求不參加 PK 會議，側面促進產品人員早日明確自己的需求。

圖 3:「待 PK」需求消息發送流程圖

圖 4: 發送「待 PK」需求列表消息示例

PK 會議召開完畢后，當晚 8 點 PMO 系統會獲取最新日常和項目迭代的待實施需求信息，并發送「待實施」需求匯總消息到「雙周 PK 群」，發送格式為「需求名稱|產品經理姓名|優先級」。

兩次 PK 會議之間除了待實施需求、偶發性的特殊需求和線上問題修復之外，不接受其他需求。

圖 5:「待實施」需求消息發送流程圖

圖 6:發送「待 PK」需求列表消息示例

(2) 進行中迭代需求進度匯總

之前當并行需求較多時，想了解整體執行情況需要挨個查看 TAPD 中的需求和任務執行情況并與計劃時間做對比，這個過程比較耗時。因此每周五晚 6 點 PMO 系統針對不同業務線的進行中迭代的需求進度、延期情況發送郵件到該業務線的研發組&產品組，并發送消息到該業務線的「雙周 PK 群」。協助 PMO 和管理人員快速識別風險并進行重點推進。

圖 7:需求進度匯總流程圖

圖 8:每周需求進度匯總消息

圖 9:每周需求進度匯總郵件

2. 需求管理

主要有以下三類功能：

• 自動創建企業微信群
• 自動同步消息和郵件
• 自動提示項目進度

下面詳細介紹。

(1) 自動創建企業微信群

雙周 PK 通過后，PMO 系統調用企業微信 API， 自動為每個待實施的需求創建企業微信群，更改群名稱為需求名稱-PM XX-PD YY，節約 PM 創建微信群和邀請人員加入的時間;需求狀態轉為「開發中」后，自動更改群名稱，增加預計提測時間和預計上線時間。

圖 10: 微信群示意

(2) 自動發送消息和郵件

PMO 系統可以通過定時掃描需求的評論和識別評論中的關鍵字自動發送站會紀要消息、延期風險郵件、上線周知郵件、測試日報和測試報告消息等。

為了讓需求相關的信息全部都統一放置在 TAPD 中方便后期查詢，并對一些操作進行自動化處理，PMO 系統定義了一些需求評論的模版，相關人員把所有需求相關的信息均按模版填寫評論，PMO 系統的數據收集定時任務每隔 15 分鐘掃描一次需求評論，識別模版中的關鍵字后，執行各類消息和郵件的發送。目前共處理 6 類關鍵字：站會紀要(項目經理錄入)、測試日報(測試人員錄入)、測試總結(測試人員錄入)、延期風險(項目經理錄入)、上線周知(產品經理錄入)和線上效果跟進(產品經理錄入)。

需求狀態轉為「開發中」之后，由項目經理填寫站會紀要到需求評論中，PMO 系統每天上午自動發送站會紀要消息;需求狀態轉為「測試中」后，由測試人員填寫測試日報，每晚自動發送「測試日報」;需求狀態在「開發中」和「測試中」時，如果項目經理填寫了「延期風險」，自動發送延期風險郵件;需求狀態轉為「已上線」后，由產品經理填寫上線周知到需求評論中，PMO 系統自動發送上線周知郵件。

圖 11: 信息的收集和處理

(3) 自動提示項目進度

一個需求評審結束的技術方案設計完畢后，開發和測試需要在 Wiki 文檔和 TAPD 中利用任務功能進行排期，之后 PM 需要把排期表格拷貝到郵件中，給相關人員發送郵件。拷貝的過程是重復且耗時的。基于這些問題，PMO 系統通過 TAPD 中需求的狀態流轉實現了自動發送 Kick Off 郵件、提測郵件、超時控制消息等。這類需求的流程圖如下圖所示：

圖 12: 需求狀態變更和風險控制

當需求轉為「開發中」，PMO 系統自動拉取該需求的各任務排期并發送 Kick Off 郵件，如果排期超迭代周期了，則需要走專門的審核流程。需求轉到「測試中」，PMO 系統會自動發送提測郵件。

圖 13: kick off 郵件示例

當需求未按時提測或者未按時上線時，PMO 系統會發送延期提測和延期上線消息到需求群和雙周 PK 群;當任務未按時完成時，PMO 系統會發送超時未完成消息到需求群和雙周 PK 群，方便 PM 和 TL 進行風險控制和有針對性的處理。如果需求上線 2 周后未填寫「線上效果跟進」，PMO 系統會發送超時未跟進線上效果消息到需求群和雙周 PK 群，提醒產品經理跟進線上效果。

圖 14: 超時提醒

2.2.2 向上管理

為了節約產品經理在周末再次匯總和編輯本周上線內容，以及協調不同業務線產品經理編寫周報時間的工作，PMO 系統每周五晚 6 點拉取本周上線的不同業務線的全部需求和每個需求的上線周知內容，給業務負責人發郵件匯報本周的需求進度和每個需求上線的效果。

圖 15：上線匯總

2.2.3 數據統計

有人經常會問 PK 會議時一個迭代究竟接多少需求合適?研發 TL 在制定 KPI 目標時也經常會關注從需求實施效率角度看，當前需要幾人日能完成一個項目類需求，日后目標是減少為多少人日完成一個同等規模的項目類需求?PMO 系統支持項目類需求按迭代、季度進行統計，給總監級別人員做決策時提供數據支撐。

圖 16: 數據統計

2.2.4 知識沉淀和管理

團隊里經常會有新鮮血液加入，PMO 對全員進行流程宣講的頻率還是比較低的，因此 PMO 系統里加入了一些項目流程的基本知識，方便新人熟悉流程和加速流程落地。

圖 17: 知識沉淀

2.3 實現效果

PMO 系統分為 3 期，已全部上線。總結來看，截至目前實現的主要效果有：

1. 信息統一匯總到 TAPD 后，所有人員可以方便地在 TAPD 查詢需求相關的一切信息，包括評論、站會紀要、測試日報、測試報告、上線周知、線上效果等。
2. PMO 系統提煉了全部需求的風險并發送到微信群，輔助 PMO 和管理人員重點關注某些高風險需求。
3. 自動發送 Kick Off 郵件、提測郵件、站會紀要，并匯總和提示需求、任務延期風險，可以節約 PM 大量的時間。
4. 自動匯總本周所有上線的所有需求和上線周知并發送周報給總業務負責人，節約了產品經理大量的編寫周報時間。
5. 幫助開發人員自動發送提測郵件，幫助測試人員自動發送測試日報和測試報告。
6. 知識沉淀功能幫助 PM 和新人盡快的熟悉流程和相互學習。

Part.3 未來規劃

通過 PMO 系統的應用，高效實現了需求從實施到上線全過程管理，盤活資源，實現項目增效。伴隨著 PMO 系統的運行和推廣，我們也在收集用戶反饋并進行系統優化。與此同時，DevOps 系統也已經開發完畢并在交通業務落地。DevOps 系統覆蓋了需求的從開發中到已上線的 4 個狀態：

目前，對于延期提測或延期上線風險預警的依據主要來自對「實際時間」和「預測時間」之間的對比，其中「實際提測時間」、「實際上線時間」等信息是通過 PM 手動維護 TAPD 狀態變更之后填寫。后續 DevOps 系統將和 TAPD 打通，例如開發在 DevOps 系統中流轉為「已提測」或者「已上線」后，該需求在 TAPD 中自動變為「已提測」和「已上線」，減少人為填寫的不確定因素，PMO 系統統計延期提測和延期上線的需求時就會更加精準。

我們相信，未來隨著 PMO 系統 與 DevOps 的打通，以及與 TAPD 等外部工具更加深度的連接，我們的項目管理將越來越高效，研發流程將越來越敏捷。