本文首發於唐虞閣微信公眾號，歡迎轉載，轉載請註明來源，否則將追究侵權行為。

我從2011年開始帶團隊，這其實是第11個年頭了，這些年大大小小的團隊帶了不少，也見識過各種各樣的「人才」。

我沒有進過大廠，所以本文僅僅是我個人這些年摸索出來的一點經驗和思考，對於迷信大廠迷信權威的讀者來說本文可能不值一讀。

雖然本文僅僅是我個人的一些經驗和思考，我也沒有任何名氣，但我保證你能從本文中讀到許多以前可能從未觸碰過的觀點，這些觀點不一定對，但一定與你在其他管理學書籍中讀到的不一樣。無論你是贊同還是反對，你都將獲得一個新的角度看待團隊管理。

全文1.6萬字，第二篇內容比較抽象、晦澀，建議收藏分次閱讀，閱讀中懷疑、懷疑中思考、思考中獲得。我希望讀者朋友們能夠保持懷疑、開放、獨立思考的能力的閱讀本文，這樣你才可能收穫更多

 

第一篇 專案管理

專案管理，即管事，對事負責。

第1章、需求管理

需求管理分為三部分：需求檔案管理、功能頁面需求管理、測試用例管理。

1. 檔案管理

檔案管理首先要實現各種需求檔案的統一管理，不要到處都是檔案，需要的時候卻找不著。

其次是檔案的即時更新。比如我們跟甲方溝通過程中的需求檔案，從一開始到籤合同，中間可能產生了很多個版本，我們需要將這些版本都統一管理到一起。如下圖所示：

 除了需求檔案，專案開發資源其實也應該管理到一起，比如伺服器資源、賬號、開發指南，等等等等。如下圖：

2. 功能需求管理

功能需求，即頁面需求。我們一個軟體專案，最終都是會被拆分成無數個功能頁面來完成開發的。

那麼頁面需求應該放到什麼地方統一管理呢？原型？UI圖？需求檔案？

我們團隊以前嘗試過通過Axure（一款原型設計軟體）來管理需求，就是把開發需求直接寫在原型頁面上。當需求改變時，先修改Axure原始檔，然後再發布。

這樣做很快便遇到2個無法調和的問題。

問題1：開發需求其實比原型頁面變動的頻率高得多。有時候因為開發需求描述不準確或者不夠詳細，不得不修改Axure檔案，很不划算。

問題2：大量的測試用例無法直接寫到Axure上面，也讓測試用例管理變得無比艱難。

於是我們團隊最終得到如下的需求管理模式：

（1）使用Axure畫原型，然後生成html，然後通過阿里雲OSS BROWSER上傳到阿里雲OSS，然後將OSS做成靜態網站，加上域名對映就可以公網存取了，比Axure官方預覽速度提升幾十倍；

（2）按照原型頁面結構1:1建立線上需求檔案結構；

（3）只有非常原始的、明確的需求我們才寫到原型頁面上，開發需求以及可能變動頻率較高的需求，我們都維護到線上需求檔案裡面；

（4）測試用例維護到線上需求檔案裡面。

以我們商城系統中的購物車頁面需求為例。原型（UI）如下：

 線上需求檔案如下圖所示：

 

 從上圖中可以看出，這個頁面隱藏的開發需求其實是很複雜的，原型不可能把每一個開發需求都體現出來，而上圖中的開發需求並不是一開始就這樣的，你現在看到的已經是我們維護過很多次的版本了。

所以，開發需求其實是會頻繁變動的，而線上需求檔案管理，才能將需求維護成本降到最低。（Axure或UI圖維護開發需求的成本太高太高了，最終導致需求沒人維護）

3. 測試用例管理

我們團隊曾嘗試過多種方式管理測試用例，最終終於探索出來一條低成本高效的測試用例管理之路。

從原理上講，測試用例的最佳載體就是需求檔案。由於我們已經將需求檔案線上化，所以基於線上需求檔案來管理和維護測試用例，本就應該是順理成章的事。

 值得一提的是，需求管理通常是由測試主管負責，而測試用例管理通常是由測試同學負責。測試主管根據原型錄入所有需求之後，測試同學按照分配自己的模組持續錄入測試用例。

測試用例錄入之後，這樣一個完整的頁面（功能）需求就算完成了。這時可以基於這個需求一鍵建立任務或提bug，如下圖：

 從上圖可以看到，建立任務或bug時，可以直接勾選測試用例。如果勾選了測試用例，那麼當程式設計師提交任務時，系統會提示先完成測試用例的驗證，避免未經過嚴格的自測就提交：

 除此之外，一個完整的需求還關聯了跟該需求相關的開發任務和曾經出現過的bug，如下圖：

 開發人員在檢視任務詳情的時候，也可以直接看到測試用例和完整的需求詳情：

 4. 本章小結

這才是一個完整的需求管理過程。包括：

• 原始的專案需求資料、客戶資料；

• 開發環境資料，開發、測試指南；

• Axure 產品原型；

• 頁面級線上需求檔案（關鍵）；

• 關聯到需求的測試用例；

• 關聯到需求的開發任務和曾經出現過的bug；

很多團隊需求管理一團糟，一會需求不是最新的、一會又出現多個版本的需求、一會需求檔案找不到，因為需求拖慢進度甚至導致程式設計師、產品、測試、UI之間扯皮的事太多太多了。管理好需求是管理好專案的基本保障。

 

第2章、專案迭代管理

很多程式設計師團隊處理不好開發新版與維護舊版，以及專案快速迭代的關係，所以工作總是感覺像一團亂麻。

