全文1.6萬字，斷斷續續寫了一個月，把我從2011年開始帶團隊所積累的所有經驗和思考都毫無保留的分享給大家，希望能夠給大家一點點啟發。

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

我從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、本文所傳遞的管理理論，我認為不僅適用于程序員團隊，也適用于其他行業。

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

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