15.9 萝卜白菜,各有所爱

  15.9 萝卜白菜,各有所爱

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  二柱:有人会怀念白菜。

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

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

  大牛:授予他们“萝卜大师”的称号?

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

读书导航