我們團隊在專案迭代方面摸索出一條非常值得分享的經驗，也是我們專案管理理論體系中的核心。當你看完本章內容，你就會明白，不管多大的專案多大的團隊，用我們這種方式來管理，輕鬆實現有條不紊。

接下來，請看我們團隊是如何實現的。

1. 初始化專案

在我們團隊，專案原型畫完評審之後，UI同學按照原型出UI圖，測試主管或專案經理按照原型1:1在唐虞閣中錄入需求檔案。

全部需求檔案錄入完成之後，測試同學繼續完善測試用例，同時，專案經理基於需求檔案編寫API檔案。

我們團隊摸索了很多年，自創了一套通過JavaScript來編寫API檔案的框架，每一個API檔案就是一個js檔案，該檔案通過git或svn管理，伺服器自動載入該js檔案，然後將API檔案按格式呈現。優勢：用極少的程式碼實現複雜的檔案；充分利用git/svn版本管理功能；充分利用JS動態語言特性讓編寫更靈活；充分利用IDE智慧提示和強大的JS編輯能力。本文後面會專門開一章節介紹，此處不再展開。

API檔案編寫完成之後，通常第一批測試用例也差不多完成了。接下來便是建立開發任務了。

一個需求通常分為伺服器API開發任務和前端開發任務，前端又可能分為ios、android、小程式、web前端等。所以，專案經理會根據需要分別建立相應工種的任務，並評估該任務的標準產出。（關於標準產出請見本文第二篇第5章）

注意，這時候所有任務通常都沒有指派開發者，通常也沒有設定截止日期。

舉個例子，假如一個擁有100個頁面的專案，需求數就是100個左右，任務數就是兩三百個，根據使用者端數量而定。

當這兩三百個任務全部完成建立和評估（標準產出）後，專案就算初始化完成。這時我們可以看到所有的任務都是未指派開發者的，也沒有設定截止日期。如下圖所示：

 專案初始化完成之後，接下來便是安排開發了。

2. 安排第一週任務

專案經理根據自己判斷或客戶要求，自行選擇哪一部分任務先開發，哪些後開發。然後將任務指派給具體的開發人員，並設定截止日期為當週週日。

注意，我們並不會強制要求員工必須在截止日期前完成任務，超時也並不會有任何懲罰。設定截止日期，僅僅是為了幫助員工只用關心自己本週的任務。如下圖：

 專案經理安排的一週的任務量，通常也會稍稍高於該員工的能力。如上圖所示，楊藝本週目標標準產出27小時，但是她通常只能完成20小時的產出（按照一週上班35小時計算的話）。

第一週任務安排完成後，專案經理可以看到每個員工的工作量，以及大家的開發內容分佈，如下圖：

 

 

 

 

 根據這個分佈圖，就可以一目瞭然的知道任務量、任務難度、需求範圍安排是否合理了。

3. 後續每週安排任務

如上一小節所述，專案經理會給每個成員都稍微多安排一點工作，那麼每週結束時大概率就有一部分任務無法完成，這個很正常。

這時，比如又到週末了，專案經理會將本週未完成驗收的全部任務重新修改截止日期為下一週週日。從而保證下一週開始時，上一週的全部任務都是已做完、已測試、已驗收。

比如上一小節中給楊藝安排了27小時產出，她完成驗收的只有12小時，然後另外有幾個任務提交了還沒有測試，另外還有一個任務完成了60%。楊藝上週完成任務如下圖所示：

 楊藝本週安排的任務如下圖所示：

 可以看到這周實際上已經有3小時任務已完成，只是未驗收而已。等到本週驗收完成後，這些任務都可以歸檔為本週完成的了。

4. 加上bug管理

bug管理和任務管理的方式其實一模一樣。

專案經理會對每一個bug評估標準產出和難度，有了這個標準產出就很容給開發人員安排。

因為每週每個人的上班時間是固定的，每個人的能力水平在一週內也幾乎是不變的，這就表示：每個人一週能完成多少小時的標準產出其實幾乎也是沒啥變化的。

比如，一個初級別員工一週能完成15小時標準產出，專案經理就給他安排20小時左右的工作量；一個高階別員工一週能完成30小時標準產出，專案經理就給他安排40小時工作量。

這個20小時或40小時工作量是包含任務和bug的總的工作量。

而對於員工自己來講，每週登入系統，只需看TA本週的任務和bug即可，不需要看上一週也不需要看下一週的。通常一週的任務數量10個左右，一眼就能瞟完，只要沒有特別指定截止日期的，員工都可以自行安排開發順序。

這實際上大大降低了員工的工作壓力，提升了員工自由度，永遠不會有那種工作怎麼幹都幹不完的感覺。

寫到這裡，我總是想起不少朋友對準確評估標準產出沒有信心甚至無從下手。我想說的是：只要你是真的懂技術，請去嘗試一週吧，嘗試將你們專案裡的每一個開發任務都悄悄的評估一個標準產出（不要告訴別人），堅持一週，最多兩週，你會發現這真的很簡單，並且自己對幹這件事已經輕車熟路了。如果兩週後還不會，再來找唐虞閣主，我負責手把手教會，但前提是你真的懂技術。

5. 本章小結

我見過好些特別能吹的專案經理，說自己有多麼豐富的敏捷管理經驗。問他怎麼敏捷的，說半天歸根到底就是把專案需求拆分成多個版本釋出而已。

我們每一款產品也會分版本釋出，但這隻與甲方合同有關，與敏捷毫無關係。

真正的敏捷，是我們團隊這樣：每週對已驗收的任務進行歸檔，然後把未驗收的任務全部放到下一週繼續。員工永遠只需要關注自己本週的幾個或十來個任務即可。

這樣的敏捷，與產品版本沒有半毛錢關係。

