作者 | rafiq gemmail
译者 |平川。
策展 | tina
Gergely Orosz（《The Pragmatic Engineer Newsletter》的作者）和ABI Noda（DX的首席执行官和DevEx框架的创建者之一）在Pragmatic Engineer上发表了一篇题为“Development Productivity Measure： A Real-World Case Study”的文章。 InfoQ 报道了 NODA 对 17 家知名科技巨头使用的工程指标的调查结果。 NODA发现，顶级团队并没有大规模采用DORA或SPACE等框架，而是混合使用特定于组织的定性和定量指标。 NODA 和 Orosz 根据指标实施团队寻求的结果进行逆向工作，为定义此类指标提供建议。
野田写道，他“采访了 17 家衡量开发人员生产力的知名科技公司的团队”。 在这篇文章中，Noda和Orosz重点介绍了四种类型的组织：拥有10万名员工的谷歌，拥有1万名员工的LinkedIn，员工人数少于10,000人的Peloton，以及员工人数少于1,000人的Notion和Postman。 使用的指标范围从典型的 PR 和 CI 指标到 Google 系统选择的指标。
NODA观察到，在实践中，“DORA和SPACE指标是有选择地使用的”，而不是完全使用。 他写道，虽然调查显示“每家公司都有自己量身定制的方法”，但他认为“任何规模的组织都可以采用谷歌的整体理念和方法。 Noda写道，谷歌的方法要求根据三种类型的指标来选择指标：速度、易用性和质量。 他写道，这三个维度之间存在着一种“紧张的关系”，“有助于揭示潜在的权衡”。
野田写道，谷歌使用“定性和定量措施来计算指标”，因为它提供了“最全面的图片”。 野田列举了谷歌使用的一系列信息获取方法，从满意度调查到“使用日志指标”。 他写道：
无论是衡量工具、流程还是团队，Google 的开发智能团队都认为单一指标无法衡量生产力。 相反，他们从速度、易用性和质量方面看待生产力。类似地，Noda和Orosz描述了LinkedIn如何将季度开发人员满意度调查与定量指标相结合。 在文章中，Noda提到了LinkedIn开发者洞察团队使用的一系列指标。 这些指标旨在减少“对关键发展活动的抵制”。 团队使用的指标包括 CI 稳定性指标、部署成功率、P50 和 P90 生成时间、评审响应时间以及提交通过 CI 管道的时间。 Noda 描述了团队如何通过定性见解来支持这种定量衡量标准，并给出了一个将构建时间与“开发人员对构建的满意度”进行比较的示例。 LinkedIn还使用“Winsorated Mean”对客观数字指标进行降噪。
温莎平均值意味着找到第 99 个百分位数，然后将所有数据点切到第 99 个百分位数以上，而不是剔除它们。 如果第 99 个百分位数是 100 秒，而您的数据点是 110 秒，则划掉 110 并写入 100，现在您计算的平均值是一个更有用的数字。野田写道，Peloton代表了一个拥有3,000至4,000名员工的组织，它已经从最初的“通过开发经验调查获得定性见解”发展到纳入定量指标。 例如，提前期和部署频率被用作速度的客观指标。 他写道，Peloton 的指标还包括定性参与分数、服务恢复时间和**质量（通过“250 行以下的 PR、线路覆盖率和变更失败率”的百分比来衡量）。
在谈到像 Notion 和 Postman 这样规模较小的“扩展”组织时，Noda 写道，这些组织通常专注于衡量“可移动指标”。 他解释说，这是一个易受攻击的指标，指标实施团队可以“通过他们的工作对指标产生积极或消极的影响来四处走动”。 这方面的一个例子是“易于交付”。 Noda写道，这个指标反映了“认知负荷和反馈循环”，可以根据“开发人员觉得完成工作的难易程度”进行调整。 另一个常见的可移动指标是“开发人员因障碍和阻力而损失的时间百分比”。 NODA 描述了该指标如何反映其价值：
这个指标可以兑换成钱：这是最大的好处！ 这使得企业领导者很容易理解时间损失。 例如，如果一个拥有 1000 万美元工程工资成本的组织通过一项计划将损失的时间从 20% 减少到 10%，这将节省 100 万美元。鉴于此类工程指标的上下文性质，NODA 建议组织在以下步骤中定义指标：
在使命宣言中定义你的目标，解释“你为什么有一个开发生产力团队？ ”
从目标开始，根据速度、易用性和质量定义顶级指标。
定义与“特定项目或目标关键结果”相关的“运营层面指标”，例如，特定开发生产力提高服务的采用率。
NODA举例指出，所选择的指标应考虑速度、易用性和质量等维度。 例如，如果目标是让开发人员更容易“交付高质量的软件”，那么指标应该包括“感知交付速度”、“交付的难易程度”和“事件频率”，他说。
Orosz 和 Noda 的这篇文章遵循“回应麦肯锡：衡量开发人员生产力？ 之后又发表了一篇文章。 在上一篇文章中，Orosz 与 Kent Beck 合作挑战了麦肯锡的文章“是的，你可以衡量软件开发人员的生产力”。 麦肯锡的文章提出了我们所说的“以机会为中心”的指标，“以确定如何改进产品的交付方式以及如何提高价值”。 本文讨论了基于 dora 和 space 的开发人员生产力衡量标准，包括鼓励领导者优化单个开发人员效率的建议，以及“非编码活动（例如，设计会议）”的示例。 本文提出的指标包括跟踪“个人贡献”和衡量“人才能力得分”。
贝克警告说，衡量个人生产力而不是交付结果的风险，并分享了他自己的经验，看到这些指标变成“激励改进的金钱和地位指标”。 他说，虽然这可能导致“行为改变”，但它也可能受到游戏化的影响，变成“以创造性方式改进这些指标”的激励措施。 Beck和Orosz鼓励领导者专注于衡量“影响”而不是“工作量”。 特别是，贝克建议，这些指标应该只用于被测量事物的持续改进反馈循环，而不是其他任何事情。 他还警告说，滥用指标来衡量个人可能会导致安全问题：
弄清楚你为什么要问这个问题，以及你和被测量者之间的权力关系。 当那些有权力的人衡量那些没有权力的人时，结果是扭曲的......分析它收集的任何级别的数据，以避免不正当的激励。 我可以分析我自己的数据，我的团队也可以分析他们自己的汇总数据。 NODA 还警告说，如果 CTO、VPE 或工程总监级别的人员需要提供开发人员绩效指标，最好确保报告处于适当的水平。 NODA 建议选择表示业务影响、系统性能和工程组织级开发效率的指标，例如项目级指标用户 NPS 和损失的一周时间。 NODA建议高层领导：
在这种情况下，我建议最好重新定义问题。 你的领导团队不想要完美的生产力指标，而是一种强调你是他们工程投资的好管家的方法。在回应麦肯锡的报告时，Orosz和Beck警告说，“人们会优化所衡量的东西。 他们引用了古德哈特定律，该定律指出“当一个措施成为目标时，它就不再是一个好的措施。 ”
原文链接：