CEO 必须知道的 5 个新绩效指标!

| 2022-02-01

没有 CEO 会在不了解收入、流失率或烧钱率的情况下,还能够经营自己管理的公司。但在「 move fast 」的竞争里,当市场发生变化时,他要能立即推出一个产品更新(就像之前一样)。如果速度足够快,他就可以利用这些很小(通常以小时为单位)的变化,就能在任何无法快速调整的竞争对手面前,获得关键的市场份额。

为了最大限度地提高速度,CEO 们应该考虑一些「非传统」的指标,比如变更前置时间( commit-to-deploy time )、构建时间( build time )、排队时间( queue time )和测试覆盖率( test coverage )。

这些指标可以让CEO们更清晰地了解他们的软件开发的路线轨迹,以及可能阻碍他们前进的因素。

但是,在了解这些指标含意之前,需要记得下而五个重要事项。

研发效能度量中最重要的事情

  • 研发效能度量是需要结合上下文的。
  • 研发效能度量是有成本的。
  • 仅有度量数据是不能产生改善的。
  • 度量数据自身的质量本身也是非常关键的。
  • 度量(即便不考核)会带来人的行为改变,这种改变可向「好」,也可向「坏」。

变更前置时间 「 Commit-to-Deploy Time ( CDT ) 」

变更前置时间是指:一次代码变更从提交到部署所需的时间。在这两点之间,它可能会经历集成、测试和预生产测试,当然,具体经历哪几个阶段取决于你的组织流程。测量 CDT 的目的是了解代码从部署流水线的一端到另一端需要多长时间,以及遇到了哪些障碍(如果有的话)。

在理想情况下,如果您已经实现了持续集成(CI)最佳实践,并且您有足够的自动化测试覆盖率,你可以在几分钟完成从提交到部署就绪的状态。假如恰巧系统是微服务架构,甚至几秒钟内完成这一过程。但是,如果你的整个过程中在很大程度上是依赖于手工验证的过程,这很可能意味着这一部署时间会长一些,也意味着你的组织流程还有改进空间。

大多数快速发展( fast-moving )的组织(如 Facebook 、亚马逊)每天部署数百次。对于较小的组织来说,「每日部署」是一个很好的目标。你每个提交的变更越小,它们投入到生产环境的速度就越快。一旦发现它们出错了,修复的速度也就越快……总有出错的时候。更频繁的部署也会让你的团队习惯于这么做,这也可能让团队会做得更好更快。

那么,如何测量 CDT 呢?使用「时间戳」。对于每一次通过代码审查并合入的代码变更提交,记录它发生的时间。使用 git 意味着您可以免费获得这种粒度的变更信息。在部署方面,你也会做同样的事情————注意:部署意味着你的用户可以看到或使用它。「平均前置时间 CDT 」实际上取决于应用程序的大小和复杂性。但是,「少即是多」,所以你需要尽可能做一些改进来缩短这个时间。这些改进可能更多是在技术方面的的改进(例如,我们的测试是不稳定的),或者是面向过程(例如,我们在应该使用单元测试的时候却使用了更为复杂的集成测试),或者技术或流程这二者的某种组合。无论如何,您的目标应该是逐步提高变更前置时间。

构建时间 ( Build Time )

浪费时间最糟糕的情况之一(但有些不可避免)是 SRE 工程师和开发人员坐在一起等待测试完成。这些测试工作的规模越大、内容越全面,花费的时间就越长。无论你把这些测试工作堆得有多高,你只能看着高薪员工在那里被微博或朋友圈,或者无聊的GIF分散注意力,而不是设计或编码。

让我们看看成本:如果有两个开发人员在等待测试,他们每小时都要支付50元(每年约10万元),那么10分钟的构建时间将使您损失大约17元的生产率。虽然缩短这10分钟似乎是一个很蠢的改变,但如果每个开发人员每天运行五次这种类似的测试工作,那么每周总计833元(每年43000元)。在更大的背景下,有些测试很可能需要一个小时才能执行。除了这些明显的直接成本外,还有难以量化的「丧失机会」的成本,即:不能更快地进入市场的成本,以及开发人员等待、然后跳回开发的心理「转换成本」。

构建时间实际上包括测试的运行,以及运行这些测试所需的任何准备工作。这些准备工作包括创建一个测试数据库,在该数据库中植入测试数据,以及在测试套件之间设置/拆除数据库,这样就不会污染数据。