這樣的敏捷，雖然實現起來非常簡單，就是一瞬間管理觀念的轉變而已，但是帶來的效果非常的明顯。並且不管一個專案多大團隊多少人，只需要按照這個模式一週一週的走下去，專案就會有條不紊且高質量的完成。

這才是真正的敏捷。

第3章、進度管理

試想一下，當你們公司其他專案組只能以「進度正常」、「進度延後」等模糊字眼的時候，而你卻能像下面這樣彙報：

當前專案已驗收任務總進度52.8%，加上待驗收任務總進度為58.9%，距離提交內測版截止日期剩餘56個工作日，剩餘標準產出856小時，按照團隊之前的效率（22.5小時標準產出/天），需要38個工作日完成，也就是說還有18個工作日的富餘。

你老闆一定會對你刮目相看。

如何做到呢？其實真的很簡單！

1. 評估所有任務標準產出

首先，讓我們回顧一下前兩章內容中，我們專案管理的流程：

1. 產品原型畫完；

2. 專案經理根據原型頁面1:1建立線上需求檔案；

3. 專案經理按照原型編寫API檔案，同時，測試小組基於線上需求檔案補充測試用例；

4. 專案經理為每一個需求，針對每一端開發人員建立開發任務，並評估該任務的標準產出（小時）。

 如果按照以上流程操作，至此，整個專案所有開發任務都已經全部錄入系統了，並且每個任務都評估了標準產出，這樣我們就會得到該專案的總產出數位。

正是因為每個任務都有一個標準產出數位，接下來，一切都開始變得簡單。

比如，你將隨時知道整個專案已驗收工作量，以及已提交待驗收工作量，以及剩餘未開始的工作量。

你可以知道每個團隊成員在這個專案中的工作量分佈，哪些人工作量大，哪些人工作量小，一目瞭然如下圖：

 你還可以看到各個功能模組的工作量分佈，哪些模組工作量大，哪些模組工作量小，專案做完後這個數位可以用於校驗我們報價的準確度，一目瞭然如下圖：

 寫到這裡， 我又想起一些朋友擔心學不會評估標準產出而踟躕不前。其實評估標準產出真的很簡單，一開始完全可以按照「如果自己來開發這個任務需要花多少小時」當做標準產出。但是有的朋友既想提升自己的管理水平，又怕這怕那怕麻煩怕學習怕嘗試，到頭來還來質疑我們的管理理論，這樣的態度實在不可取。

2. 避免無謂的加班

一個常態化加班的團隊一定不是一個聰明的團隊。

長期加班對團隊的危害我在這裡就不展開了，短期加班我倒是並不反對。我真正反對的是無謂的加班。

什麼叫無謂的加班？

我想起曾經的一個老闆，他跟我們部門經理說他壓力多大，要是晚上七八點到公司看不見幾個人加班，心裡就發慌。於是整個公司幾乎所有人都在無謂的加班，即使沒啥事可幹也要坐到七點多才走。

還有種無謂的加班是這種情況，因為管理者/老闆無法評估專案的真實進度，因為擔心逾期所以要求大家加班加點的幹。早點幹完後面沒專案了坐著幹耍都可以。慢慢地，感覺團隊被掏空。

無謂的加班對團隊有害無益，如何避免呢？很簡單！

請看下方專案經理關於加班的彙報就明白了：

當前專案距截止日期剩餘56個工作日，剩餘標準產出856小時，按照團隊之前的效率（16小時標準產出/天），需要54個工作日完成，富餘工作日較低，特此申請本週六起週六全天加班，直到進度壓力緩解。

這樣的加班安排相信誰都沒有怨言。

要做到這一點，如果你們團隊已經建立起了本文所描述的管理模式，那你們就已經做到了。

3. 浪費時間還是節約時間？

不斷地建立和評估每一個任務，下屬做的每一個開發任務都必須先由管理者建立並評估，不允許下屬做未安排的任務。很多朋友跟我說，如果一個管理者做了這些事，那一天就做不了其他事了，但是管理者自身也是有很多事要做的呀，自己都忙不過來的呀。

我想說的是：

（1）如果一個管理者的業務工作和管理工作在時間上無法調和的話，那首先應該保證管理工作的有序進行。因為如果管理工作做不好，整個團隊其他人的工作效率和工作質量都得不到保證，很快就會讓整個團隊陷入亂糟糟的境地。

（2）一個管理者應該把自己拆分成兩半來看，一半做管理工作，一半做業務工作。當做業務工作的時候，自己就是一個普通的專案成員，不應該擁有任何特權，應該把自己當做一個普通成員來安排任務，從而保證所有人的工作安排都有條不紊，切不可因為自己的特殊性影響整個團隊。

（3）以我們團隊的經驗來看，一個專案經理每天上班7個小時，在專案初期可能需要全天做管理工作，但在專案初始化之後，實際上每天只需要安排1-2個小時來做管理工作就足夠了。本節開篇那些表示忙不過來的管理者，有幾個人每天都能保證30分鐘的管理時間？這些管理者，完全就是陷入自我感動的忙碌中去了。

（4）忙歸忙，亂歸亂。忙不能成為亂的藉口，相反，如果能在忙的時候還能把團隊管理的有條不紊，那才是真水平。

有這打嘴炮的時間，不如多學學、多試試、多摸索，逐漸建立起屬於自己的管理模型，這才是正道。

4. 本章小結

我們常說一個管理者對專案、團隊的掌控度怎樣怎樣，體現了一個管理者的管理能力。

掌控的意思，就是不管大家忙成什麼樣了，團隊的一切事情都還在有條不紊的進行，只是大家每天工作時間變長了，其他什麼都沒變。該怎麼建立評估任務就怎麼建立評估，該怎麼安排任務就怎麼安排，完全不會因為忙就亂了章法。

