讀《程式設計師度量》思考

最近抽空在家粗讀了一般書：《程式設計師的度量：改善軟體團隊的分析學》

書點評描述，度量在軟體開發中的應用，例如有些公司號稱，三個人幹五個人的活拿四個人的工資。

這裡人數很容易確定，技術也可以通過標準化的考核衡量，那麼五個人的工作量怎麼衡量，這就牽扯到了團隊的管理，對於乙個外行來說，無法衡量乙個需求的具體工作量，軟體系統紛繁複雜，表面上看起來一樣的系統，內部實現可能千差萬別。

團隊管理另乙個棘手的問題是人員的考核，現在大部分公司都實行271 比例，末尾淘汰制，從管理的角度看無疑是提高團隊的競爭力，但具體實行的時候，乙個團隊的成員怎麼確定那個1.

不同的成員在技術上有不同的側重，同乙個需求，實現起來可以由好幾種方式，怎麼達成共識，怎麼衡量哪種技術方案最合適。

這點很考驗管理者的能力。

這篇文章我從乙個技術團隊管理者的角度分析目前網際網路企業或者技術團隊的管理工作，對於棘手的問題結合實際經驗給出一些方向提示，和大家一起交流。

程式設計師是乙個新興的行業，從個人pc機的普及到目前的網際網路時代，不僅僅技術在發展，程式設計師的工作內容也在不斷變化，今後全棧的技術人員將越來越少，更多的程式設計師崗位將精細化。

目前程式設計師主要工作內容是對接產品人員提出的需求，評審需求是否合理，給出實現方案，方案評審通過之後，編寫**，自測，提測，測試之後版本發版。

寫**是程式設計師的主要工作，**不僅僅考慮業務邏輯的實現，同時需要考慮效能，新的功能點對舊業務邏輯是否相容，歷史資料的處理，對未來的業務預留介面。

如果是分布式系統需要跟隨團隊聯調，固定乙個發版時間。

程式設計師是產品業務邏輯的實現人員，在領域驅動開發中，技術人員被定義為核心。

但是在中國的物聯網企業中，技術驅動、技術創新的公司很少，大部分公司都是業務驅動，直白點說就是賺錢，傳統的業務利用網路模式服務。

表現出產品經理的話語權很重，經歷過一家產品經理負責的公司，公司所有版本的實現、上線由產品經理負責推動，實踐下來就是需求實現不完整，或者實現的需求不是運營想要的樣子。一方面和產品經理能力有關係，一方面是權責不對等導致。

作為技術人員，一定得為自己的**負責，作為開發團隊管理人員一定要為自己的團隊成員的**負責。

技術團隊管理不是傳聲筒，也不是產品團隊的乙方。

考核制度是公司的一部分，對於員工的考核給管理人員提供重要資訊，對於程式設計師來說，工作內容的考核涉及方方面面的利益，從老闆的角度看，希望自己的員工價效比高，技術好，能加班，要求少，從員工的角度看，希望公司氛圍好，不加班，待遇超過行業平均。

程式設計師不同於一般的流水線工人，產出沒有辦法衡量，當然有些重複的性的**工作可以衡量，但仔細想寫程式不就是避免重複性的工作嗎，從目前看，程式設計師的能力和收入成正比，如果一家公司的程式設計師平均工資在行業水平之下，那麼大概率這個公司的程式設計師水平在行業平均水平之下。寫出的**質量可想而知。

目前大部分企業的考核是有直屬上級決定，這點就涉及個人的偏好。

造成每年考核之後一批人的離職。這對於技術團隊來說是不健康的狀態，也容易影響氛圍。

現階段看了，對於程式設計師的考核設定一些標準化指標，例如bug數

設計概要的質量等資料，盡量做到公平合理。

考核的時候，有些上級會詢問下級對於其他同事的看法，這也是一種考核手段，但這點對於私下小團隊就失效了，如果大家私底下溝通好呢，如果上級考試詢問下級這個問題，盡量只誇人。

同時你也要了解，上級的能力不足把控團隊的人員。

《程式設計師的度量》書中主要用體育明星的衡量做模擬，思考程式設計師的度量，

相對於體育明星在公眾下展示自己的技能，程式設計師更多的時候再角落裡默默的寫**，測試可以從成品角度衡量需求是否完成，但是如果你不看**，你無法準確判斷出他的工作量和質量，而且必須是專業的人來review。

但現實是一部分領導的技術能力不足，無法衡量下屬的工作量、質量。

作為乙個管理者，一定要具備一定廣度和深度的技術，對於自己團隊成員的**能夠快速review。

通俗來說，就是你的團隊成員突然缺失，團隊管理者要有能力及時補位。

補位是暫時的，管理者側重全域性的把控，具體的業務邏輯實現不必須親自參與。

軟體行業仍在快速發展，歡迎同行交流。