(翻译)停止使用糟糕的MBO
停止使用糟糕的MBO
---Rex Black原著《Stop the Bad MBOs》
---Kiki翻译于2005/9/02
摘要
有些管理人员有效地使用“目标管理（management by objectives）”，不过，由于被他们太过频繁地被消极使用，结果却破坏了团队。在这篇文章中Rex给出了强烈停止使用糟糕的MBO的号召, 并且给出了三个不要做的案例分析。
导言
你想引入一个新的目标到你的组织中来帮助为你工作的每一个人吗？这个怎么样：停止用糟糕的MBO破坏你的团队。
MBO，是management by objectives的缩写，常用做每年绩效考核中的一部分。理论上来说，目标的完美组合是一种用量化的方法来准确地定义职员将要在来年收获到些什么。在年末，在每年的绩效考核中,管理人员简单的度量是否－或者达到目标的什么程度。
然而，一些目标管理常常用戏剧性的方式走向了相反的方向。让我们看看三个糟糕的MBO案例分析，看看他们如何负面地影响团队，并且管理人员怎样才可以做的更好。
案例分析一：受刑的男孩和女孩
有个公司为他的测试团队设定了两个年度绩效目标。第一个是所有团队都适用的，就是所开发的系统要按时交付。第二个只是针对测试经理的，就是交付的系统必须是高质量的，只存在少量的bug。
测试团队在开发期间做的很好，发现了大量的bug，实际上，有上千个。他们发现了如此多的bug以致于系统不能够按时地部署，直到在最初发货日期后的几个月后。他们发现如此多的bug以致于开发人员无法修故所有的bug，大部分的bug被开发人员以不是“面向客户”的bug为借口推迟修复了。而大多数此类bug在以后都被客户服务人员报告了。
当每年针对测试团队的绩效考核又开始时，他们被告知他们未能满足两个目标中的任何一个目标。毕竟，系统发货期迟了，并且还有很多导致大量客户服务电话的bug。沮丧的测试经理立刻开始寻找其他的工作，并且在这个事件后的不久就辞职去别的公司了。
很明显，“按时发货”的目标是不适当的。当我们测试人员做的很好时，我们几乎总是可以发现问题，并且这也通常会导致延期。“高品质系统” 的目标同样不适当。测试人员没有许多可以注射品质到系统中去的魔法仙尘（pixie dust）。
因为测试团队已经贡献了很多，所以这些目标的选择确实是不适宜的：
·给提供关键子系统的供应商传递了知识和测试的最佳实践
·创建一个自动化回归测试工具，它包括在定制和商业化成品的测试工具之间的首创集成
·在部署之前（即使这些bug被管理层批准可以推迟修复）测试团队发现了大部分的bug。
如果管理团队已经建立了基于那些贡献的可衡量目标，形势就会变得非常不同。
案例分析二：当你在大西洋时，请跨过它
我最近听说有个组织，它每年用两个相同的目标评估测试人员：
1.在测试人员测试过的子版本发布之后有多少个被用户发现的bug？测试人员的绩效评估等级随着这数目的上升而下跌。
2. 有多少因为开发人员以“设计原本如此”，“不可重现”等原因返回给测试人员而被归档的bug报告？测试人员的绩效评估等级－当然，象你猜到那样－随着这数目的上升而下跌。
这两个度量标准至少部分的在测试人员的控制之下。但是注意怎样使只有熟练的测试人员－或者正在测试一个十分琐屑的子系统的测试人员－才可以有希望在这些目标之内得到一个优秀成绩评估等级。而且，要注意任何尝试将其中之一的度量标准向零推动将倾向于将另一个度量标准抬高。也要注意到那些设计一些灰色区域的开发人员的力量，他们可能或不能将一份报告返回为“设计原本如此”。如果测试人员发现了设计中地一个问题或需求中的一个冲突，那么他最好不要说任何话，因为一个“设计原本如此”报告将损害他的评估！最后，当测试人员只是做比简单运行测试更多些的工作时，他们就不会被任何那些其他的活动所衡量。
面对这些目标的测试人员全部持反对意见。 少数向经理抱怨这些目标的人将会在前额上印上在所有经理书桌上都有的"并非一名团队成员"的大的红色印章。尽管这是很荒唐的行为，但是他们中大多数人决定他们还是要做正确的事情，尽他们最大努力证明什么是正确的事情－完全忽略施加于他们的绩效评估方案，并且只是做他们的工作。
经理至少可以使两个目标更现实些。任何过程所固有的错误和变化都有一个正常的水平。一对现实且可达到的这些目标的度量标准可能减轻一些极其苛性的效应。
案例分析三：走在你自己的地雷上
在以上的两个案例研究里，利用这些目标的管理人员或许心地是很正直。他们被告知，并且导致相信了定量的绩效评估方案是非常公正并且将使雇员的行为与公司的需要一致。然而，在有些案例中，我们遭遇了居然为了恶毒目的而使用MBO的管理人员。并且有时他们也获得了他们应有的下场。
不是太久以前，我听说一个用一种惊人的方式而产生相反后果的MBO处理的例子。在那个案例中，CEO发出的一封秘密email备忘中指出由于过多的兼并和买进而引起的资金紧缩，没有一个经理可以为超过一名的成员加薪。而且，备忘还说，要求每一个经理使用这个（已经确定的）计算人数的MBO方法。这证实了除了那一个人外的每个人都会责骂“令人满意”或者更坏。因此，给那个唯一的人以额定的“超出期望”的2％的加薪。
在那封邮件发出后的很短一段时间里，有些人－不管是一个反叛的管理人员还是一个截获到信息的人－决定以匿名的方式转发邮件给公司的所有人。当然出现了很大的喧嚣声。许多有其他选择的能人离开公司了。一些人匿名的张贴那封读过的邮件“冻结工资＝冻结代码？”。公司的士气被完全熄灭了。公司最后也破产。
那些执行者当然已经通过挥霍了他们全部现金而把他们自己放在一块岩石和一块硬地之间，但是与这样一个迂回的方案相比，肯定有更好的选择。或许CEO会召开一个公司会议，承认当前的形势， 接受对它的责任，并且通知人们加薪将推迟到资金形势改进后的一年里。人们会不开心，并且他们可能会对上层管理层的愚蠢而发牢骚，但是至少他们不会在背后戳穿他们以指责他们。
结论
俗话说，当你发现自己陷入困境时，要做的第一件事情是停止挖掘。 因此，如果你正用MBO为你的雇员挖掘一个punji 陷阱时，放下铲并且慢慢地走开，远离那些锐利的竹子。
但是我不能停止，你很可能会抗议－整个kahunas大社团都发布了经理应该使用MBO作为每年绩效考核过程的一部分的命令。不要担心，我们的解决方案不是停止使用MBO，而是停止使用糟糕的MBO。
以前写过一些测试人员和测试团队工作的目标，我发现一些有帮助的实践：
·确定测试团队怎样为组织提供有价值的服务。每个雇员在提供这些服务过程中扮演什么样的角色？
·使用SMART记忆方法提醒你创建以下目标：
o 明确且具体的，根据要度量的量化而定
o 可度量的，包括度量将发生的方式
o 雇员可以达到的
o 实际的，关于团队，组织和当前的项目内容
o 那些目标应该在确定的时期内发生的时间限制
·考虑你在每个目标里要给雇员什么样的奖励。目标为雇员指向更好为那些用户服务的方向吗？
·问问你自己正给每个目标什么样的信号。你将最重要的东西指引给雇员了吗？
·指定目标，但要为每个人留下获取它的方法。 你不想成为一个事必躬亲的管理人员，是吗？
尽管目标管理可能会引起一些问题，但是可以确信很多的管理人员可以成功地使用这种技术了。那些经理已经学习使用这些技巧－并且避免掉进我前面讨论的陷阱里。因此，让我们一同开始一个新的时尚：不再用糟糕的MBO了！