這樣的管理模式需要堅定的理論支撐才能達到的，沒有堅定的理論支撐，工作一忙就容易動搖，一動搖就會更亂，就更難以實現。

本文所講述的管理模式，是我們團隊在過去十多年程式設計師團隊帶隊過程中不斷創新摸索出來的，雖然可能不100%適用你們的團隊，但我相信一定值得你們為之一試。

 

第4章、質量管理

程式設計師團隊的工作質量，是通過bug來體現的。幾乎所有程式設計師團隊都使用bug管理系統，但簡單的bug管理並不等於質量管理，也無法提升團隊的工作質量。

利用bug管理大幅提升團隊工作質量，請看我們團隊是如何做到的。

1. bug扣分

首先，我們針對所有bug型別制定了嚴格的扣分標準，這個扣分標準只與bug的嚴重程度相關，而與修復bug所花的時間沒有太大關係。舉例如下圖所示：

 這樣，我們測試人員在提bug的時候，就會按照這個扣分標準去評價這個bug的嚴重程度。

注意，上方扣分標準表格裡面的「5：一般-自測不充分」這一項。相信很多團隊都遇到過，開發人員完成開發後，根本就沒有充分自測就提交了，開發人員想，反正有測試同學會提bug，到時改bug就好了嘛。

事實上，大量的未自測bug會大幅降低團隊的工作效率。試想，開發人員完成一個幾小時的任務開發，本來過一遍所有需求點（測試用例）花不了多少時間，但直接提交結果導致好幾個bug。首先這浪費了測試人員的時間，其次開發人員後面修復這個bug的時候，肯定沒有剛開發完成時那麼熟悉，最後如果這個bug沒有被發現呢？

自從我們團隊加了這一條扣分標準之後，幾乎就再也沒有出現過這種「愚蠢」的bug了。

2. bug扣分應與工資掛鉤嗎？

我們建立bug扣分機制並不是用來扣員工工資的。bug扣分主要用在獎金髮放和晉升的時候。

有些團隊也引入了bug扣分機制，但直接與當月工資掛鉤，這會給員工巨大的壓力（雖然沒扣幾塊錢），並且會讓員工心裡很不爽。

我們團隊設計的bug扣分機制，完全不會影響員工當月工資，但是當有專案獎金或年終獎的時候，bug扣分就會成為相當重要的角色，一年的扣分可能拉開幾萬塊的差距，所以沒人敢不在乎這個數位。另外，職級晉升也會對bug扣分有明文要求，即使工作能力再強但是扣分太多也無法晉升。所以，更沒人敢忽視這個數位。

bug扣分還用於同事之間的橫向比較。哪個人長期扣分較多，哪個人長期扣分較少，管理者心裡跟明鏡似的。這都將成為人事決策的重要依據。

3. 迴歸測試

軟體專案開發過程中，總會有些時候測試人員是比較閒的。這時我們就會安排測試人員進行迴歸測試。

因為我們所有需求檔案都已經線上化，並且所有需求下面都有完整的測試用例，因此建立迴歸測試計劃就變得非常簡單。如下圖：

 建立測試計劃之後，可以將待測試的需求指派給具體的測試人員，測試人員可以標記測試狀態、提bug、記錄測試備註等等，如下圖：

 4. 本章小結

建立bug扣分機制，就好像給團隊中引入了一股神祕的力量，這股力量時時刻刻督促每個成員更加註重工作質量，更加註重自測。

如果將bug扣分與工資掛鉤，這就會產生巨大的副作用。所以，我們團隊摸索出的經驗是，只將bug扣分與員工長期利益掛鉤，而不要與短期利益掛鉤。

最後我想說，引入bug扣分機制，不是為了要扣誰的工資，但卻會實實在在大幅提升團隊工作質量，避免大量「愚蠢」的bug產生，從另一個角度講也是提升了工作效率，最終提升企業競爭力，最終所有員工都將受益。

 

第5章、API檔案

我們團隊於2018年自創的API檔案伺服器，對於提升我們整個開發團隊的工作效率貢獻了非常大的作用。

我猜大概將我們團隊整體效率提升20%左右。你可能會表示非常懷疑，但當你讀完本章內容後，你可能會表示相信。

1. API檔案由誰編寫？

在我們團隊，API檔案通常是由專案經理或架構師編寫的。

編寫者要求有非常高的編碼素養，包括優秀的命名能力、優秀的系統設計能力、豐富的系統架構經驗、豐富的編碼經驗等等。同時，還要求精通需求。

我粗略統計過我們上個專案API檔案的質量，API檔案第一版釋出出來之後，後面被修改的概率低於5%，這還包括需求變動帶來的修改。

這修改過的5%裡面，大部分都還是因為筆誤，因為複製貼上時可能忘了改URL或範例資料或欄位名稱什麼的。真正因為API檔案設計錯誤而修改的，比如資料結構不對、業務流程設計錯誤等，絕對低於1%。

所以，我們第一版的API檔案質量是相當高的。單就這一點，就可以避免相當可觀的工作量浪費以及團隊成員間扯皮。

所以，我們團隊總結出的關於API檔案的第一條經驗就是：API檔案編寫工作屬於高階工作，絕不應該偷懶交給初中級開發人員去寫。

2. API檔案何時編寫？

我知道，不少團隊的API檔案是由伺服器端開發人員編寫的，很多甚至還是通過後端程式碼生成的，比如swagger。這會導致使用者端開發人員強行依賴伺服器端開發。

我們團隊的API檔案，是在需求確定之後，專案經理建立專門的API檔案原始碼專案。這樣，前後端開發人員依賴的都是API，而不是前端依賴後端。

