上一篇文章《DevOps｜產(chǎn)研運協(xié)作工具鏈上的皇冠-項目管理工具》主要講了項目管理工具對軟件研發(fā)的重要性，本篇文章主要想講清楚我們需要什么樣的項目管理工具，項目管理工具必須具備的功能有哪些，以及如何選擇最適合自己的那一款。

部署方式：SaaS化 or 私有部署

這是一個首先要回答的問題。如果你所在的企業(yè)有非常苛刻的數(shù)據(jù)安全、保護、大量定制開發(fā)、信創(chuàng)軟件合規(guī)要求等，那么只能選擇支持私有部署的軟件。SaaS軟件無法滿足你的這些要求。私有化部署也會帶來成本高昂，需要專業(yè)人員支持等問題，這也是要同時考慮的事情。「欲戴王冠，必承其重」。

除了部署方式之外，我們考慮最多的就是產(chǎn)品的功能。

根據(jù)公司實際情況選擇工具

說話要講究場合，做選擇要考慮場景。在大公司從自己的環(huán)境中長出一個適合自己的項目管理工具是最好的，是適配的，也是合理的。但是對于很多中小公司，沒有這個實力和無法支付這樣的成本去自研一款自己的項目管理工具，那么去市面上找到一款適合自己的工具就是正確的選擇。所以我們要有個清楚公司的定位，我們是什么樣的公司，處于什么樣的階段，需要什么樣的功能。

對于中小公司來說，除了功能之外還有一些需要考慮

• 產(chǎn)品成熟度。如果產(chǎn)品成熟度太低，雖然一些功能滿足，但是還有大量的需求沒有滿足，選這樣的工具就不是一個好的選擇。

• 使用成本：功能很好，用得很棒，但是軟件太貴了，企業(yè)無法承擔，這樣的工具也不是你的選擇；這里所說的成本不僅僅是購買軟件license 的成本，還包括硬件、安裝、調(diào)試、培訓的成本。比如某些行業(yè)用 jira多，行業(yè)屬性非常明顯，那么你采購 jira 成本就很低，只是軟件license 和安裝的成本，后面的培訓、遷移都會水到渠成。不用你參與，用戶就能找到最適合自己的方式。  

需求拆解成用戶故事

項目管理工具需要支持把用戶需求文檔拆解成一個個獨立上線的對用戶有價值、容易理解的用戶故事（User Story）的活動。

通常來說我們的用戶需求文檔（PRD）會以一個在線文檔的形式存在，有利于撰寫、修改、協(xié)作和評審。PRD有大有小，優(yōu)先級有高有低，這個時候我們就要把 PRD 拆解成一個個用戶故事錄入到項目管理工具中去。如果項目管理工具不支持用戶故事，那拆分粒度就會變成一個需求文檔，這對工作量評估和后續(xù)跟進就會是很大的挑戰(zhàn)。一個需求關聯(lián)很多任務，周期長短不一，導致這個需求久久不能完全全部完成。

UserStory001: 作為用戶，當我輸入正確的用戶名和密碼后點擊「登錄」按鈕后就可以登錄系統(tǒng)，以便于進入系統(tǒng)中我的工作臺

項目排期

當我們把需求拆分成一個個用戶故事后，這個時候我們就可以綜合考慮用戶故事優(yōu)先級，團隊速率等因素，對用戶故事進行排期，把用戶故事放到一個個 sprint 中去，有節(jié)奏地交付。

如果不按照 sprint 交付，設置了交付截止日期的用戶故事，實際上也是一種排期的形式。

UserStory001，優(yōu)先級P0，2人天，涉及前端和后端的修改

用戶故事拆分到任務

一旦用戶故事的排期確定了，我們就要把用戶故事拆分成多個工作任務，評估工作量，然后分配到具體負責的人。

用戶故事是按照對用戶價值的完整性進行拆分的，我們還需要按照概要設計、詳細設計文檔中的的技術方案把功能涉及到的項目的實際模塊、涉及到變更的范圍進行更細粒度的拆分。比如一個上面的用戶故事就需要前端和后端兩個團隊的協(xié)作。更多可參考《敏捷任務拆解、工作量評估和指派》

任務進度看板/敏捷看板

任務看板可以把進度可視化、團隊協(xié)作透明、任務跟進和梳理，且可以通過支持不同的視圖，讓我們可以從不同的維度去審視我們的項目、團隊和人員。具體可參考《敏捷開發(fā)之任務看板》

工作進度跟進和流程定制

從需求澄清到價值交付是一個很長的過程，中間還涉及到 coding、code review、building、testing等很多環(huán)節(jié)。但這段過程實際上是很難跟進的，也非常的不規(guī)范。這個時候我們就可以利用一些工具來自定義我們團隊的工作流，來適合我們團隊的實際情況。

比如我們的每個工作待辦需要有：to-do, doing, testing,released 幾個狀態(tài)，此時有一個用戶故事，拆解成了兩個工作待辦

當我們通過git 提交的代碼關聯(lián)到其中一個工作待辦時，這個工作待辦的狀態(tài)自動從「to-do」變成「doing」

當我們把代碼 MR 到 Master 上的時候，這個工作待辦的狀態(tài)自動從「doing」變成「testing」

當Master 上的代碼發(fā)布上線后，這個工作待辦的狀態(tài)自動從「testing」變成「released」