和 CDT 一样,「好」的构建时间取决于上下文,但这个时间几乎总是越短越好的。将相关测试放在一起可以防止不必要的设置环节和拆卸环节。「CI 最佳实践」还建议首先运行那些运行比较快的测试,并且一旦有错误出现,尽快发现它们,并取消构建,马上修复它们。

排队时间( Queue Time)

比构建时间更微妙的是,工程师在构建执行之前的等待时间。这个指标高度依赖于组织的规模,以及同时并行开发的特性的数量。讽刺的是,在每次提交时运行构建,这恰恰是开发人员应该做的事情,这可能会进一步加剧这种情况。

但是的长时间排队,成本是非常昂贵的。虽然开发人员可以在另一个项目上工作,但这也冒着失去刚刚所编功能的需求上下文的风险。

如果他们并没有将注意力转到下一个工作项目上,而是将注意力集中在等待测试的这次变更上,那么,比构建时间更糟糕的是,如果工程师因为发现测试失败而中断了这次构建,这就让“最大构建时间”缩短;而排队时间不允许这样的捷径。

对于每一个要被测试的变更,应跟踪它从队列尾到队列头部所需的时间。这可以简单到让工程师记录他们在构建开始执行之前等待的时间。

保持较低的排队时间,让工程师的工作可以持续吧~

主干变红的频率( How Often Master Is Red )

开发人员使用「主干分支」作为所有新工作的起点。这是真相的主要来源,所以如果它变成「红色」,就意味着每个人都陷入了困境,因为没人能发布代码,整个部署流水线嘎然而止。假如变红时,恰好有人要发布一个密钥安全修复的代码变更,他们不得不等到主干被修复。

在很多组织中,如果主干上的代码出现故障,可能需要几个小时才能修复。这不是你想看到的情景。如果组织不关注尽快修复红色的主干,这表明了以下几点:

  • 如果你的测试套件不稳定或者测试不可靠,主干就很容易会变红。
  • 代码库的测试覆盖率也会影响主代码变红的可能性:不良的测试覆盖率会导致构建失败。
  • 长期存在的特性分支很可能会以因最后的合并冲突而失败。变更集越大,你的代码就与其它地方的代码差异越大。帮助避免这种情况的一个 CI/CI 原则就是:每次提交少量变更,而不是进行「大爆炸式」的合并。

让主干处于不好的状态也可能仅仅表明了开发实践或开发文化不好。你的组织可能没有足够的紧迫感,在第一时间修复主干——这个「真北之源」。当主干变红时,它为代码提交造成了瓶颈,让修复时间变长,而且让开发延迟了。

持续交付的一个原则是强调始终保持软件「绿色」,即:软件一直处于可部署状态。如果它不是绿色的,你在它坏掉的那一刻就应该修复它,而不是让它流连忘返。无论谁破坏了它,都应该全心专注于修复这个问题,如果需要,还可以从其他团队成员那里获得帮助。这与看板方法中的「红色按钮」有些相关:任何人都可以而且应该在发现缺陷时按下红色按钮,以便尽快修复问题。也就是说,一旦按下红色按钮,每个人都需要尽快让「装配线」再次启动。

你如何衡量这个呢? 每次主干变红时,启动一个累积计时器。将这个数字除以今年迄今为止的剩余时间。这是主干花费在「红色」的时间百分比。要获得更详细的信息,您可以按月或按天细分。或者:计算从红色回到绿色的平均时间。 这应该不超过一个小时。

让主干保持绿色就是为了防止瓶颈和保持公司的敏捷性。

工程开销( Engineering Overhead )

工程开销包括员工人数,以及在一些花费,如购买的 License 和 AWS 等,当然,也包括工具的维护成本。虽然很多 CEO 会跟踪每个席位的工具成本,但他们并不关注配置、维护或监控这些工具需要多少时间。你的工程团队中是否有人主要负责维护每个人都使用的工具?工程师在这种类型的流程工作上花费了多少小时而不是构建功能?

如果一个工具需要一直花费大量时间和精力才能发挥期功能,你可能需要重新评估它的价值。工程师花在工具上的时间减少了他们花在产品上的时间。工程师希望使用最好的工具:不要以牺牲基础设施或工具的质量为借口。

其它指标

以上就是 CEO 应该知道的五个较大的非传统指标,但为了确保他们保持竞争力,还应该回答以下几个问题:

  • 开发人员每天向主干合并多少次?
  • 代码库多久处于可发布状态?
  • 代码测试测试覆盖率是多少?
  • 是否优化了我的工具和基础设施?
  • 通过替代工具(基础设施解决方案)的潜在速度增益和节省是什么?