API檔案編寫完成後，我們會把API檔案的地址加到線上需求檔案裡面，這樣當開發人員做這個需求下面的任務時，就可以清晰的看到應該呼叫哪個API。對於大多數頁面來講，我們這個過程都不用任何形式的溝通的，開發人員自己按照需求檔案做即可，因為需求檔案裡面有TA需要的所有資訊。如下圖所示：

 所以你可以看到，我們整個團隊就像一個精密設計的機器一樣，這個機器的各個部件都圍繞需求中心運轉，各個部件所需要的資源都可以從需求中心獲得。所以在我們團隊做常規任務開發時，幾乎不需要任何的溝通，大家非常有默契。

這就是效率！

我再重新解釋一遍整個機器的執行原理：

1. 專案經理按照原型1:1錄入需求檔案；

2. 專案經理按照需求檔案編寫API檔案，測試人員按照需求檔案完善測試用例；

3. 專案經理按照需求檔案建立全部開發任務，專案初始化完成；

4. 每週，專案經理提前給每個人安排足夠一週的工作量的任務；

5. 每天，開發成員登入系統，檢視自己本週的任務和bug，開發任務所需要的API檔案、需求、測試用例，都可以通過任務關聯的需求檢視；

6. 每天，測試人員登入系統檢視已提交待測試的任務/bug，然後去驗收或提新的bug。 

怎麼樣，不知隔著螢幕你是否能感受到我們團隊的效率。

3. API檔案如何編寫？

我們的API檔案原始碼使用JavaScript編寫，使用intellij idea作為開發工具（或者其他任何文字編輯IDE），我們工作介面大致如下圖所示：

 API檔案JS原始檔通過git或svn提交到程式碼倉庫，唐虞閣API檔案伺服器會自動從設定好的原始碼倉庫載入js檔案，並呈現API檔案，如下圖：

 

 

 

 

 

 

 

 

 從上面截圖可以看出，短短20行js原始碼，生成了如此豐富的API檔案，這就是效率！

除此之外，充分利用intellij idea的智慧提示功能、複製貼上功能，以及JavaScript語言的動態性，都可以大幅提升編寫API檔案的效率。

這是我們團隊摸索多年，突有一天靈光乍現，才發明的一套全新的API檔案編寫/渲染框架。可以說是全網編寫效率最高、可維護性最高的一個框架，不服的朋友歡迎評論區交流。

不僅如此，這還是去前後端耦合的一個框架，讓前後端真正分離！

這樣的一個API編寫體驗，你不想試試嗎？

4. 本章小結

優秀的API檔案管理模型，幫助我們團隊整體提升20%工作效率。這體現在：

1. API檔案全部由專案經理或架構師等高階別員工編寫，減少設計錯誤就是減少返工、減少溝通成本；

2. API檔案專案是獨立於後端和前端的，解耦前端對後端的依賴，使前後端真正分離；

3. 由我們團隊自創的API渲染引擎，讓API原始碼足夠簡化，且可充分利用IDE的各種強大功能，大幅減少API編寫時間，大幅降低API維護成本。

 

第6章、專案管理總結

以上5個章節的內容，就是我們團隊在專案管理方面最核心的經驗總結了。其中包含了我們團隊在專案管理過程中做的大量的嘗試、探索和創新。每一條經驗都來之不易，希望能夠對你和你的團隊有所啟發。

接下來，讓我們繼續探索管理，因為管理不只是管事，更重要的是管人。

這裡的「管」字我覺得是「負責」的意思。「管事」就是對事負責，對專案負責；「管人」就是對人負責，對團隊、組織負責。

我們團隊在「管人」方面積累的經驗和感悟，我認為其價值是遠高於專案管理的。接下來，我將繼續，毫無保留的為你分享，我們在團隊管理中沉澱的所悟所得。

 

第二篇 團隊管理

管理就是識人用人，本文第一篇講的專案管理過程就是「用人」的過程。

本篇內容講「識人」。

第1章 被玄化的管理學

管理學的理論太多太多，隨便在網上一搜一籮筐。我先給大家看看管理學是如何被玄化的：

「管理就是管人性」、「管理就是通過他人來達成目標」、「管理就是把人和事做到充分結合」、「管理就是讓別人做你想做的事」、「不懂管理就自己累到死」、「管理是一種手段而非目的」、「做領導必須先學會忍受孤獨」、「想當好領導就不能故好人」、「做領導看人要準用人要狠」、「做領導心胸要寬格局要大」、「管理就是管人心」、「管理就是原則」、「管理就是控制」、「管理者要無為，讓下屬有為」、「要成為領導者，必須先學會領導自己」、「管理是向上管理，向下負責」、「管理的核心是啟用人」

什麼叫被玄化？就是看起來都對，一做就出錯。說白了就是：被故意誇大的但卻難以被複制的管理經驗。這些經驗大都不是管理學的主要矛盾，管理學的主要矛盾我認為就是識人用人的學問。

所以，不管你花了多少精力去鑽研這些玄乎的管理學，即使學成了，也不見得適用你的團隊，效果很可能微乎其微甚至適得其反。

 

第2章 管理很簡單

我的管理理論其實很簡單：通過專案管理採集評價數位，在完成專案管理的同時即完成對人的評價，即識人。

我認為管理很簡單，一點也不玄乎。

在我們團隊要當好一個管理者，不要求你懂人性、不要求你懂心理學、不要求你能說會道、不要求你懂人心、不要求你精於人情世故、不要求你精通人事關係。

所以，即使你是一個性格孤僻甚至怪異的人，即使你是一個特立獨行的人，也完全不影響你當好一個管理者。

