从 CEO 的角度来看，DORA 指标仍是工程领域的指标，对业务领域的表达有限。

关注我，每天收获一个新技能!

在我们深入话题之前，我想快速介绍DORA指标。DORA 是指：

DevOps Research and Assessment 

这四个关键指标——部署频率、变更故障率、平均恢复时间以及代码前置周期时间——被定义为加速交付的关键指标。

注：2021年， DORA团队加入了第五个指标：可靠性(Reliability)。

其中，

前两个指标以紫色显示，代表速度，即团队在整个开发流程中移动工作项的速率和效率。

橙色显示的后两个指标，则代表稳定性，关注代码发布到生产环境后的质量及其稳定性。当你同时拥有高速度和高稳定性时，奇迹便发生了。

因此，衡量这四项指标是非常有价值的。

然而，这里存在一个问题，那就是，DORA指标在工程领域之外的实用性比较有限。

当工程团队向 CEO 汇报说，我们的部署频率提升了 27%，这听起来是个不错的成绩。但是， 从 CEO 的角度来看，他们更关心这些数字背后，代表了哪些真实的业务意义。比如，

这是否意味着公司能够达成季度目标？

是否意味着这个月能更多用户功能？

是否意味着我们正在向客户交付正确的产品？

如果DORA指标无法回答这些问题，那么它们就没有真正触及业务的核心。

CEO 和其他业务领导者真正关心的是，工程团队能否兑现承诺，更快地交付更多功能，并提供出色的客户体验。这些是他们希望从工程中获得的业务成果。

但是，DORA 指标并不总能直接转化为这些成果。例如，企业关心的是整个功能，而非单独的代码片段或单个提交。周期时间和部署频率虽然重要，但DORA衡量的是代码段的流动速度，而非整个功能的交付。

同样，变更故障率和平均恢复时间提供了发布代码的稳定性信息，但它们并不直接反映是否更多功能被交付给客户。

此外，DORA指标是滞后性的，它们衡量的是过去已经发生的事情，而不是预测未来的成果。

开发人员也很可能并不真正关心 DORA 指标，他们更关心的是快速解决问题，合并代码，并继续下一项任务。因为这种快速迭代和成果交付的过程，为开发人员带来了成就感。

我们需要认识到，DORA 指标只是整个产品研发大局中的一个数据点。我们需要更广泛地观察，包括工程效率、执行团队的效率以及最终的业务成果。如果我们过分关注 DORA 指标而忽视了整个画面，我们可能会失去对真正重要的业务成果的视角。

为了提高DORA指标和业务成果，我们需要从引导指标着手，如需求的大小、CR审查时间和整体审查过程。这些指标能够影响工程成果，进而影响业务成果。

例如，我们发现小型的Pull Request（PR）更容易被审查和合并，减少了返工和流失，提高了速度和稳定性。

保持PR的小规模，可以加快代码的流动速度，减少引入新bug的机会，从而提高整体的工程效率。

此外，企业还希望看到工程团队能够准确规划并兑现承诺，提供深思熟虑的客户体验。这包括规划准确性、资源分配以及对承诺的深思熟虑。

企业希望了解工程团队是否在正确地分配资源，以及是否能够灵活地响应新的优先级和需求。

如果你只想评价，那么就关注结果性指标。

如果你想改进，那么就多关注引导性指标。

最后，为了可持续地提高领先指标、DORA指标和业务成果，我们需要采取一系列措施。

首先，需要获取团队的基准指标，了解他们在行业中的位置。

其次，建立团队目标和工作协议，确保团队成员对目标和协议有共识。

最后，考虑引入自动化来优化开发人员的工作流程，提高效率。

通过这些步骤，我们可以确保我们的 DORA 指标和业务成果不仅在数字上表现良好，而且能够真正反映我们的工程和业务成功。