紅珠實驗由著名質量學家戴明設計。

實驗器材如上圖所示，在一個盒子里，有4000顆彈珠(代表總工作量)，3200顆白珠(正常任務)，800顆紅珠(缺陷)，兩種彈珠混合在一起，有一個勺子，一勺可以容納50顆彈珠(代表每天的工作量)，右手邊有個盆子，用來盛放和記錄每一勺的結果。

實驗過程如下：操作員的職責是盡量產出白珠，盡量減少紅珠，他每次挖一勺彈珠，代表一天的工作量，如果操作員確認這次操作，就放到右手邊的記錄盆里記錄結果，如果不確認，可以倒回盒子里再重新挖一勺。而你作為管理員，可以用任何管理方法對操作員進行干預和管理，包含績效考核，缺陷管理，激勵懲罰手段等。

在實驗中，不論管理員用何種方法干預和管理，最終的缺陷比例就是20%，每天的缺陷數量就是趨近10個。

這個實驗結果表明，系統績效是穩定并可以預測的，只跟系統本身的結構有關聯，一些看似有關的因素，比如檢查手段，缺陷數量要求，獎勵和懲罰措施，管理措施等，其實對績效都沒有影響。

于是，進一步推演，得出：

結論一：“在不改變系統本身的情況下，任何針對個體或團體的績效考核都不是問題解決之道”?？冃Э己藢T工或團體進行排名，是一種錯誤的方法。

結論二：“在決定員工績效的因素中，有94%以上是他們自己所不能決定的”。紅白珠的混合比例基本就決定了實驗結果。雖然工人的疏忽或個人行為也能在一定程度上影響實驗結果，但實驗結果主要取決于所采用的實驗材料，即人無法控制的系統原因。

紅珠實驗，我認為在一定的前提下，針對軟件工程也是有道理的。

這個前提就是在工程師平均能力達到行業平均水平。因為在實驗中，操作員需要做的只是挖一勺彈珠，技術高低對結果影響不大，但軟件工程中，工程師的技能和態度對缺陷影響巨大，在很多情況下，工程師造成的缺陷甚至多于系統本身包含的。在人資管理做的非常差公司，就是這種典型情況，人為缺陷大于系統缺陷。

在我的工作中，14年底到15年底，即研發經理和老一部經理的時期，一直在考核跟過程下功夫，認為結果是由考核和過程管理所決定。而那時也常有一種無力感，隱約覺得績效結果并沒有控制在考核和過程上，但又說不清到底在哪里。明顯的表現就是有時根本沒在意考核，結果卻過得去，有時你把精力全放在考核跟過程管理上，結果卻慘不忍睹。

16年初成立CMI，由于團隊精簡，成員的專業技能在平均水平之上，我決定完全不需要做考核，把注意力放在方法論，系統本身以及每個成員的因材施教上，這個決定現在回頭看，應該是比較正確。CMI的工作結果，跟紅珠實驗的結果是一致的：缺陷主要是由系統本身決定，考核并不是問題的解決之道。那時的項目，缺陷絕大部分都集中在系統上，只要有效管理好了前期需求和設計，后期bug量很小，而我們也沒有做過任何質量相關的考核指標。

成立員工檔案也在另一方面保證每個人專業技能的進步，而不至于止步不前帶來質量隱患。這是余世維在日企工作時見到的一個做法，我自己試過之后，覺得比起千篇一律的考核標準帶來的實際作用更大，而且不容易淪為一紙空文。把員工檔案給同事看過之后，他們大部分表示小團隊適合，人數超過10個就不適合了，原因是太耗精力。從實操來看，這是偏見，員工檔案花費的精力只有績效考核一半不到，效果卻提高了好幾倍。

當然，最終CMI產出了跟戴明一致的實驗結論，質量較好的項目，裁剪出了非常有用的方法，以及人才輸出。除了財務考核上的弱勢，我認為我們比較優秀了。反過來想，正如紅珠實驗所說，在不改變系統本身的情況下，任何針對個體或團體的績效考核都不是問題解決之道，而團隊的績效絕大部分并不由我們自己控制。公司的系統目前是簡單地把財務數據分攤到每個部門，并不是問題解決之道。