红珠实验和CMI

红珠实验由著名质量学家戴明设计。

实验器材如上图所示，在一个盒子里，有4000颗弹珠(代表总工作量)，3200颗白珠(正常任务)，800颗红珠(缺陷)，两种弹珠混合在一起，有一个勺子，一勺可以容纳50颗弹珠(代表每天的工作量)，右手边有个盆子，用来盛放和记录每一勺的结果。

实验过程如下：操作员的职责是尽量产出白珠，尽量减少红珠，他每次挖一勺弹珠，代表一天的工作量，如果操作员确认这次操作，就放到右手边的记录盆里记录结果，如果不确认，可以倒回盒子里再重新挖一勺。而你作为管理员，可以用任何管理方法对操作员进行干预和管理，包含绩效考核，缺陷管理，激励惩罚手段等。

在实验中，不论管理员用何种方法干预和管理，最终的缺陷比例就是20%，每天的缺陷数量就是趋近10个。

这个实验结果表明，系统绩效是稳定并可以预测的，只跟系统本身的结构有关联，一些看似有关的因素，比如检查手段，缺陷数量要求，奖励和惩罚措施，管理措施等，其实对绩效都没有影响。

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

结论一：“在不改变系统本身的情况下，任何针对个体或团体的绩效考核都不是问题解决之道”。绩效考核对员工或团体进行排名，是一种错误的方法。

结论二：“在决定员工绩效的因素中，有94%以上是他们自己所不能决定的”。红白珠的混合比例基本就决定了实验结果。虽然工人的疏忽或个人行为也能在一定程度上影响实验结果，但实验结果主要取决于所采用的实验材料，即人无法控制的系统原因。

红珠实验，我认为在一定的前提下，针对软件工程也是有道理的。

这个前提就是在工程师平均能力达到行业平均水平。因为在实验中，操作员需要做的只是挖一勺弹珠，技术高低对结果影响不大，但软件工程中，工程师的技能和态度对缺陷影响巨大，在很多情况下，工程师造成的缺陷甚至多于系统本身包含的。在人资管理做的非常差公司，就是这种典型情况，人为缺陷大于系统缺陷。

在我的工作中，14年底到15年底，即研发经理和老一部经理的时期，一直在考核跟过程下功夫，认为结果是由考核和过程管理所决定。而那时也常有一种无力感，隐约觉得绩效结果并没有控制在考核和过程上，但又说不清到底在哪里。明显的表现就是有时根本没在意考核，结果却过得去，有时你把精力全放在考核跟过程管理上，结果却惨不忍睹。

16年初成立CMI，由于团队精简，成员的专业技能在平均水平之上，我决定完全不需要做考核，把注意力放在方法论，系统本身以及每个成员的因材施教上，这个决定现在回头看，应该是比较正确。CMI的工作结果，跟红珠实验的结果是一致的：缺陷主要是由系统本身决定，考核并不是问题的解决之道。那时的项目，缺陷绝大部分都集中在系统上，只要有效管理好了前期需求和设计，后期bug量很小，而我们也没有做过任何质量相关的考核指标。

成立员工档案也在另一方面保证每个人专业技能的进步，而不至于止步不前带来质量隐患。这是余世维在日企工作时见到的一个做法，我自己试过之后，觉得比起千篇一律的考核标准带来的实际作用更大，而且不容易沦为一纸空文。把员工档案给同事看过之后，他们大部分表示小团队适合，人数超过10个就不适合了，原因是太耗精力。从实操来看，这是偏见，员工档案花费的精力只有绩效考核一半不到，效果却提高了好几倍。

当然，最终CMI产出了跟戴明一致的实验结论，质量较好的项目，裁剪出了非常有用的方法，以及人才输出。除了财务考核上的弱势，我认为我们比较优秀了。反过来想，正如红珠实验所说，在不改变系统本身的情况下，任何针对个体或团体的绩效考核都不是问题解决之道，而团队的绩效绝大部分并不由我们自己控制。公司的系统目前是简单地把财务数据分摊到每个部门，并不是问题解决之道。