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