但有一個要求，那就是要求你必須懂業務。

什麼叫懂業務：

1. 能夠將一個大專案拆分成無數個小任務的能力；

2. 任務拆分後，能夠評估每個任務的標準產出的能力；

3. 任務拆分後，能夠評估每個任務的工作難度的能力；

4. 工作出現bug時，能夠評估這個bug的嚴重級別的能力。擁有這四個能力才叫懂業務。

只要擁有了這四個能力，你就可以成為一個優秀的管理者。當然，我這裡所說的「優秀的管理者」，可能跟你想的有一點不一樣。

 

第3章 如何評價一個團隊的管理水平

我們團隊做專案管理、做任務/bug的標準產出和難度值評估的目的，不僅僅是為了「用人」，更重要的是為了「識人」。

我個人認為，評價一個管理者的水平怎麼樣，關鍵是看TA識人用人的水平怎麼樣，而識人的權重與用人的權重比可能高達8:2，也就是說識人能力佔8成，用人能力佔2成。識人能力遠比用人能力重要。

識人能力強，慢慢的團隊就會聚集人才；識人能力差，慢慢的團隊就會聚集庸才和小人。一個團隊若都是庸才和小人，就算你有再強的用人能力，也難以力挽狂瀾。

以前我認為，管理決策的加權正確率體現了一個團隊的管理水平，但現在我認為這其實只是表象的管理水平。真正的管理水平：指一個管理體系能夠準確評價一個成員所需時間多少的水平。

注意，我這裡說的不是識別人才的正確率，而是識別人才的耗時長短。因為如果在時間尺度上沒有限制的話，一個管理者遲早會認清TA的下屬的。關鍵就是花1個月認清還是花10年認清，這才是體現管理者水平的關鍵。

本篇內容就是給大家分享，我們團隊多年來摸索出的：如何建立快速識人管理體系。這個體系對管理者的要求很低，可以輕易複製到你的團隊。

 

第4章 如何建立快速識人管理體系

我再次重申：我們的目標從來都不是準確識人，而是快速識人。因為如果在時間尺度上沒有限制的話，一個管理者遲早能做到準確識人。關鍵就是花1個月還是花10年，這才是體現管理者水平的關鍵。

在正式開始理論展開之前，我先分享一個我們團隊的例子，好讓大家對快速識人的感受更深刻。

以前，我們招過一個員工，名校畢業，在大廠工作過2年，面試的時候表現也比較好，所以工資就給的高一點。但是一個月下來，其標準產出和難度值都不如工資比他低1000的同事。後來我給老闆彙報了這件事，老闆說需按照公司職業標準調整工資，或者走人。然後我找這個新人談了一下，他接受了降薪，因為他自己也知道以前在大廠確實沒有學到什麼東西，導致工作產出值和難度值都達不到公司要求。

這個例子的積極意義在於：1）維護了團隊公平；2）降低了該員工心理負擔；3）減少了企業成本。

這個例子中，我們主要通過【標準產出】和【難度值】兩個數位進行判斷，得到了較為準確的結果。

其實，我們提的準確識人並不是要100%準確，有個百分之八九十的準確度就足夠我們做出正確的決策了。只有槓精才會去追求100%的準確度。

如何做到八九十的準確度呢？關鍵就在於【標準產出】和【難度值】兩個數位。

這2個數位均來自於我們專案管理過程。因為我們專案經理在安排及驗收任務的時候，一定會對每一個任務進行標準產出和難度值的評估/修正。這樣，我們每週、每月、每個專案做完就會得到每個成員在該時段內的標準產出總值和平均任務難度值。

當然，這要求一個管理者充分發揮TA的管理職能，要花時間去對每一個任務/bug進行評估，並且要有這個評估的能力。

每每寫到數位化評估，我就總是想到有些朋友覺得評估標準產出和難度值太難了，甚至感覺無從下手。這裡我繼續囉嗦一下，只要你去嘗試了就會知道，這件事並不難，最長一個月便會輕車熟路，當然，前提是你得擁有懂業務的四個能力。

因此，我們建立快速識人管理體系的方法很簡單，那就是：通過專案管理採集評價數位，然後通過這些數位作橫向縱向（時間）比較，就可以實現快速、準確識人。

 

第5章 專案管理過程中的4個評價數位

我們團隊在專案管理過程中採集的4個評價數位，分別是：投入時間（Input）、標準產出（Output）、扣分（Punishment）、難度（Difficulty），簡稱IOPD。

先說這4個數位中最重要的一個數位：標準產出。

1、標準產出

定義：一個行業中等偏上水平的員工完成一個任務所需要花費的時間。

所以，標準產出都是以時間為單位，唐虞閣專案管理系統中的標準產出都建議採用小時為單位。

剛開始時，管理者可能對「行業中等偏上」把握不準，那麼完全可以按照管理者自己的水平來評估即可，即：管理者自己做這個任務需要花多少時間就是標準產出。

特別注意，標準產出這個數位絕對不是按照任務指派人的水平去評估，一定得按照一個「標準人」的水平去評估。

標準產出帶來的管理體驗是顛覆性的，在我們7個數位的管理體系中是最重要的一個數位，我認為佔據50%權重。實現了標準產出，就實現了50%的數位化管理體系。

引入標準產出後，企業很多問題都將變得簡單，比如：老員工幹得少拿得多、有些人嘴上能吹乾事卻不行、新員工試用期滿轉正定級、職級晉升、獎金髮放。

根據我們團隊的經驗，強烈建議：標準產出不應與工資掛鉤，但應與晉升和獎金掛鉤。抽象的講：標準產出不應與員工短期利益掛鉤，而應與員工長期利益掛鉤，從而規避KPI副作用。

