量化管理在程式員身上永無可能

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

這次估計會有争議，是以這裡給出具體的邏輯鍊以及對應的分析。

邏輯鍊：

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

具體分析：

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

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

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

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

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

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

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

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

誠

然思維的表現形式則是可以度量的，我們可以通過頁數來度量一本書的厚薄，通過分鐘來度量一部電影的長短，通過代碼行來度量軟體，但這種度量所反映的内涵是

有限度的，精度也是有限度的。最終結果很可能是人員之間的差距是由誤差或其他非主觀因素造成的，而不是由個人工作好壞所造成的。

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

補充說明：

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

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