程式員第二定律：量化管理在程式員身上永無可能

恰如標題，第二定律表示為：在思維可以精確量化前，量化管理在程式員身上永無可能。

 

這次估計會有爭議，所以這裡給出具體的邏輯鏈以及對應的分析。

 

邏輯鏈：

 

軟體是一種固化的思維 →思維的本質是概念和邏輯 → 概念和邏輯無法直接度量和精確度量 → 度量過程中需要很多的主觀判斷 → 以目標為導向的，個人中心的量化管理（相關的激勵和懲罰）將崩潰 

 

具體分析：

 

 

公平公正是管理的基石，為達成這一目的很多人會想到量化管理，但量化管理的基石卻往往被忽略。

 

對人進行量化管理的基石是：量化後的數字主要受個人表現這一個因素的影響，否則將產生巨大的不公正，並對個人工作意願產生不良影響，是真正的事與願違。

 

好比說，不同的工人在同等條件下生產杯子，一個人一小時生產5個，一個人1小時生產6個，那顯然後者要好於前者。這時，5和6可以用來比較的前提是兩個人的生產條件相同，比如生產工藝等。在這種情況下，量化後的數字為個人表現的函數，因此量化管理基本上是公正的。

 

這時可以進一步來考慮下面的情形：兩個人同時生產杯子，廠方安排一個人用工藝a，另一個人用工藝b，這個時候前者一小時生產5個，後者1小時生產6個。這個時候單純比較5和6事實上是不公平的，因為這1個杯子的差距可能是工藝造成的。

 

大多時候，軟體的情況比後一個情形還要糟糕一些。

 

在軟體開發中，往往既沒有辦法清楚的界定一個人的輸入，也沒辦法清楚的界定一個人的輸出。

 

軟體開發的輸入是需求，但同一個需求不需要做多次，所以對需求自身的複雜程度眼下來看還只能依賴判斷，而不能精確度量。

軟體開發的輸出是代碼，而代碼自身屬於固化後的思維。在度量思維時，多少、大小、長短、厚薄這類慣常的度量方向，並不具有多大意義。就好比說，不能講一個人代碼寫的越多貢獻就越大一樣。

 

誠然思維的表現形式則是可以度量的，我們可以通過頁數來度量一本書的厚薄，通過分鐘來度量一部電影的長短，通過程式碼來度量軟體，但這種度量所反映的內涵是有限度的，精度也是有限度的。最終結果很可能是人員之間的差距是由誤差或其他非主觀因素造成的，而不是由個人工作好壞所造成的。

 

總結來看，在軟體開發中，數字含義的模糊性會導致使用數字進行評價包含非常多的不公正，這種不公正會對工作意願構成致命傷害。所以個人層面的量化管理在軟體開發面前，必然崩潰。

 

補充說明：

 

• 為避免矯枉過正，最後需要強調的是：並不是說專案管理中不需要收集資料，只是說在軟體這個行業中，各種資料的精度天生是有限的，因此必須用在允許有限精度的工作上（估算、任務安排等），而不能用在對人進行評價、對項目進行評價這樣需要高精度資料的工作上。

 

 

 

• 這條定律的推論可以無限多，影響到管理，流程乃至估算，這裡就不列了。

 

關聯文章：

程式員第一定律：關於技能和收入