程式設計師團隊如何做好專案管理？十年管理經驗，真實案例分享

我們團隊目前已經可以做到：

bug很少，大約只有同水平技術團隊1/3的bug率；
溝通很少，幾乎只有同級技術團隊的1/4；
加班很少，因為可以隨時準確掌控專案進度，大多數情況下都可以協商解決，避免加班；
在家辦公。

下面，我就通過一個真實的頁面開發的例子，給大家毫無保留的展示我們團隊的專案管理過程。

00. 例子

本文中使用的例子頁面的原型如下圖所示：

這個頁面的功能主要是，允許企業自己的管理員新增、刪除其他管理員。

01. 編寫API檔案

這個原型對應的前端頁面總共需要呼叫3個API，分別是：獲取全部企業管理員、新增管理員、移除管理員。

在我們團隊，API檔案都是由專案經理編寫的。

首先讓我們看一下第1個API編寫完成後的效果，如下圖：

第1個API檔案的原始碼如下圖所示：

可以看到這個API的原始碼非常簡單，並且在intellij idea中編輯，可以複製貼上+智慧提示，編寫速度超快。

請注意上方的API原始碼截圖中畫紅線的地方，我們專案經理在編寫API檔案的時候，就會把一些注意事項（包括特殊的演演算法）寫到API檔案中，並隨API檔案一直維護下去。這個動作，幾乎不會增加專案經理的時間，但卻非常可觀的幫助後端開發人員避免寫出bug。

我們專案經理甚至在API檔案中把參考程式碼都寫出來了，目的就是為了避免被問問題。為什麼我們團隊溝通這麼少呢？因為專案經理把大家可能遇到的問題都提前想到了，並且寫到檔案裡面了。

我們團隊會去刻意訓練每一個專案經理的思維習慣，在寫檔案的時候，一定要站在閱讀者/開發者的角度去儘可能多的提前考慮到可能出現的問題，然後把答案寫到檔案裡面，從而避免溝通減少bug。

下面，我再貼一下第2個API的呈現效果截圖：

第2個API的原始碼截圖如下：

第3個API我就不放呈現效果圖了，貼一下原始碼吧，如下圖：

02. 編寫需求

在我們團隊，專案經理會按照產品原型中的頁面結構，1:1錄入需求。我們團隊多年總結的經驗是：原型只承載介面，以及顆粒較大的且改動可能性較低的文字需求，而線上需求檔案負責承載細粒度需求以及改動可能性較大的需求，以及開發需要的一切資源（不僅限於API檔案）。

在這個指導思想下，專案經理最終完成的本文中的這個例子的需求檔案如下圖所示：

從上圖中可以看出，本文中的例子頁面的需求檔案包括了四個部分：

本頁面需要呼叫的API（點選連結直接跳轉API詳情），開發人員再也不用問更不用猜調哪個API了；
開發需求，包括前端和後端需求；
重點中的重點：測試用例。測試人員將通過這個需求下面的測試用例來驗收本需求衍生出的所有任務和bug。

請大家再次仔細看看我們這個頁面的測試用例：

總共寫了4個用例，每一個用例都是特別容易出bug的。可以想象，如果我們專案經理沒有寫這4個用例，那很有可能到時就是4個bug，大大拖垮了整個團隊的工作效率。

現在，我們專案經理寫出了這4個測試用例，這個頁面開發後很有可能前後端加起來一個bug都沒有，在我們團隊這都是常事。「一個bug都沒有」，這會給專案經理、前後端開發人員極大的信心和極佳的工作體驗，大家都會感覺自己是在跟一群聰明的人一起工作。

03. 建立開發任務

我們專案經理將這個頁面拆分成了4個開發任務，一個前端開發任務，3個API開發任務（當然也可以將3個API任務合併到一個任務）。

先看看前端開發任務的建立介面：

注意上圖中畫紅框框的地方：只有第2個測試用例是需要前端開發人員完成的；任務並無具體指派人，但評估的標準產出是2.5小時，這個2.5小時就是一個行業中等偏上的程式設計師完成這個頁面開發所需要的時間。

接下來我們以開發人員視角看看這個任務詳情，如下圖所示：

我們再來看看後端開發任務的建立，如下圖所示：

開發人員視角：

4個開發任務都建立完成之後，我們再回到該頁面的需求檔案，可以看到這個需求下面已經有關聯4個開發任務了，如下圖：

以後不管過了多久，我們想要知道曾經有哪些人蔘與過這個頁面的開發，都可以在需求檔案裡面找到歷史記錄。

至此，你便可以發現，我們團隊每個開發人員在開發功能的時候，幾乎是不需要問問題的，更不需要跟誰討論。所以我們團隊的工作溝通很少很少，大家上班期間幾乎都是一邊寫程式碼一邊聊八卦。

04. 指派開發任務

專案經理通常會將一個版本的全部需求一次性錄入系統，同時將所有開發任務建立好，然後每週末指派下一週的任務。

當專案經理把一個版本的任務全部建立之後，就可以從唐虞閣系統中看到這個版本總的工作量分佈，如下圖所示：

這也是我們團隊加班很少的主要原因之一：因為專案進度能夠準確控制，確實資源不足的時候我們大多數時間都可以延期。

在我看來，幾乎所有的開發團隊都是寧願加班也不願意延期的，我認為最根本的原因並非老闆想要壓榨大家，而是管理者拿不出一個可信的資料給老闆看，老闆自然覺得大家的工作量還可以擠一擠。

有時，我們也無法做到延期，但這個時候我們基本上都能砍掉一小部分需求移到下一次迭代裡面去，儘量把沒有安排的加班時間留足，這樣專案進度質量的風險就會更小一些。

回到正題。

專案經理建立完一個版本（迭代）的所有開發任務後，下一步就是指派任務。注意哦，我們每個任務的標準產出是在指派任務之前就評估的哦，所有這才是一個標準的數位。

指派操作我就不截圖了。

任務指派後，開發人員登入唐虞閣系統，只需要關心專案經理指派給自己的當前這一週的任務，其他的任務都不必關心，如下圖所示：

開發人員只需要按照這個任務列表，一個一個完成任務即可。

所以我們團隊經常在家辦公。

寫到這裡，我想給大家分享一個我們團隊很有價值的經驗。

就是專案經理每週末整理任務狀態的時候，會把未完成未驗收的任務全部挪到下一週，只有已完成且已驗收的任務才會放到當週。這樣做是為了讓開發人員永遠不需要關心上一週及之前的任務，永遠只需要關心當前這一週的任務即可。

除此之外，專案經理在安排每一週的任務的時候，會稍微給員工多安排一點任務。比如，某個初級員工一週大概只能完成15小時標準產出的任務，那麼專案經理在安排任務的時候，可能就會安排到20小時產出的任務。員工只需要盡力去完成就好，不必非要做完安排的所有任務，未完成的挪到下一週即可。管理層會看到長期的任務資料並自有評價，員工只需要盡力而為即可，不需要全力以赴。我們鼓勵員工輕鬆、快樂的工作。