一个亲身经历的故事。 为篇幅道歉。
几年前，我们的开发小组尝试为个人和团队领导设定“适当的”可衡量的目标。实验只持续了一年，因为硬指标对于个人目标并不是很有效（请参阅我关于该主题的问题以获取一些链接和进一步讨论）。
请注意，我是一名团队负责人，并与我的技术老板和其他团队负责人一起参与计划，所以目标不是由无知的高层管理人员从高层决定的——当时我们真的希望他们发挥作用. 还值得注意的是，奖金结构无意中鼓励了开发人员之间的竞争。以下是我对我们尝试过的事情的观察。
客户可见的问题
在我们的案例中，我们计算了我们为客户提供的服务的中断。在收缩包装的产品中，它可能是客户报告的错误数量。
优点：这是对高层管理人员可见的唯一真正措施。它也是最客观的，在开发组之外进行测量。
缺点：没有那么多中断——每个开发人员一整年大约只有一次——这意味着失败或超过目标是每个团队确实发生的少数中断“归咎于”的问题。这导致了不好的感觉和士气的丧失。
完成的工作量
优点：这是唯一的积极措施。其他一切都是“当坏事发生时我们会注意到”，这令人沮丧。它的包含也是必要的，因为没有它，一个全年无所事事的开发人员将超过所有其他目标，这显然不符合公司的利益。测量完成的工作量检查了开发人员在估计任务大小时的自然乐观情绪，这很有用。
缺点： “已完成工作”的衡量标准是基于开发人员自己提供的估计（通常是一件好事），但将其作为他们目标的一部分会鼓励系统博弈以夸大估计。我们没有其他可行的衡量已完成工作的方法：我认为衡量生产力的唯一可能有价值的方法是“对公司底线的影响”，但大多数开发人员都远离直销，这在个人层面上很少实用。
在新的生产代码中发现缺陷
我们衡量了这一年引入新生产代码的缺陷，因为认为前几年的错误不应计入今年目标中的任何个人。内部质量团队发现的缺陷即使不影响客户也被计入计数。
优点：出奇地少。引入缺陷和发现缺陷之间的时间差意味着实际上没有立即反馈机制来提高代码质量。团队层面的宏观趋势更有用。
缺点：过于关注负面因素，因为只有在发现缺陷并且我们需要有人为此负责时才会调用此目标。开发人员不愿意记录他们发现的缺陷，简单的计数意味着小错误与严重问题一样糟糕。由于每个人的缺陷数量仍然很低，轻微和严重缺陷的数量并没有像更大的样本那样均匀。旧缺陷不包括在内，因此该小组在代码质量方面的声誉（基于发现的所有错误）并不总是与今年引入的可衡量数量相匹配。
项目交付的及时性
我们将及时性衡量为在规定的截止日期前交付给内部 QA 团队的工作的百分比。
优点：与计算缺陷不同，这是一项由开发人员直接直接控制的措施，因为他们有效地决定了工作何时完成。目标的存在将注意力集中在完成任务上。这有助于团队投入实际的工作量，并提高内部客户对开发组兑现承诺能力的看法。
缺点：作为开发人员直接控制的唯一目标，它以牺牲代码质量为代价最大化：在截止日期的那天，如果选择说任务完成或进行进一步测试以提高对其质量的信心，开发人员会选择将其标记为完成，并希望任何由此产生的错误永远不会浮出水面。
来自内部客户的投诉
为了衡量开发人员在软件开发和后续支持期间与内部客户的沟通情况，我们决定记录收到的关于每个人的投诉数量。投诉将由经理验证，以避免任何可能的报复行为。
优点：我真的什么都想不起来了。在足够大的群体水平上衡量，它成为更有用的“客户满意度”分数。
缺点：不仅是高度消极的，而且是主观的衡量标准。与其他目标一样，每个人的数字都在零分附近，这意味着对某人的单个评论可能意味着“无限超过”和“未达到”之间的差异。
普通的留言
官僚主义：虽然我们的任务管理工具保存了这些指标的大部分数据，但仍然需要大量的人工来整理这些数据。获得所有数字所花费的时间并不愉快，通常集中在我们工作的负面方面，甚至可能没有通过提高生产力来回收。
士气：对于那些将问题归咎于个人的措施，不仅那些得分“差”的人感到士气低落，而且得分“好”的人也感到士气低落，因为他们不喜欢团队士气的损失，有时会觉得他们是排名更高不是因为他们更好，而是因为他们更幸运。
概括
那么我们从这一集中学到了什么？在后来的几年里，我们试图以一种“更温和”的方式重用一些想法，减少对个人责任的强调，而更多地强调团队的改进。
- 不可能为个别开发人员定义客观可衡量的目标，为公司增加价值并且不能被游戏，所以不要费心去尝试。
- 客户问题和缺陷可以在更广泛的团队级别计算，如果缺陷的位置明确是该团队的责任——也就是说，你不必玩“责备游戏”。
- 一旦您仅在代码模块的责任级别上衡量缺陷，您就可以（并且应该）衡量旧错误和新错误，因为消除所有缺陷符合该团队的利益。
- 在组级别测量缺陷计数会增加每组的样本量，因此可以消除轻微缺陷和严重缺陷之间的异常，并且简单的“错误数量”测量可能意味着一些事情，例如查看您是否在逐月改进月。
- 包括高层管理人员关心的事情，因为让他们开心是您作为开发团队的主要目的。在我们的案例中，这是客户可见的中断，所以即使测量有时是武断的或看似不公平的，如果这是老板正在测量的，那么你也需要注意。
- 高层管理人员不需要查看他们在自己的目标中没有的指标。这样就避免了将错误归咎于个人的诱惑。
- 衡量项目交付的及时性确实改变了开发人员的行为，并将重点放在完成任务上。它改进了估计并允许小组做出现实的承诺。如果收集及时性信息很容易，那么我会考虑在团队级别再次使用它来衡量随时间的改进。
当您需要为单个开发人员设定可衡量的目标时，所有这些都无济于事，但希望这些想法对团队改进更有用。