作者介紹：宋培培，去哪兒網過程改進組和研發項目管理平臺負責人。
案例背景
去哪兒網作為國內領先的在線旅游平臺，在2013年之后，隨著業務迅速發展，研發團隊的規模也快速擴張。隨之而來的如何降低項目管理成本、提升研發人員工作效率、保證項目交付質量等問題變得日益重要。
我所在的qunar研發支持團隊，嘗試對“需求-開發-發布”整個鏈條中的各種流程、工具、數據進行打通及自動化處理，以此減少研發過程中的各種浪費，提升整個研發團隊的效率。
采用Jira之前存在的問題和痛點
問題1：信息不一致，溝通成本高
不同的團隊有各自特定的溝通方式、工具和記錄載體，當需要查詢信息的時候，需要多方的配合，得到的信息可能會大相徑庭甚至互相矛盾，如果想校準信息，往往通過“人肉”確認，溝通成本高……“配合開發的幾個團隊目前有什么進展？” “什么時候能聯調？” 在當時，作為項目經理想準確獲得自己項目的這些相關信息只能選擇當面溝通、打電話、聊天群、郵件等“人肉”方式詢問。
這樣的結果是：不但溝通效率低，還導致開發人員的工作經常被打斷，影響生產力。
問題2：老系統對研發生命周期（ALM）信息沒有打通，重復錄入，改造成本高
當時公司有一套老的項目管理系統，字段配置復雜繁瑣，各部門所以實際上還是各自采用“Excel+郵件”的方式來管理自己團隊的項目，導致在系統中記錄的項目數據跟實際進行的情況差異很大。
具體原因如下：
○老系統對ALM的管理沒有打通，造成字段信息重復錄入，使用時，在開發過程（需求-計劃-開發-測試）的每個階段要分別填寫類似“申請單”的表格進行記錄，而這些表單中很多字段是需要重復填寫的，這對開發人員來說簡直就是“反人類”的設定。
○老系統各階段表單，字段非常復雜。以提測環節為例，整個表單要填寫幾十個字段和確認項。我們曾經做過實驗，僅填寫提測申請單，平均每次需要花費30多分鐘。很多時候開發和測試部門之間通過口頭來交流溝通，對項目缺少了信息的一致性和完整性。
問題3：項目狀態可視化程度低，管理成本高
當管理團隊需要對這個部門經營的項目有哪些，有個全局的了解，就需要項目經理一個個統計，需要花費1-2天時間，而且有時因為迭代需求隨時在變化，往往統計出來的結果與實際進度不一致。
當有需求變更的時候，需要一個個人去通知。當時去哪兒網每天并行開發的需求有上百個，一旦出現緊急需求插隊或某個需求變更的情況，對后面需求的計劃調整、影響關系人識別、影響周知，都是一場災難……
系統選型
在選擇繼續開發老的項目管理系統還是選擇商業軟件之間，我們衡量了開發的成本和能否實現高效團隊協同，最后決定選擇Jira系統。因為它配置的靈活度，根據公司具體情況和流程和字段的定義進行配置，Jira還有強大的API接口功能，滿足我們對二次開發的需求。用最少的開發資源，最快的響應速度，我們很快上線了Jira項目管理系統。
解決方案
為了解決這些溝通協作問題，我們設計并實施了去哪兒網的項目管理平臺（基于Jira開發，同時結合研發過程改進、組織結構優化等實踐一并實施）。
在解決項目管理相關問題之后，我們又進一步將項目管理系統同公司原有的工程類系統（GIT、Jenkins、CI等）打通，從打通“項目管理信息”，提升為打通“產品研發全過程信息”，幫助研發工程師一站式完成項目全過程的各種操作和相關信息查詢。這一解決方案不止提升研發效率，還有效減少了信息傳遞不一致導致的人為出錯。
整個解決方案分兩個階段實施。
第一階段：打通項目全過程信息打通
這個階段主要圍繞降低項目管理成本展開，關鍵目標及實施的主要特性如下。
目標1：減少團隊溝通成本
特性a：為各部門劃分專屬項目池
去哪兒網的組織結構是BU制，每個BU看做一個獨立的項目管理平臺，按照部門/團隊的維度來劃分項目池。對Jira管理員的維護成本減低很多。一個BU一個部門，對應一個項目池，權限和規則每個項目池可以獨立設置。錄入項目信息時，只需要在自己所屬部門的項目池內錄入就可以，不用做過多區分。為了滿足特定化的功能，有二次開的，特定字段基于項目池來做管理、展示和限制條件。
項目池劃分
特性b：集中管理各類型事務
根據實際工作中的需求集中管理各任務類型，包括業務需求、技術需求、線上問題、日常任務等等。
目標2：消除管理浪費
這樣就把研發團隊要做的所有類型的事情在一個系統內集中管理和對應起來：
○統一管理和報表分析：業務類型做了統一定義和字段，形成統一標準，根據項目池數據有個沉淀的過程，基于這些數據看到項目開發進度、效率和數量進行進一步的分析。
○統一入口：對研發人員來說，可以一站式管理自己所有類型的任務，統一入口。
○統一數據：后續做開發計劃制訂、開發進度跟蹤等項目管理相關活動時，直接基于一個系統生成報表和統計視圖，不會出現跨多個系統做統計時數據不一致的問題。
目標3：易用性
根據去哪兒網的標準研發流程，配合Jira工作流，沉淀下來的工作流狀態，每個階段有統一標準和認識。
○在Jira系統里，根據不同的狀態，設置了不同的tab，方便用戶在不同狀態下錄入信息。每個階段看到每個階段的信息，對信息的查詢管理和操作比較清晰明了
○簡化了流轉的狀態和填寫字段，最后沉淀下來只有這六個狀態：需求-需求Review-排期-開發-測試-發布
○從用戶角度出發，減少用戶學習成本，設置了按用戶身份“自適應”的視圖-看板、日歷、面板
在“我的項目”里顯示該用戶在不同階段的信息，可以一目了然。還可以根據不同業務線配置不同查詢類型，看板的配置。
Mail.Ru Calendar 插件能夠看到我們在一個月項目的排期，按日歷展示，按列表展示。
○在線Excel。在線項目管理系統另外一個比較讓人詬病的地方是：批量修改任務數據時，需要一條條分別編輯和保存，不如Excel操作方便。因此，這里提供了類似Excel的在線表格編輯功能，支持Crtl+C插入行，Ctrl+V刪除行、拖動排序等常見的Excel操作，同時可以在編輯后批量提交和保存，大大提高了信息錄入的效率。自適應顯示與當前用戶相關的開發中項目、過去7天內發布項目等在線表格編輯功能展示
○批量同步物理看板上的卡片狀態到系統中。很多敏捷團隊都用“物理白板+卡片”的方式來管理團隊內部的任務，但這樣就產生了新問題：大家習慣更新物理看板的卡片狀態，但線上系統中的任務信息卻經常忘了更新。
這里使用一個Jira插件“Agilecard”解決了這個問題，這個插件可以很方便地批量打印卡片。每天站會后（站會溝通時會更新卡片狀態）對物理白板拍照，然后在Jira中上傳照片，這樣就可以批量更新卡片狀態，使之跟物理看板保持一致。本質上來說，相當于提供了一種低成本的方式保證物理看板和電子系統中信息一致。
第二階段：項目信息同工程信息打通
統一研發全流程各類操作入口，提高研發效率
在實現了項目信息的集中管理后，接下來仍然從消除浪費、簡單易用兩個角度去進行嘗試，把改進范圍擴大到整個研發工具鏈（數據展示+操作入口），通過把項目信息和工程類系統之間的數據打通，以及對研發過程中的工具鏈進行操作入口整合，來提升工程師的工作效率。
我們發現，工程師在項目開發過程中，以及同各種工程系統打交道的過程中，依然面臨著系統間信息不一致、信息搬運和操作復雜等問題。
解決方案如圖所示，項目信息和工程信息間建立映射關系，在同一個界面可以執行項目研發過程中所有的信息和任務。當開發拉出開發分支的時候，相應需求的項目管理信息會和相關的工程信息整合，統一在Jira平臺上就能操作所有信息，統一了入口自動關聯，集中展示。
○自定義上線步驟。
○匯總工程、分支等工程信息。
○點擊超鏈接可直接跳轉到各工程系統。
○代碼質量結果實時預警。
○點擊按鈕執行發布操作，直接跳轉到發布平臺。
○“一鍵群聊” 直接調取創建即時溝通工具，實時溝通。
○“發布周知”調用郵件系統自動發送郵件。是公司規定每個項目發布之前要有一個發布周知郵件。
如果質量檢查結果有問題，右側“！”圖標，會變成紅色，然后用戶可點擊紅色按鈕，直接切換到質量詳情頁面。
EazyBI插件，沉淀了幾年的信息可以做報表分析，數據呈現，項目個數，周期和質量等維度進行分析。
新舊系統對比
實現方式1：數據間對應關系
實現上文中提到的效果，最關鍵的一步是要把研發各系統間的數據打通。而在打通數據的環節中，最重要的是建立需求和代碼間的映射關系。這兩個概念屬于兩個維度，它們之間不具備天然的映射關系。
首先規定分支命名規范。要求所有開發分支的名稱中必須包含對應需求的JIRA編號。{2[因為去哪兒網主要的分支策略是分支開發和主干發布，所以對我們來說，大多數情況下，一個開 發分支會對應一個需求。因此，我們的分支命名規范是基于這個前提制訂的。]}
然后在后臺增加監控程序。當一個新分支拉出時，自動解析分支名稱中的需求JIRA編號，并把它們之間的映射關系記錄在數據庫中。
如圖所示，這樣需求同各類工程類信息之間的映射關系就完整建立起來了。
映射關系
實現方式2：系統結構介紹
數據打通之后，剩下的工作主要是把各系統的操作界面進行統一，以及用腳本來串聯各系統間的調用邏輯。針對這一點我們做了以下幾個方面的工作（如圖所示）。
○各工程系統前后端分離、提供API，供互相調用。
○用戶交互的部分重新設計交互和前端，并統一到項目管理系統界面中。
○專門開發一個消息中心（IC），用于各系統間通信（類似事件廣播的方式進行通信），任何一個系統發生變化時，都會“廣播”發出一條事件，其他系統監聽到這條事件后，會根據自身邏輯做相應處理。
○專門做了一個數據中心（DC），把各系統數據匯總到一個庫里提供一站式查詢，這樣各系統需要讀取其他系統數據時，可以直接到數據中心獲取完整的數據，而不用到各系統中分別調取。
○持續集成相關系統，為了滿足快速檢查代碼質量、實時反饋的需求，要持續對速度做優化，正常情況下各檢查點要做到分鐘級反饋質量檢查結果。
系統結構
總結與思考
（1）項目管理平臺首先應該滿足“把項目管好”的需求。對一線研發人員來說，系統簡單、易用永遠是第一位的，其次才是管理層的各種“統計度量”需求。如果為了給老板做各種報表，要求員工花時間在系統中填寫很多分類字段，這樣反而是本末倒置。
（2）系統的設計，要結合公司的實際情況，匹配大家日常執行的研發過程。比如，文中的項目池劃分、工作流狀態、系統字段，都是根據去哪兒網的特點重新定義的，這樣員工使用項目管理系統時才不會有陌生感，系統才能起到承載公司研發流程的作用。
（3）當團隊規模變大后，管理層需要從系統中獲取數據來實現對團隊各方面狀態的報表可視化。這種管理需求是正常的，但不能只考慮管理需求，應同時考慮是否會導致團隊的項目管理成本上升（比如各種字段的填寫、檢查和確認等），所以用自動化手段獲取所需的統計數據是最好的選擇。
（4）無論是項目管理系統，還是工程類系統，都應該遵循一個原則：讓用戶少花時間做低層次操作（如各種復制和粘貼，各種“人肉”切換和查詢），消除各種人為等待。這樣才能讓研發人員把更多精力放到設計和編碼這類高層次的腦力活動上，進而提升研發效率。
（5）好的研發工具只是建設團隊的一方面，實施過程中還需要配合組織結構、流程、文化建設等。多方面齊頭并進才能有效建設和改進團隊。比如，在實施項目管理平臺過程中，還要并行開展全功能團隊建設、需求拆分等其他方面實踐。
本文內容參考《管理智慧：成功研發團隊的18條管理啟示》