同時工作待辦對應的用戶故事進度變成 50%，如果另外一個工作待辦也上線了，那么用戶故事的進度就是100%

數(shù)據(jù)驅(qū)動決策

正是因為產(chǎn)研運整個流程很長，很難簡單地說清楚產(chǎn)品整體什么狀態(tài)，每個人現(xiàn)在具體做什么，對整體的影響、做到了什么程度，進度如何。這個時候我們就可以通過各種報告和儀表盤，了解到項目的整體健康狀況、進展和可能的問題。數(shù)據(jù)驅(qū)動決策（Data-Driven Devision-Making）

效能度量

在這一點上，很多工具都做得不是很好，好在現(xiàn)在的很多先進的工具都可以通過拖拽、設置維度和周期生成一些簡單的度量看板。但是現(xiàn)在很多項目管理工具的主要使用場景還是在任務協(xié)同，雖然可以通過插件/hooks集成一些其它的工具，但是還是無法形成全鏈路的一個工具聯(lián)動，有些數(shù)據(jù)難以獲取和及時更新。研發(fā)效能度量道阻且長。

項目管理百花齊放

做到上面的功能就是一款不錯的產(chǎn)研項目管理工具了么？不。具有上面的功能只能說剛摸到產(chǎn)研項目管理工具的門檻，想要成為「不錯」的工具還差得很遠。現(xiàn)在我們的很多工具很有特色，但是也只是在一兩個點上做得不錯。

• 我喜歡 upbase的簡潔清爽，它卻支持一個workspace有多個board，搞得又有點大了。我個人貌似不需要聯(lián)合項目。

• 我喜歡 asana 的漂亮，又覺得有些功能做得復雜了

• 我喜歡Clickup 貼心的功能引導，吸引我把其它地方的任務導入進來，在這一點上其它任何工具做得都不如它。

• 相對于青春靚麗的 asana，monday就顯得有點老氣了

• 我最喜歡的還是 Team+Kone 的合體，絲一般順滑

很多時候，我們考察一個工具要看療效，不能只看廣告。到底這個工具帶來什么樣的價值，要在實踐中體現(xiàn)出來。

團隊內(nèi)高內(nèi)聚，跨團隊低耦合

就像上篇文章中所講項目管理工具就是一個公司管理層思維方式和管理手段的體現(xiàn)。在項目管理工具上，我們也期望能做到「高內(nèi)聚、低耦合」。每個團隊內(nèi)部管理好自己團隊內(nèi)部的事務，跨團隊之間的耦合要低。A團隊小朋友AA要關注B團隊的某個任務，這樣的場景，我認為要仔細分析其合理性。如果僅僅是AA小朋友給B團隊提了個bug，B團隊用不了多久修復就能上線了，關注與否沒太大意義，除非這個bug block你的工作了。真的block很多人的工作，那就不是bug而是事故了。概率太低；如果AA小朋友給B團隊提的是個需求，應該由B團隊去評估；這兩種情況都應該相信B團隊的判斷，在其團隊內(nèi)部處理和消化。

跨團隊協(xié)作需要PMO和項目聚合

對于跨團隊之間的拉通和對齊，項目進展的更新，一般需要兩個團隊業(yè)務負責人FTO的周期性同步；如果項目較大，可能需要PMO同學的協(xié)助，同時需要「項目集」把項目狀態(tài)、進展和風險暴露出來。這個時候會議上同步的信息已經(jīng)不是具體某一個工作任務的狀態(tài)，而是整個項目整體的狀況。通用的項目管理工具很難支持，但是支持軟件研發(fā)領域垂直的項目管理工具就考慮到了這一點。

棒棒的用戶體驗和高效的任務管理

對于項目管理工具，我主要考察兩點：用戶體驗和高頻動作的高效性。用戶體驗很差的工具通常在工作的高效性上做得也不是很好。心情受到了影響肯定會影響到工作，體現(xiàn)在工作上就是效率低。用戶體驗好的工具，至少讓我有更高的忍耐度。我可以容忍其某些非關鍵功能方面的缺失，愿意伴隨其一起成長。漂亮的UI、絲滑的交互、超出用戶預期的實現(xiàn)、時不時的一點小驚喜，那么地讓人愛不釋手，誰又能拒絕呢？

本文小結(jié)

我們要從功能和非功能等多方面來考察一個項目管理工具。對于產(chǎn)研運的小伙伴來說，項目管理工具是每天都要打交道的工具，其工具的用戶體驗和是否高效，影響著每位小伙伴的工作。我們要慎重選擇。同時也期望公司的各位專家們能從自己專業(yè)的角度出發(fā)給出專業(yè)的意見和建議。一旦我們選擇了一款工具，不妨「先僵化、后固化、再優(yōu)化」，用它一段時間看看效果再說。

閱讀我的更多文章

DevOps｜產(chǎn)研運協(xié)作工具鏈上的皇冠-項目管理工具
DevOps｜研發(fā)提效-敏捷開發(fā)之每日站立會
DevOps｜研發(fā)提效-敏捷開發(fā)之任務看板

DevOps｜研發(fā)提效-敏捷任務拆解、工作量評估和指派
高效能敏捷交付團隊反思：特性團隊(FeatureTeam)+Scrum