2、難度

我們發現，引入難度值之後，會產生意想不到的效果。

效果1：可以看出管理者的工作安排是否合理。比如一個技術經理下面帶了3個人，其中一個高階工程師，如果一個月下來這個高階工程師的平均工作難度還不如其他中低階的難度，那就說明技術經理任務安排的不合理，應該把有難度的任務安排給高階的人才。

效果2：可以清晰看出公司花高薪聘請的人才是否名副其實。比如，公司花2萬月薪請了一個架構師，但是一個月下來，這個架構師完成的任務達不到企業其他架構師的難度，那就可能是這個架構師吹牛了。

效果3：讓員工晉升更有理有據。能夠長期持續完成更難的任務，說明這個員工的職業技能得到了提升。職業技能的提升，就應該是晉升的重要依據。這樣，企業就可以降低「論資排輩」的依賴性，更放心大膽的去改革晉升機制。

晉升機制的改革，會極大的刺激員工的積極性，會對整個企業管理體系產生非常明顯的積極影響。員工之間會更加註重職業技能的競爭，而不再是職業關係的經營，這會大大簡化員工關係，提升整個組織的工作效率。少了職場中的「阿諛奉承」、「爾虞我詐」、「勾心鬥角」等等，你會明顯感覺到企業中的「烏煙瘴氣」消失了，一個政治清明、積極向上的組織出現了。

這就是「難度」數位的神奇表現。

3、扣分

我們團隊引入扣分數位，是因為以前很多程式設計師開發完一個功能後，基本不自測就提交給測試同學了，以致導致大量的bug和返工，浪費測試資源。

然後我們就引入了扣分機制。對於那些自測都不做就提交任務導致的bug，全部當做「嚴重」級別的扣分處理。

效果怎麼樣呢？

可以說是立竿見影！

當天開會宣佈扣分機制，當天就再也沒有產生這種沒有自測的bug。為什麼呢？因為這本來就是一種工作習慣的引導而已。一個人完成工作後，本來就應該自己檢查一遍再提交給下一個環節處理，只要做了這個檢查/自測的工作，就一定可以避免低階的工作失誤。

所以說效果太快太好。

專案建立扣分機制之後，每個員工會更加註重自測。更多的自測會大大提高整個團隊的工作效率，原理大家一想就明白。

其實，我們建立扣分機制，不是想要去扣員工的分。而是建立這個機制之後，整個團隊中就像有了一股神祕的力量，時刻監督著大家要把工作做好、測好再提交，大幅度減少「返工」。

我看到不少的軟體開發團隊，開發一個新需求只需要花一週，但是測試驗收要花兩三週，甚至四五週。這樣的團隊很多很多。

我們建立的唐虞閣人才數位化評價體系，不是要去扣員工的工資，而是旨在建立一套完整的管理體系，這套體系會時刻敦促員工注意工作質量，大幅減少工作失誤，而不是等到員工出現工作失誤之後去扣員工的工資。

所以，唐虞之治的治，更多的是一種「預」的機制。

4、投入

投入數位記錄每個員工每天的上班時長。

我有個朋友的公司，有的員工明明沒啥事，每天晚上也要坐到7點多才走；還有的部門長期都比較閒，可能也是因為閒慣了，安排個事吧總是要拖很久才做完。

後來我跟朋友說，因為他們一天上班7.5小時，那就要求每個員工每天必須填滿7.5小時工作內容，即使是開會也要填。

這可把那些閒的人愁壞了。每天明明沒有那麼多工作，一開始編一編工作內容還能應付，很快就會發現自己江郎才盡：太難編了，或者編的看著太假，自己都看不下去。

然後這些人就會主動向上級要工作了，或者實在沒事就安排學習吧。以前只知道有些人比較閒，現在知道這些人到底有多閒。

就這一個簡單的數位，大大提供了我朋友公司的閒置資源利用率。就這麼神奇！

當然，投入數位還有其他應用場景，比如有的人請假多（家裡事多）、有的人加班多，這個數位都會幫每一個員工記著。有苦勞的人，公司也絕不辜負。

 

第6章 貢獻值

貢獻值這個數位其實並非採集來的數位，而是通過IOPD模型計算而來的數位。

首先，企業需要設定貢獻值演演算法，如下圖所示：

 以上圖中的貢獻值演演算法為例：貢獻值 = i+o*2+o*d*5-p*5

這個演演算法表示：貢獻值=投入時間+標準產出的2倍+標準產出X難度值的5倍-扣分的5倍。

貢獻值最大的用途就是獎金分配。

比如，一年下來，我們得到如下表所示的資料：

 假設公司年終拿出50萬發年終獎，那麼每個人應該拿多少年終獎，完全可以按照貢獻值比例計算而得，如下表所示：

 從上表看出，苟建國分得12.8萬年終獎，易瀟瀟分得2.8萬年終獎。每個人分得都不一樣，這是因為平均不一定等於公平。

雖然每個人分得不一樣，但保證每個人都沒有任何怨言。不管職級高低，都能分得自己應得的那部分獎金。並且保證第二年大家會更加在乎產出、扣分、難度、投入等數位。

從上表2021年資料看，每1（股）貢獻值可換2.8元年終獎，員工可以選擇兌換也可以選擇留到下一年一起兌換，因為說不定下一年1（股）貢獻值可換10元呢。

發獎金本來是好事，但很容易處理不好導致不愉快，關鍵就在於兩個字：公平。沒有公開透明的數位化的客觀的評價標準，「公平」二字在每個人心中的理解都不可能完全一樣的。

所以我們團隊這種方式，不僅絕無可能產生矛盾，還可以非常清晰的向員工傳遞公司的經營理念：什麼樣的員工是公司認可的。

