15.9 萝卜白菜，各有所爱

　　项目进行了一段时间，TFS上也积累了不少数据。大拴做了“数据挖掘”，整理出来一些统计信息。在头碰头会议上汇报。

　　大牛：哇塞！看起来UI组的这位哥们是冠军呀，他的bug数量约等于所有其他成员的总和。

　　二柱：那是有客观原因的，你可能不知道他的工作量是最大的。

　　阿亨：那也不能因此产生这么多小强，而让整个团队的进度停下来吧。

　　二柱：别人工作得这么辛苦，我倒是不太忍心再批评他。阿超，其实我觉得我们应该鼓励成员多做贡献，错误总是难免的，但是你知道他上星期完成了两个功能，明显比别人快多了。别的同事和他一比，就慢多了。

　　阿亨：我不太同意，从TFS的数据来看，他的bug数量远比别人多，而且不少bug都有一段时间了，你说的“慢”的人，好像没有多少bug，也是差不多按期完成的。

　　大牛：问题是你希望团队里是“萝卜快了不洗泥”类型，还是“慢工出细活”类型？

　　阿超：我有一个故事，假设团队里来了两位年轻人，嗯，就叫“萝卜”和“白菜”。

　　萝卜做事很快，是“萝卜快了不洗泥”类型；白菜是“慢工出细活”类型。

　　分配了任务后，萝卜很快就说做好了做好了！白菜还在吭哧吭哧的和PM/Test讨论。

　　领导很高兴，让萝卜去做更多的事。开发阶段结束了，萝卜比白菜多做了不少功能。稳定阶段开始了。大家发现萝卜负责的功能出了很多问题，白菜的模块倒是比较稳定。然后萝卜在团队中的曝光率很高，很多问题都在等着他解决，从统计上看，他也修复了不少缺陷。白菜结束了自己模块的工作，开始帮助其他人，由于不熟悉其他人的模块，白菜修复的缺陷不多。由于萝卜的设计有缺陷，导致模块非常复杂，萝卜也成了唯一了解他的模块的开发人员。项目最后阶段，几乎都是萝卜工作得最晚，把最后几个缺陷修复了。领导们说：有问题，找萝卜！

　　项目结束了，开始了绩效考核，领导A认为白菜绩效不错，模块按时完成，没有大多问题，然后还能帮助其他成员；领导B认为萝卜是超级明星：第一个完成模块，修复的缺陷最多，而且掌握了最复杂的模块，离开他不行，工作得也很晚，有突出贡献。至于白菜，领导B没感觉他做了啥，仅仅是按要求完成任务了。

　　萝卜白菜，各有所爱。那萝卜和白菜谁该得到奖励，谁该得到批评呢？

　　假如领导B的评价方式占了上风，萝卜得到奖励，白菜离开了团队，你觉得下一个版本会出现什么情况？

　　阿杰：我估计萝卜会成为“构建大师”，每天忙得不可开交。然而项目进展不一定会像以前那样顺利……

　　二柱：有人会怀念白菜。

　　大牛：你的意思是团队的领导者文化决定了团队的风格。但是当前该怎么办呢？

　　阿超：所以我们要让“萝卜快了不洗泥”的人慢下来，这样能减少他们的危害。

　　大牛：授予他们“萝卜大师”的称号？

　　阿超：恐怕不灵了，我们要胡萝卜和大棒并用。