建站
咨詢
售后
建站咨詢
新聞中心
「天下武功，唯快不破」，這句話用在互聯(lián)網(wǎng)世界里格外適合。互聯(lián)網(wǎng)產(chǎn)品模式講求快速迭代、小步快跑，業(yè)務和協(xié)同團隊的快速變化是常態(tài)。
在成都做網(wǎng)站、成都網(wǎng)站建設、成都外貿(mào)網(wǎng)站建設過程中，需要針對客戶的行業(yè)特點、產(chǎn)品特性、目標受眾和市場情況進行定位分析，以確定網(wǎng)站的風格、色彩、版式、交互等方面的設計方向。成都創(chuàng)新互聯(lián)還需要根據(jù)客戶的需求進行功能模塊的開發(fā)和設計，包括內(nèi)容管理、前臺展示、用戶權(quán)限管理、數(shù)據(jù)統(tǒng)計和安全保護等功能。
然而，要想真正在一個研發(fā)周期內(nèi)每個需求執(zhí)行不失控、成本和風險能控制、項目質(zhì)量有保障，除了產(chǎn)品寫需求文檔、開發(fā)寫代碼改 BUG、測試寫用例和 BUG 匯報驗證外，通常還有很多非常重要而細碎的事情要做，比如：項目經(jīng)理創(chuàng)建需求溝通群、組織站會、產(chǎn)品經(jīng)理編寫上線周知通知運營和客服人員等，其中有些工作是重復的，需求相關(guān)的信息也比較多，通常散落在各個地方后期難以查找。
對于 PMO 和開發(fā)組長而言，則需要在多需求并行的情況下快速地發(fā)現(xiàn)某些高風險需求并重點關(guān)注和推進。如何提升需求執(zhí)行效率和降低并行需求管理成本呢?本文將分享馬蜂窩交酒 PMO 團隊是如何通過用自研 的 PMO 系統(tǒng)驅(qū)動過程管理的方式，來降低項目管理的人力成本。
Part.1背景介紹
馬蜂窩大交通和酒店研發(fā)團隊采用雙周 PK 和雙周迭代模式。為了助力高效、透明的研發(fā)流程，團隊成立初期就確立了使用工具來進行研發(fā)項目全周期管理的方式。通過對比后最終選擇了 TAPD 作為產(chǎn)研流程的管理工具，主要是因為 TAPD 具有配置和操作簡便、支持移動辦公、項目間隔離性強等優(yōu)勢。
1.1 需求狀態(tài)和分類
需求分為三類：日常、項目和線上問題。目前主要使用 TAPD 的「需求」功能管理需求，「迭代」功能管理迭代，日常類需求的迭代周期為 2 周，項目類需求的迭代周期為 4 周。
日常和項目需求的狀態(tài)均有以下九種：
圖 1：需求狀態(tài)
1.2 PMO 的日常
1. 組織項目實施
線下的研發(fā)流程其實是個很龐大的矩陣圖，橫軸為需求的 9 種階段，縱軸為 5 種不同角色——項目經(jīng)理(PM)、產(chǎn)品經(jīng)理、開發(fā)、測試、PMO，矩陣圖明確地規(guī)定了對于一個需求而言不同角色在不同階段應該做的事情。在需求處于不同狀態(tài)時，5 種不同角色都有很多細碎的事情要做，比如：
- 準備階段：「待實施」狀態(tài)時，PM 需要為需求相關(guān)人員組建企業(yè)微信群，實現(xiàn)信息及時互通。
- 開發(fā)階段：進入到「開發(fā)中」后，PM 需要每天組織站會并發(fā)送站會紀要到需求的企業(yè)微信群。
- 測試階段：到「測試中」以后，測試需要每天發(fā)送測試日報到企業(yè)微信群。
- 上線后：需求狀態(tài)轉(zhuǎn)為「已上線」后，產(chǎn)品經(jīng)理需要發(fā)送上線周知郵件;轉(zhuǎn)到「線上效果跟進」，產(chǎn)品經(jīng)理需要發(fā)送線上效果跟進郵件。
這些事情中有很多是重復性很強的工作，比如拉微信群等。上述這些不同的信息也會因產(chǎn)生的時間不同、同步的方式不同而非常分散，有的通過郵件，有的是微信群，后期查找起來非常困難。
2. 項目質(zhì)量控制
對于 PMO、開發(fā)經(jīng)理和開發(fā)總監(jiān)而言，同時需要管控多個并行需求的實施質(zhì)量，就需要能快速地獲取到項目執(zhí)行中的風險，比如：
- 每天有哪些項目未通過站會溝通，需要逐個在企業(yè)微信群查找并與 TAPD 中的需求做對比。
- 有哪些需求發(fā)生延期提測或者延期上線，需要逐個在 TAPD 中查找項目的提測和上線狀態(tài)，非常繁瑣而且容易遺漏。
除了需求的落地和多個需求并行管控外，每周產(chǎn)品經(jīng)理們都需要向上級匯報本周的需求上線情況，每周每個業(yè)務線都有需求上線。多業(yè)務線和多負責人使得周報收集和匯總的工作量非常大，有時候難免會有些內(nèi)容遺漏，也不能保證在固定時間發(fā)送。
1.3 PMO 系統(tǒng)設計目標
基于上述在需求管理、風險控制和日常工作中存在的一些問題，交酒 PMO 團隊規(guī)劃并實現(xiàn)了 PMO 系統(tǒng)，以期高效實現(xiàn)需求從實施到上線的全過程管理。PMO 系統(tǒng)的主要目標和定位如下：
- 信息全部需求相關(guān)信息統(tǒng)一在 TAPD 中錄入和管理，包括站會紀要、測試日報、上線周知等。
- 支持多業(yè)務線，不同業(yè)務線的迭代開始時間和迭代周期、不同業(yè)務線對應的郵件組、企業(yè)微信群均可配置。
- 流程提效，包括自動創(chuàng)建企業(yè)微信群，從 TAPD 中查詢站會紀要、測試日報等信息并發(fā)送到企業(yè)微信群，從 TAPD 中查詢上線周知信息并自動發(fā)送郵件等。
- 并行需求管理和風險管控。
- 知識沉淀和管理，包括流程文檔、PM 知識分享等。
- 向上匯報，多業(yè)務線的產(chǎn)品經(jīng)理們在 TAPD 填寫了不同需求的上線周知后，系統(tǒng)自動匯總本周全部上線的需求和上線周知，定時向業(yè)務總負責人發(fā)送周報。
Part.2 主要功能及實現(xiàn)
2.1 整體設計
PMO 系統(tǒng)將過程管理與 PMO 理論相結(jié)合，基于 TAPD 的 API 和企業(yè)微信 API 獲取遠端數(shù)據(jù)進行項目的數(shù)據(jù)擴展，可以同時支持多業(yè)務線的項目過程管理。
PMO 系統(tǒng)的核心就是進行關(guān)鍵信息的收集和高效的處理。具體來說，每個業(yè)務線在項目實施的不同階段，都會通過創(chuàng)建企業(yè)微信群的方式實現(xiàn)實時的溝通和管理。通常來說分為如下幾類：
- 短期群——需求企業(yè)微信群：該需求變?yōu)椤复龑嵤购髣?chuàng)建，需求上線一定時間后群可以解散;群成員包括該需求的產(chǎn)品經(jīng)理和產(chǎn)品組長、開發(fā)人員和開發(fā)組長、測試人員和組長、研發(fā)總監(jiān);后面簡稱為「需求群」。
- 長期群——雙周 PK 企業(yè)微信群：該業(yè)務線參加 PK 會議的全部開發(fā)組長和全部產(chǎn)品;后面簡稱為「雙周 PK 群」。
另外，我們將每個業(yè)務線的郵件組分為研發(fā)組和產(chǎn)品組兩個大組。
所有需求相關(guān)信息都由需求相關(guān)人員錄入到 TAPD 中，PMO 系統(tǒng)自動從 TAPD 中拉取信息并做處理。
PMO 系統(tǒng)主要分為數(shù)據(jù)收集和數(shù)據(jù)處理兩個部分，整體流程圖如下：
圖 2：PMO 系統(tǒng)流程圖
2.2 主要功能實現(xiàn)
PMO 系統(tǒng)實現(xiàn)的功能主要包括：
1.對實施過程進行管理和風險控制，實現(xiàn)迭代管理和需求管理
2.向上管理，拉取一定周期內(nèi)多業(yè)務線上線的需求，并定時給業(yè)務負責人發(fā)送周報
3.數(shù)據(jù)支持，按項目、迭代、季度、人的維度進行工時統(tǒng)計
4.知識沉淀和管理，包括流程文檔、PM 知識分享等
下面我們來看具體的實現(xiàn)方式。
2.2.1 實施過程管理
對實施過程的管理主要分為迭代管理和需求管理。迭代管理主要是幫助 PMO 和管理人員進行并行需求管理和風險控制，需求管理則聚焦對需求實施流程進行提效。
1. 迭代管理
(1) 需求 PK 前后信息匯總
剛剛實行 PK 會議的時候，有些參與 PK 的需求錄入到 TAPD 的時間很晚，與會人員對參加 PK 的需求不是很了解，產(chǎn)品人員花費了很多時間在 PK 會議中講需求，最長的一次 PK 會議甚至開了 3 個小時。
為了解決這個問題，PMO 系統(tǒng)采用開啟數(shù)據(jù)收集定時任務的方式，通過 TAPD API 統(tǒng)一獲取待 PK 類型的需求，并在 PK 前一天下午固定時間發(fā)送到「待 PK」需求列表，幫助參與 PK 會議的開發(fā)、測試人員盡早了解這些需求，提升 PK 會議的效率。并且規(guī)定超過固定時間未錄入到 TAPD 的需求不參加 PK 會議，側(cè)面促進產(chǎn)品人員早日明確自己的需求。
圖 3:「待 PK」需求消息發(fā)送流程圖
圖 4: 發(fā)送「待 PK」需求列表消息示例
PK 會議召開完畢后，當晚 8 點 PMO 系統(tǒng)會獲取最新日常和項目迭代的待實施需求信息，并發(fā)送「待實施」需求匯總消息到「雙周 PK 群」，發(fā)送格式為「需求名稱|產(chǎn)品經(jīng)理姓名|優(yōu)先級」。
兩次 PK 會議之間除了待實施需求、偶發(fā)性的特殊需求和線上問題修復之外，不接受其他需求。
圖 5:「待實施」需求消息發(fā)送流程圖
圖 6:發(fā)送「待 PK」需求列表消息示例
(2) 進行中迭代需求進度匯總
之前當并行需求較多時，想了解整體執(zhí)行情況需要挨個查看 TAPD 中的需求和任務執(zhí)行情況并與計劃時間做對比，這個過程比較耗時。因此每周五晚 6 點 PMO 系統(tǒng)針對不同業(yè)務線的進行中迭代的需求進度、延期情況發(fā)送郵件到該業(yè)務線的研發(fā)組&產(chǎn)品組，并發(fā)送消息到該業(yè)務線的「雙周 PK 群」。協(xié)助 PMO 和管理人員快速識別風險并進行重點推進。
圖 7:需求進度匯總流程圖
圖 8:每周需求進度匯總消息
圖 9:每周需求進度匯總郵件
2. 需求管理
主要有以下三類功能：
- 自動創(chuàng)建企業(yè)微信群
- 自動同步消息和郵件
- 自動提示項目進度
下面詳細介紹。
(1) 自動創(chuàng)建企業(yè)微信群
雙周 PK 通過后，PMO 系統(tǒng)調(diào)用企業(yè)微信 API， 自動為每個待實施的需求創(chuàng)建企業(yè)微信群，更改群名稱為需求名稱-PM XX-PD YY，節(jié)約 PM 創(chuàng)建微信群和邀請人員加入的時間;需求狀態(tài)轉(zhuǎn)為「開發(fā)中」后，自動更改群名稱，增加預計提測時間和預計上線時間。
圖 10: 微信群示意
(2) 自動發(fā)送消息和郵件
PMO 系統(tǒng)可以通過定時掃描需求的評論和識別評論中的關(guān)鍵字自動發(fā)送站會紀要消息、延期風險郵件、上線周知郵件、測試日報和測試報告消息等。
為了讓需求相關(guān)的信息全部都統(tǒng)一放置在 TAPD 中方便后期查詢，并對一些操作進行自動化處理，PMO 系統(tǒng)定義了一些需求評論的模版，相關(guān)人員把所有需求相關(guān)的信息均按模版填寫評論，PMO 系統(tǒng)的數(shù)據(jù)收集定時任務每隔 15 分鐘掃描一次需求評論，識別模版中的關(guān)鍵字后，執(zhí)行各類消息和郵件的發(fā)送。目前共處理 6 類關(guān)鍵字：站會紀要(項目經(jīng)理錄入)、測試日報(測試人員錄入)、測試總結(jié)(測試人員錄入)、延期風險(項目經(jīng)理錄入)、上線周知(產(chǎn)品經(jīng)理錄入)和線上效果跟進(產(chǎn)品經(jīng)理錄入)。
需求狀態(tài)轉(zhuǎn)為「開發(fā)中」之后，由項目經(jīng)理填寫站會紀要到需求評論中，PMO 系統(tǒng)每天上午自動發(fā)送站會紀要消息;需求狀態(tài)轉(zhuǎn)為「測試中」后，由測試人員填寫測試日報，每晚自動發(fā)送「測試日報」;需求狀態(tài)在「開發(fā)中」和「測試中」時，如果項目經(jīng)理填寫了「延期風險」，自動發(fā)送延期風險郵件;需求狀態(tài)轉(zhuǎn)為「已上線」后，由產(chǎn)品經(jīng)理填寫上線周知到需求評論中，PMO 系統(tǒng)自動發(fā)送上線周知郵件。
圖 11: 信息的收集和處理
(3) 自動提示項目進度
一個需求評審結(jié)束的技術(shù)方案設計完畢后，開發(fā)和測試需要在 Wiki 文檔和 TAPD 中利用任務功能進行排期，之后 PM 需要把排期表格拷貝到郵件中，給相關(guān)人員發(fā)送郵件?？截惖倪^程是重復且耗時的?；谶@些問題，PMO 系統(tǒng)通過 TAPD 中需求的狀態(tài)流轉(zhuǎn)實現(xiàn)了自動發(fā)送 Kick Off 郵件、提測郵件、超時控制消息等。這類需求的流程圖如下圖所示：
圖 12: 需求狀態(tài)變更和風險控制
當需求轉(zhuǎn)為「開發(fā)中」，PMO 系統(tǒng)自動拉取該需求的各任務排期并發(fā)送 Kick Off 郵件，如果排期超迭代周期了，則需要走專門的審核流程。需求轉(zhuǎn)到「測試中」，PMO 系統(tǒng)會自動發(fā)送提測郵件。
圖 13: kick off 郵件示例
當需求未按時提測或者未按時上線時，PMO 系統(tǒng)會發(fā)送延期提測和延期上線消息到需求群和雙周 PK 群;當任務未按時完成時，PMO 系統(tǒng)會發(fā)送超時未完成消息到需求群和雙周 PK 群，方便 PM 和 TL 進行風險控制和有針對性的處理。如果需求上線 2 周后未填寫「線上效果跟進」，PMO 系統(tǒng)會發(fā)送超時未跟進線上效果消息到需求群和雙周 PK 群，提醒產(chǎn)品經(jīng)理跟進線上效果。
圖 14: 超時提醒
2.2.2 向上管理
為了節(jié)約產(chǎn)品經(jīng)理在周末再次匯總和編輯本周上線內(nèi)容，以及協(xié)調(diào)不同業(yè)務線產(chǎn)品經(jīng)理編寫周報時間的工作，PMO 系統(tǒng)每周五晚 6 點拉取本周上線的不同業(yè)務線的全部需求和每個需求的上線周知內(nèi)容，給業(yè)務負責人發(fā)郵件匯報本周的需求進度和每個需求上線的效果。
圖 15：上線匯總
2.2.3 數(shù)據(jù)統(tǒng)計
有人經(jīng)常會問 PK 會議時一個迭代究竟接多少需求合適?研發(fā) TL 在制定 KPI 目標時也經(jīng)常會關(guān)注從需求實施效率角度看，當前需要幾人日能完成一個項目類需求，日后目標是減少為多少人日完成一個同等規(guī)模的項目類需求?PMO 系統(tǒng)支持項目類需求按迭代、季度進行統(tǒng)計，給總監(jiān)級別人員做決策時提供數(shù)據(jù)支撐。
圖 16: 數(shù)據(jù)統(tǒng)計
2.2.4 知識沉淀和管理
團隊里經(jīng)常會有新鮮血液加入，PMO 對全員進行流程宣講的頻率還是比較低的，因此 PMO 系統(tǒng)里加入了一些項目流程的基本知識，方便新人熟悉流程和加速流程落地。
圖 17: 知識沉淀
2.3 實現(xiàn)效果
PMO 系統(tǒng)分為 3 期，已全部上線?？偨Y(jié)來看，截至目前實現(xiàn)的主要效果有：
- 信息統(tǒng)一匯總到 TAPD 后，所有人員可以方便地在 TAPD 查詢需求相關(guān)的一切信息，包括評論、站會紀要、測試日報、測試報告、上線周知、線上效果等。
- PMO 系統(tǒng)提煉了全部需求的風險并發(fā)送到微信群，輔助 PMO 和管理人員重點關(guān)注某些高風險需求。
- 自動發(fā)送 Kick Off 郵件、提測郵件、站會紀要，并匯總和提示需求、任務延期風險，可以節(jié)約 PM 大量的時間。
- 自動匯總本周所有上線的所有需求和上線周知并發(fā)送周報給總業(yè)務負責人，節(jié)約了產(chǎn)品經(jīng)理大量的編寫周報時間。
- 幫助開發(fā)人員自動發(fā)送提測郵件，幫助測試人員自動發(fā)送測試日報和測試報告。
- 知識沉淀功能幫助 PM 和新人盡快的熟悉流程和相互學習。
Part.3 未來規(guī)劃
通過 PMO 系統(tǒng)的應用，高效實現(xiàn)了需求從實施到上線全過程管理，盤活資源，實現(xiàn)項目增效。伴隨著 PMO 系統(tǒng)的運行和推廣，我們也在收集用戶反饋并進行系統(tǒng)優(yōu)化。與此同時，DevOps 系統(tǒng)也已經(jīng)開發(fā)完畢并在交通業(yè)務落地。DevOps 系統(tǒng)覆蓋了需求的從開發(fā)中到已上線的 4 個狀態(tài)：
目前，對于延期提測或延期上線風險預警的依據(jù)主要來自對「實際時間」和「預測時間」之間的對比，其中「實際提測時間」、「實際上線時間」等信息是通過 PM 手動維護 TAPD 狀態(tài)變更之后填寫。后續(xù) DevOps 系統(tǒng)將和 TAPD 打通，例如開發(fā)在 DevOps 系統(tǒng)中流轉(zhuǎn)為「已提測」或者「已上線」后，該需求在 TAPD 中自動變?yōu)椤敢烟釡y」和「已上線」，減少人為填寫的不確定因素，PMO 系統(tǒng)統(tǒng)計延期提測和延期上線的需求時就會更加精準。
我們相信，未來隨著 PMO 系統(tǒng) 與 DevOps 的打通，以及與 TAPD 等外部工具更加深度的連接，我們的項目管理將越來越高效，研發(fā)流程將越來越敏捷。
網(wǎng)站欄目：PMO心好累？看馬蜂窩如何用系統(tǒng)驅(qū)動項目管理
本文地址：http://www.5511xx.com/article/cdghoie.html