除了根據貢獻值發獎金，還可以設定質量獎（扣分比例最低的）、勞模獎（投入時間最多的）、大牛獎（難度值最高）等等。

貢獻值數位除了用於獎金分配，也可以用於其他場景，比如：晉升、期權、股票、假期獎勵等。

 

第7章 週報系統

我們團隊使用唐虞閣週報系統主要有2個目的。

目的1：將所有職級的員工每週表現數位向100分制投影。

目的2：加強對管理者的監督。

先說目的1。因為員工職級不同、工資不同，他們每週的IOPD+貢獻值等5個數位都是絕對數位，絕對數位的多少不容易看出誰表現好誰表現差。

比如下表所示：

 上表實際上是看不出來每個員工當週表現如何的，因為每個人職級不一樣，工資不一樣，這時我們就需要週報系統來將絕對值轉換為相對值。

首先在唐虞閣系統中設定每個員工所屬職業的週報評價模型和下級打分模型，如下圖：

 

 

 

 職業模型設定之後，每個員工每週提交週報的時候，員工就可以給其上級打分，上級也需要給員工打分。這個打分都是相對員工所在職級進行打分的。

下級提交週報時給上級打分如下圖：

 

 上級評閱週報時給下級打分如下圖：

 

 我們的【效率】分是根據每個職級的「80分標準產出」來計算的。比如P1職級每週80分標準產出是15小時，員工做到15小時產出就可以得80的效率分。【質量】分是根據bug扣分來計算的，【態度】分則是管理者主觀評價（我們相信長時間的主觀評價也是相對比較客觀的資料）。

每週週報評閱完成之後，我們就可以得到如下圖所示的表格：

 

 上表按照上級加權打分排序，就可以看出，哪個員工本週表現好哪個員工本週表現差了。

下面說目的2：加強對管理者的監督。

唐虞閣週報系統包含了一個下級給管理者打分的功能。下級給管理者打的分和評語，管理者是看不見的，只有管理者的上級才看得見。

這個機制的建立，會大幅降低管理者為所欲為的概率。比如，經常有些管理者會冒領下級的功勞，下級只能忍氣吞聲，有了這個機制之後，管理者再想幹壞事，心理就得掂量掂量了。

還有的管理者一點不尊重下屬員工，一副高高在上的樣子，動不動就辱罵、責怪、甩鍋下屬。這樣的管理者通常對其上級極其阿諛逢迎。如果沒有這樣的週報機制，上級領導想要發現這樣的管理者還不那麼容易，可能得要較長時間。

所以，我們的管理體系，就是幫助管理者更快速的識別人才、庸才。「更快」才是我們的管理目標。如果說職場是一場戲的話，我們希望小人們第一集就領盒飯，而不是等到大結局。

 

第三篇 總結

以下內容為我十來年總結的對團隊管理的一點看法，希望能對大家有所啟發：

1、管理就是識人用人的過程，管事就是對事負責，即用人過程；管人就是對人負責，即識人。

2、識人遠比用人重要。管理者能識人，團隊就會越來越聚集人才；管理者不能識人，團隊就會越來越聚集庸人和小人。

3、識人快慢體現了一個組織的管理水平，而不是識人準確率。因為如果在時間維度上沒有限制的話，再差的管理者總會實現準確識人，關鍵就在於耗時一個月還是10年的區別。

4、我們團隊建立了完善了快速識人體系，說白了就是7個數位而已：投入、產出、扣分、難度、貢獻值、上對下評分、下對上評分。

5、這7個數位的權重不是均勻的，實現標準產出就可以說完成了50%的數位化人才體系建設，完成7個數位的話，就可以說實現了95%以上的數位化人才體系建設。

6、「標準產出」是我們管理體系中核心的核心。建立了標準產出評估機制，可以說就開啟了企業人才數位化的大門。

7、我們在程式設計師團隊積累的經驗是：通過專案管理採集數位，通過數位識別人才。「用人」的時候既實現了管事，又完成了識人，識人的結果反過來又會激勵和更新人才，從而更好的實現「用人」。

8、管理並不難，也沒那麼玄乎。我認為一個管理者只需要真正在懂業務就能輕鬆做好一個管理者。除此之外，其他能力都很次要。

9、懂業務表示管理員擁有4個能力：

1. 能夠將一個大專案拆分成無數個小任務的能力；

2. 任務拆分後，能夠評估每個任務的標準產出的能力；

3. 任務拆分後，能夠評估每個任務的工作難度的能力；

4. 工作出現bug時，能夠評估這個bug的嚴重級別的能力。

 

10、管理的核心是公平，我們做的一切管理工作都是為了提高團隊的公平度。只要團隊公平度提升上來了，一切都會進入良性迴圈：人才會聚集、效率會提供、質量會提高、人事關係會更簡單、團隊氛圍會更加積極，團隊會越來越有戰鬥力。

11、未來的管理一定是數位化的。這裡說的數位化，不僅僅是把專案錄入系統來管理就完了，而是在做專案管理的同時，要完成對人才的評價數位的採集，然後通過這些數位來識別人才，從而讓組織得到進化，為專案管理輸入更優秀的人才。

12、本文所傳遞的管理理論，我認為不僅適用於程式設計師團隊，也適用於其他行業。

朋友，如果你認同我的觀點，歡迎點贊轉發。

如果你也想試試我們這套管理體系，你可以通過唐虞閣微信公眾號聯絡到我，我仍將毫無保留、傾盡所能幫你們團隊出謀劃策（免費）。這套管理體系在實施過程中肯定還會遇到一些細節問題，而我的經驗可能會幫你們少走一些彎路。