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

2022 年 11 月 11 日
筆記
唐虞閣, 團隊管理

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

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小時產出的任務。員工只需要儘力去完成就好，不必非要做完安排的所有任務，未完成的挪到下一周即可。管理層會看到長期的任務數據並自有評價，員工只需要儘力而為即可，不需要全力以赴。我們鼓勵員工輕鬆、快樂的工作。