一、案例簡述：
去哪兒網(wǎng)作為國內(nèi)領先的在線旅游平臺，13年之后，隨著業(yè)務迅速發(fā)展、研發(fā)團隊規(guī)模也快速擴張。
相應的，如何降低項目管理成本、提升研發(fā)人員工作效率、保證項目交付質量，變得日益重要。
所以我所在的qunar研發(fā)支持團隊，嘗試對“需求——開發(fā)——發(fā)布”整個鏈條中的各種流程、工具、數(shù)據(jù)，進行打通&自動化處理，以此減少研發(fā)過程中的各種浪費，提升整個研發(fā)體系的效率。
二、背景&當時的問題
問題1：溝通協(xié)作成本高：
一起配合開發(fā)的幾個團隊，現(xiàn)在互相都什么進展？什么時候能聯(lián)調(diào)？如果你作為項目經(jīng)理，想準確獲得自己項目的這些相關這些信息的話，當時只能選擇“當面溝通、打電話、聊天群、郵件”等“人肉”方式詢問，不止溝通效率低，還導致開發(fā)同學的工作經(jīng)常被打斷。
問題2：信息不一致
由于各團隊項目信息管理方式、信息存放的載體各不相同，同一個需求，不同時候、問不同的人，得到的信息可能是大相徑庭甚至互相矛盾，如果想對齊信息，又是一波“人肉”確認環(huán)節(jié)……
問題3：缺少工具支撐
當時公司有一套老的項目管理系統(tǒng)，但大家普遍覺得不好用，所以實際上往往還是采用excel+郵件的方式來管理自己團隊的項目，導致在系統(tǒng)中記錄的項目數(shù)據(jù)，跟實際進行的情況差異很大。具體原因如下：
老系統(tǒng)對于研發(fā)生命周期的管理沒有打通，使用時，在開發(fā)過程（需求-計劃-開發(fā)-測試）的每個階段，要分別填寫類似“申請單”的表格進行記錄，而這些表單中很多字段是需要重復填寫的，這對于開發(fā)人員簡直就是“反人類”的設定。
老系統(tǒng)各階段表單，字段非常復雜，以提測環(huán)節(jié)為例，整個表單要填寫幾十個字段和確認項,我們曾經(jīng)做過實驗，僅填寫提測申請單，每次就平均需要花費30多分鐘。
問題4：需求變更
當時qunar每天并行開發(fā)的需求有上百個，一旦出現(xiàn)緊急需求插隊或某個需求變更的情況，對后面需求的計劃調(diào)整、影響關系人識別、影響周知，就是一場災難……
為了解決這些溝通協(xié)作問題，我們設計并實施了去哪兒網(wǎng)的項目管理平臺（基于jira開發(fā)，同時結合研發(fā)過程改進、組織結構優(yōu)化等實踐一并實施）。
在解決項目管理相關問題之后，我們又進一步將項目管理系統(tǒng)同公司原有的工程類系統(tǒng)（GIT、jenkens、CI等）進行打通，從打通“項目管理信息”，提升為打通“產(chǎn)品研發(fā)全過程信息”，幫助研發(fā)工程師可以一站式完成項目全過程的各種操作和相關信息查詢。不止提升研發(fā)效率，還有效減少了信息傳遞不一致導致的人為出錯。
三、如何做的
第一階段：打通項目全過程信息
這個階段主要圍繞降低項目管理成本開展，關鍵目標及實施的主要特性如下：
目標1：減少溝通協(xié)作成本
特性a:為各部門劃分單獨的項目池
qunar的組織結構是BU制，所以首先我們按照部門/團隊的維度來劃分項目池，這樣有幾點好處：
易于理解，大家在錄入項目信息時，只需要在自己所屬部門的項目池內(nèi)錄入就可以了，不用做過多區(qū)分
這樣劃分項目池，體現(xiàn)了組織結構的概念，不同團隊在操作權限、團隊管理上的差異性需求，可以很方便的基于項目池做功能開關
團隊的變化相對穩(wěn)定，項目池調(diào)整維護的工作量比較小，不像按項目劃分那樣，需要經(jīng)常為新項目增加jira項目池
特性b：集中管理全部類型的團隊事務
我們在每個項目池下面，劃分了不同的事務類型，包括：
產(chǎn)品業(yè)務需求
技術優(yōu)化需求
線上問題處理
日常task
測試階段bug
這樣我們就把研發(fā)團隊所有類型要做的事，在一個系統(tǒng)中集中管理起來，好處如下：
統(tǒng)一 “語言&工具”，不像之前那樣，要在不同系統(tǒng)和工具中記錄項目信息，導致不同團隊間溝通項目信息時往往需要各種“翻譯”而產(chǎn)生浪費。
對研發(fā)同學來說，可以一站式管理自己所有類型的任務，統(tǒng)一入口。
后續(xù)做開發(fā)計劃制定、開發(fā)進度跟蹤等項目管理相關活動時，直接基于一個系統(tǒng)生成報表、統(tǒng)計視圖，不會出現(xiàn)跨多個系統(tǒng)做統(tǒng)計時經(jīng)常出現(xiàn)的數(shù)據(jù)不一致問題。
目標2：消除信息搬運的浪費和信息不一致
之前的研發(fā)過程中，不同角色，在研發(fā)流程中的不同環(huán)節(jié)，使用不同工具管理自己的任務信息，如下圖
這樣會導致對于一個需求來說，需要到多個系統(tǒng)中重復錄入需求信息，而且由于系統(tǒng)是多個，還會經(jīng)常出現(xiàn)各系統(tǒng)中信息不一致的情況。
所以我們的做法是在項目管理系統(tǒng)的工作流中，打通研發(fā)流程，一個需求，也就是一次業(yè)務發(fā)布，用一條系統(tǒng)記錄跟蹤到底 。
像下面圖中所示，我們對一條需求記錄，加入了工作流和狀態(tài)的概念，同時所有環(huán)節(jié)的信息，都記錄在這一條系統(tǒng)記錄下面。從需求創(chuàng)建開始，產(chǎn)品先錄入需求，然后流轉給開發(fā)記錄開發(fā)計劃、設計方案，開發(fā)完成后，流轉給測試……隨著項目向后進行，不同角色在工作流相應環(huán)節(jié)，錄入相應環(huán)節(jié)的項目信息 。
這樣就確保了不同角色，對這個需求的信息獲取是一致的，而且也不用像以前那樣，需要在多個系統(tǒng)重復錄入 。
此外，工作流的概念，實際上等于是把公司的研發(fā)流程沉淀在工具中，所以只要大家適應工具后，也就相當于是習慣了公司的開發(fā)流程，這樣流程的實施成本也會大幅降低（之前是需要定期進行研發(fā)流程培訓以及定期檢查，要項目管理人員大量的時間）。
目標3：簡單易用
上面說的都是比較“宏觀”的。但有個很實際的問題：很多公司都搞了一套 “線上的項目管理系統(tǒng)”，但實際上大家往往還是習慣使用excel，不喜歡用官方的項目管理工具，覺得麻煩，時間長了，官方的項目管理工具成了“擺設” 。
原因何在？
我們認為，除了工具的場景設計（工作流、視圖）同實際情況不匹配，還有一個很主要的原因就是工具的易用性不好，所以我們在細節(jié)上，對易用性方面做了很多改進。
改進a：盡量簡化字段和工作流，控制研發(fā)人員使用項目管理工具的時間
首先，工作流中，只保留研發(fā)流程的關鍵環(huán)節(jié)（需求——需求review——計劃——開發(fā)——測試——發(fā)布），盡量減少大家走流程的操作次數(shù) 。
注：最早我們設計的工作流，最長流程一共要走21個狀態(tài)，但我們經(jīng)過反復討論后認為過于復雜，最終核心狀態(tài)精簡到7步
其次，盡量精簡每個環(huán)節(jié)填寫的字段數(shù)量，不要為了項目管理人員的需要，在系統(tǒng)中增加大量的統(tǒng)計分類字段讓大家填寫。
改進b：從用戶角度出發(fā)，提供面向用戶的“自適應”視圖 看板、日歷、面板
如下圖所示，我們除了為管理者提供各種統(tǒng)計視圖外，還設計了各種根據(jù)當前用戶姓名自適應顯示的各類視圖，以方便用戶無需進行復雜的查詢操作，就可以查看自己相關的任務信息。
例1：團隊看板中點擊“我的任務”，即可自適應過濾當前用戶的任務信息
例2：自適應顯示當前用戶相關的開發(fā)項目日歷
例3：自適應顯示當前用戶相關的開發(fā)中項目、過去7天內(nèi)發(fā)布項目等
改進c：在線excel
在線項目管理系統(tǒng)，另外一個比較讓人詬病的，就是批量修改任務數(shù)據(jù)時，往往需要一條條分別編輯、保存，不如excel操作方便
所以我們提供了類似excel的在線表格編輯功能，支持“crtl C+ ctrl V”、“插入/刪除行”、“拖動排序”等常見的excel操作，同時可以編輯后批量提交保存，大大提高了信息錄入的效率。
改進d：批量同步物理看板上的卡片狀態(tài)到系統(tǒng)中
很多敏捷團隊都用“物理白板+卡片”的方式來管理團隊內(nèi)部的任務，但這樣就產(chǎn)生了新問題：大家會很習慣經(jīng)常更新物理看板的卡片狀態(tài)，但線上系統(tǒng)中的任務信息， 經(jīng)常忘了更新。
我們使用了一個jira插件“agile card”解決了這個問題，這個插件可以很方便的批量打印卡片；而且每天站會后（大家會在站會溝通時順便更新卡片狀態(tài)），對物理白板拍照，然后jira中上傳照片，就可以批量更新卡片狀態(tài)跟物理看板一致。（本質上來說，相當于是提供了一種低成本的方式保證物理看板和電子系統(tǒng)中信息一致）。
第二階段：整合研發(fā)工具鏈（數(shù)據(jù)展示+操作入口），提高研發(fā)效率
當我們把項目信息集中管理之后，接下來我們依然從消除浪費、簡單易用兩個角度去進行嘗試，把改進范圍擴大到整個研發(fā)工具鏈，通過把項目信息和工程類系統(tǒng)之間數(shù)據(jù)打通，對研發(fā)過程中的工具鏈進行操作入口整合，來提升工程師的工作效率 。
我們發(fā)現(xiàn)，工程師在項目開發(fā)過程中，同各種工程系統(tǒng)打交道的過程中，依然面臨著“系統(tǒng)間信息不一致”、“信息搬運”、“操作復雜”這些問題，比如下面的場景：
在項目過程中，工程師需要操作大致如下：
首先到項目管理系統(tǒng)創(chuàng)建一條需求記錄。
然后到git去拉分支，開始寫代碼。
接下來每次提交代碼，要到CI平臺下面不同系統(tǒng)中（SONAR、UT、自動化測試、code review等），輸入分支名稱，查看檢查結果。
開發(fā)完成，開發(fā)自測的時候，到發(fā)布平臺，把相關的工程、分支名稱、各種發(fā)布參數(shù)填到發(fā)布平臺，發(fā)完dev環(huán)境。
再回到CI平臺里，不同系統(tǒng)查看 code review、自動化測試、數(shù)據(jù)庫慢查詢報警、sql審核結果。
接下來，提交測試，QA同學也是到發(fā)布平臺，手工把相關的工程、分支系統(tǒng)、各種發(fā)布參數(shù)填到發(fā)布平臺，再去CI里查看各種質量檢查結果。
最后，在整個過程中，開發(fā)、QA還得想著定時去項目管理平臺更新項目狀態(tài)。
總結來看，問題在本質上跟第一階段很類似：
項目各種信息分散，獲取困難。
操作入口多，麻煩，易出錯。
影響工作效率，容易導致流程跳步。
我們的解決方案如下圖，當開發(fā)拉出開發(fā)分支的時候，相應需求的項目管理信息，會和相關的工程信息整合，統(tǒng)一在一個頁面中展示。
如果質量情況出現(xiàn)紅色，可點擊紅色按鈕直接切換到質量詳情頁面。
同之前對比，主要有如下好處：
具體的實現(xiàn)方式
1、數(shù)據(jù)間對應關系
實現(xiàn)上面的效果，最關鍵一步是要把研發(fā)各系統(tǒng)間數(shù)據(jù)打通。而打通數(shù)據(jù)環(huán)節(jié)中，最重要的是建立需求和代碼間的映射關系（因為這兩個概念，屬于兩個維度，之間不具備天然的映射關系）。
我們首先規(guī)定了分支命名規(guī)范，要求所有開發(fā)分支的名稱中必須包含對應需求的jira編號。
然后在后臺增加監(jiān)控程序，當一個新分支拉出時，自動解析分支名稱中的需求jira編號，并把他們直接的映射關系記錄在數(shù)據(jù)庫中。
這樣如下面圖中所示，需求同各類工程類信息之間的映射關系，就完整建立起來了
注：qunar主要的分支策略，是分支開發(fā)、主干發(fā)布，所以對我們來說，大多數(shù)情況，一個開發(fā)分支會對應一個需求。所以我們的分支命名規(guī)范，是基于這個前提制定的。
2、系統(tǒng)結構介紹
當數(shù)據(jù)打通后，剩下的，主要是把各系統(tǒng)的操作界面進行統(tǒng)一，以及用腳本來串聯(lián)各系統(tǒng)間的調(diào)用邏輯，主要做了以下幾個方面
各工程系統(tǒng)，前后端分離、提供API，供互相調(diào)用
用戶交互的部分，重新設計交互和前端，并統(tǒng)一到項目管理系統(tǒng)界面中
專門開發(fā)一個消息中心IC，用于各系統(tǒng)間通信（類似事件廣播的方式進行通信），任何一個系統(tǒng)發(fā)生變化時，會“廣播”發(fā)出一條事件，其他系統(tǒng)監(jiān)聽到這條事件后，根據(jù)自身邏輯做相應處理
專門做了一個數(shù)據(jù)中心DC，把各系統(tǒng)數(shù)據(jù)，匯總到一個庫里提供一站式查詢，這樣各系統(tǒng)需要讀取其他系統(tǒng)數(shù)據(jù)時，可以直接到數(shù)據(jù)中心DC中獲取完整的數(shù)據(jù)，而不用到各系統(tǒng)中分部調(diào)取
CI相關系統(tǒng)，為了要滿足快速檢查代碼質量、實時反饋的需求，要持續(xù)對速度做優(yōu)化，正常情況，各檢查點要做到分鐘級反饋質量檢查結果
四、總結&思考
關于項目管理平臺，首先應該滿足大家“把項目管好”的需求，對于一線研發(fā)人員來說，系統(tǒng)簡單、易用永遠是第一位的，其次才是管理層的各種“統(tǒng)計度量”需求。如果為了給“老板”做各種報表，要求大家花時間在系統(tǒng)中填寫很多分類字段，這樣反而是本末倒置。也正是因為我們從這個角度出發(fā)去設計工具，才使得上線后等得到一線業(yè)務團隊的認可并迅速推廣。
系統(tǒng)的設計，要結合公司的實際情況，匹配大家日常執(zhí)行的研發(fā)過程。比如我們的項目池劃分、工作流狀態(tài)、系統(tǒng)字段，都是根據(jù)qunar的特點，重新定義的，這樣大家使用項目管理系統(tǒng)時才不會有“陌生感”，系統(tǒng)才能起到承載公司研發(fā)流程的作用。
當團隊規(guī)模變大之后，這時管理層往往需要從系統(tǒng)中獲取數(shù)據(jù)，來實現(xiàn)對團隊各方面狀態(tài)的報表可視化。這種管理需求是正常的，但這時，不能只考慮管理需求，應該要同時考慮是否會導致團隊的項目管理成本上升（比如各種字段的填寫、檢查、確認），所以用自動化手段獲取所需的統(tǒng)計數(shù)據(jù)，往往是我們最好的選擇（比如我們就根據(jù)開發(fā)的工程操作軌跡，自動統(tǒng)計項目的開始開發(fā)、測試、發(fā)布時間、發(fā)布/回滾次數(shù)等項目管理需要的信息）
無論是項目管理系統(tǒng)，還是工程類系統(tǒng)，都應該遵循一個原則：即讓用戶少花時間做低層次操作（比如各種拷貝、粘貼，各種人肉切換、查詢），消除各種人為等待。這樣才能讓研發(fā)人員能把更多精力放到“設計”、“編碼”這類高層次的腦力活動上，從而提升研發(fā)效率。
好的研發(fā)工具只是建設團隊的一方面，在實施過程中，往往需要配合組織結構、流程、文化建設等多方面，才能有效改進（比如我們在實施項目管理平臺過程中，還要并行開展全功能團隊建設、需求拆分等其他方面實踐）。(本文于2017年發(fā)布)
