关于软件研发生产力的误区与思考

误区一: 生产力完全取决于开发人员的活动

这是最常见的误区之一，它可能会导致不良后果以及开发人员的不满。有时，由于各种原因，出现了大量的活动，任务密集，工作时间的延长可能意味着开发人员必须“加班”以克服计划不周，来满足预定的时间表。另一方面，这些增加的活动可能是由于工程环境的糟糕，因此需要为开发人员提供完成工作所需的有效工具，或者需要更好地与团队成员协作沟通，以解除代码变更及代码评审的阻碍。

开发活动的度量本身并不能直接揭示背后的原因，也不应该孤立地用作奖惩。即使是简单的度量标准，如代码提交或代码审查的数量，也很容易因为数据缺口和度量误差而出现错误，而这些度量标准也会失去在结对编程或头脑风暴中获得的协作好处。另外，开发人员经常灵活安排工作时间以满足最后期限，例如一次性提交，这使得某些活动难以应用于生产力的评估。

误区二: 生产力只与个人表现有关

虽然工程师的个人表现很重要，但是为团队成功而做出的贡献对于生产力的衡量也是至关重要的。平衡开发人员、团队和组织的绩效度量非常重要。就像踢足球那样，最终的胜利既取决于球员的个人表现，也取决于球队的整体表现。

一个只为自己绩效负责的工程师可能会损害团队的生产力。那些以团队为中心的活动，如代码审查、事件响应、开发和管理工程平台等，有助于维护代码库和产品/服务的质量。在优化个人、团队和组织生产力时找到正确的平衡点，理解可能的权衡才是关键。

误区五: 生产力只与工程系统及开发工具有关

便捷的监控系统、客服系统、问题分发系统、日志分析系统都将有助于提高开发人员的效率。虽然开发工具和工作流程对开发人员的生产力有很大的影响，但是开发环境和文化等人为因素也有很大的影响。通常，对于保持工作环境和团队文化的健康，所需的关键工作对于许多人来说是“看不见的”，或者对于传统用于衡量生产力的指标来说是“看不见的”。诸如团队建设、现场指导团队的新成员和鼓舞士气、以及知识分享这样的工作对于支持一个富有成效的工作环境都是至关重要的，但往往不能衡量。

另外，如果开发者晚上在家工作的时候因为某个事件而被不断地呼叫，那么这些“看不见的”因素尤其会影响他们的工作效率。因此，有利于团队整体生产力的“看不见的”工作与其他更常见的测量维度一样重要。

误区六: 个人解决的问题数量才是最重要的

与软件开发生命周期中的许多其他活动一样，事件（如故障）处理也是一种团队活动。一个导致大量中断和花费更多时间进行恢复的服务会对开发和维护服务的整个团队造成不良影响。更多以团队为中心的活动，例如知识共享、准备故障排除指南、帮助其他团队成员、指导团队的新成员、进行适当的交接和分配任务，都是事件处理的重要方面。 

研发生产力的一个场景示例

以代码评审作为一个示例场景，这个场景可以涵盖所有五个维度的度量。

• 满足感

关于代码评审的测量可以揭示开发人员是从好的角度还是坏的角度来看待这项工作。例如，是否提供了学习、指导或者塑造代码库的机会。这一点很重要，因为如果一些开发人员认为他们被分配了不成比例的代码审查时间，那么代码审查次数过多可能引起他们的不满，因为那样他们就没有时间做其他工作。

• 绩效表现

代码评审速度既可以反映个人完成审查的速度，也可以反映团队的约束，所以它既是个人层面的度量，也是团队层面的度量。例如，一个人可以被指派在一个小时内完成一项审查，但有可能团队有一个政策，让所有的审查开放24小时，以便让所有人都能看到目标的变化。

• 研发活动

代码评审的完成数量是一个单独的度量指标，用于衡量在给定的时间内完成的审查数量，并为最终产品做出贡献。

• 沟通协作

代码评审本身是开发人员通过代码进行协作的一种方式，而代码评审质量的度量或评分是协作和交流的一个重要的定性度量。

• 流程效率

代码评审很重要，但是如果它中断了工作流程，或者延迟导致了发布环境中的约束，那么代码评审就会面对挑战。类似地，等待代码评审可能会延迟开发人员继续工作。批量化的代码评审可能不会中断开发人员的编码时间(这会影响单个度量) ，同时也不会造成发布的整体延迟(这会影响系统度量) ，这样可以让团队有效地交付代码(团队级度量)。因此，衡量代码评审时间对个人、团队和系统的效率和流程的影响很重要，这可以通过对评审的耗时和中断的特征(如时间和频率)进行测量来完成。

在这个示例中，研发活动度量是个体级别的指标: 提交次数、编码时间(总时间或每天的时间)和完成代码评审的次数，描述了直接有助于最终产品的工作，有利于理解工作模式和行为如何受到团队和环境的影响。

流程效率是更广泛的混合度量指标。自我 告的生产力指标是在个体层面的体现: 询问开发人员是否具有生产力盲点的影响，同时询问该成员是否干扰最小的情况下完成工作是一个有用的信 。无论是代码、文档还是其他项目，都可以测量工作流程，并获得诸如所用时间、移交次数、延迟和软件交付流水线中的错误等度量指标，这些指标构成了系统级度量。

一些局限的反思

太多的度量指标也可能会导致混乱和积极性的降低，并不是拥有所有维度才会有帮助。例如，如果向开发团队提供了一个广泛的度量矩阵和改进目标列表，那么可能会让人感觉这是一个无法实现的目标。考虑到这一点，一个良好的生产力度量标准至少包括三个维度上的一些指标; 这些指标可以提示一个整体的观点，并且足以激发改进。

任何测量范式都应该谨慎使用，因为没有任何度量是完美的。有些指标是糟糕的度量，因为它们是杂乱的近似值。例如，员工离职率会被用来衡量员工满足感，然而，这不仅仅只是满足感，它还可以反映薪酬、晋升机会、团队问题，甚至老板的变动。在团队层面，一些经理可能会阻止内转，以保护他们自己的职级。即使员工离职率确实反映了员工的满足感，也只是一种滞后的衡量指标，团队知道的时候已经为时已晚。

度量指标的建立应该注意到开发人员的隐私，并且只体现在匿名的聚合结果。然而，对于开发人员来说，个人层次的生产力分析可能很有见地。例如，开发阶段的工作依赖，能否在一天中有更多的编码时间等。

最后，任何度量范式都应该有偏差检查和规范，这些都是可能改变或影响具体实施的外部因素。

喔家ArchiSelf

一半是20多年老程序员的技术生涯，一半是人到中年却仍向往青春的生活感悟，交织起来，是一个享受生活的老码农。——Architect oneSelf 架构自己

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91767 人正在系统学习中