最近翻了下之前寫的公眾號文章，發現研發效能相關的就有三篇：

• 怎樣提高開發效率

• 關于增效，需要做好這兩點

• 再談研發效率提升

從工具使用、業務的理解、團隊的溝通協作到流程、組織、分享等內容，我能想到的大部分有關研發效能的點都有涉及到。

但知識和認知是在不斷進化的，就像好書一樣，常讀常新。最近關于研發效能又看了些書和視頻，有了些新的想法。

1、研發效能的本質是人，最終還是需要依靠人的內驅力來達到效能的提升，所有工具建設、流程優化、組織管理都是為人服務的；

2、 向落后的項目中增加人手，只會使進度更加落后，這就是著名的 Brooks 法則，因為增加人會帶來溝通成本的增加，增加更多的人，這個成本會指數級地增加。但也并非絕對，如果事情都拆分的很細，并且有標準化的文檔，增加的人員可以根據文檔快速落地，也能增快速度的。軟件研發中想做到零溝通，這種情況很少，也很難。

3、《人月神話》中有這么一句話：人月是危險和帶有欺騙性的神話，因為它暗示人員數量和時間是可以相互替換的。就是說 1 個人做 10 個月能完成的任務，讓 10 個人做 1 個月就能完成。這種在流水線上的計件工是可能的，但在軟件研發項目中就成為神話了。

4、德魯克說過：管理是最大限度地激發他人的善意。這個善意是指激發員工的成長性思維，提升每個人的內驅力，讓每個人看問題能更長遠，而不是只顧眼前利益。如果管理者在潛意識中認為每個人都是人性本惡的、那么在管理方式方法上就會引發他人的惡意，這種惡意對外的表露更是讓管理者覺得自己的感覺是對的，從而形成了一種惡性循環。

5、德魯克還說過：如果你不能度量他，你就不能改進他。好的度量要符合兩個標準：

• 從解決根本痛點問題作為出發點；

• 能夠引導團隊成員做出正確的行為。

6、度量不應該跟 KPI 進行綁定，程序員是聰明的，上有政策就會下有對策，往往會適得其反，這樣的例子很多：

• 考核釘子的個數，結果就是會生成一堆小釘子；

• 考核釘子的重量，結果會得到幾個大釘子；

• 考核延期率，最終都不會延期，但質量就不能保證；

• 延期率和 Bug 數都進行考核，代碼中就會有各種補丁，難以維護和擴展。

考核什么指標，經過一定的時間，從數據上看，這些指標肯定會越來越好，但結果未必就好。古德哈特定律也提到：當一個政策變成目標，它將不再是一個好的政策。

7、霍桑效應是指意識到正在被觀察的個體，具有改變自己行為的傾向，這是心理學上的一種特征。在管理團隊時，也需要照顧到每個人，做的好的時候要表揚、做的不好的地方要指出不足、心態、心情有波動的時候需要鼓勵和安撫。每個人都覺得自己被關注了，就會做出改變。

8、樊登讀書講的《可復制的領導力2 》中，提到了一個「10 倍好」的方法，意思是如果要求提升 20 % 的效率，首先想到的是多招點人，加加班，或者增加投入，肯定能夠提高 20% 。如果要求提升 10 倍的效率，就不是靠加人、加班可以解決的，需要我們放棄過去的做法，進行一些顛覆性的創新。10 倍這是一個說法，主要是思維能跳脫出來，站在更高維度來看問題。

9、代碼注釋是提升代碼信息熵的低成本手段，只要稍加注意，每個人都能做到，可以減少人和人之間的依賴。以前覺得如果一個研發團隊職責分的比較細，各個環節標準化，上下游協作像流水線一樣，這樣效率就會很高。實際發現很難做到，現在更傾向于一個人或一個小團隊做一個垂直的模塊。

10、交付更多的功能就實現了目標嗎？當我們被繁重的工作弄得焦頭爛額的時候，需要停下來思考下這個問題。最近領導在群里說：三個蓋子五口鍋，怎樣才能把飯做熟？，有人說加火加時間，我覺得火太大不一定是做熟，有可能做糊了。要解決這個問題要思考下面幾個問題：

• 一定要五口鍋才能吃飽飯嗎？

• 每口鍋是否是滿的呢？如果不是，是否能減少到三口鍋，讓每口鍋裝滿？

• 如果五口鍋都是滿的，才能勉強吃飽飯，那就要好好想想了，是不是飯的質量不行，不抗餓？

找到問題，才能解決問題，加火加時間只能掩蓋問題。

祝大家兒童節快樂！