为了在市场中保持竞争力的技术公司都在进行某种程度的转型。敏捷转型、数字化转型和DevOps转型无处不在,因为公司试图改变他们的工作方式,从而改善业务结果。
指标(metrics)是任何转型的关键部分。传统的IT绩效指标,例如计算代码行数和软件bug的数量,应该谨慎使用,因为存在不值得修复的bug和不值得维护的代码。这些老式的绩效指标度量的是活动(activities),而非结果(outcomes)。活动指标很少能告诉组织对业务目标的真正影响是什么。
那么,应该如何度量呢?我们需要考虑Flow(流)相关的指标。Flow指标是一种绩效(performance)指标,它揭示了期望的业务结果的趋势 —— 例如更快的上市时间、对客户的响应以及可预测的发布时间框架。这些业务结果在成功的转型努力中起着至关重要的作用。请允许我向您介绍五个强大的流指标。
Flow Time(流动时间)
Flow Time是衡量一件事从开始到结束需要多长时间。你可能会想,“等等,这不是周期时间(Cycle Time)吗?”。你可能是对的。这取决于使用该定义的上下文。根据你所问的人的不同,“周期时间”有不同的含义,计时可能在不同的时间点开始或停止。理解周期时间是一个模棱两可的术语,这就是为什么我喜欢在讨论速度指标时使用Flow Time。因为Flow Time对于大多数人来说是一个陌生的术语,它提供了一个清晰定义含义的机会。Flow是通过系统顺利且可预测的值,是支撑DevOps的三个基本原则中的第一个。
Flow Time说明:当请求(request)被批准时,计时开始,当变更生效并在生产环境中运行时,计时结束。
Flow Time计算开始时间和结束时间。Flow Time不会因为周末的到来而停止。Flow Time所做的是量化在该时间段内完成给定工作的概率。
例如,如果历史Flow Time显示,某种类型的工作有90%的概率在30天内交付,这样我们就可以说,10次中有9次我们可以30天内交付该类型的工作。我们知道有10%的可能需要更长的时间。这让我们对客户的需求有更好的可预测性。
译注:在DevOps里通常会用到Lead Time(前置时间)这一术语。但Lead Time也来源于工业生产里,这样也会出现歧义。Flow Time这样一个专有名词显然更好。
Flow Efficiency(流动效率)
好的指标让我们有更清晰的全景和对诸如“何时能够完成?”这样的问题有更准确的答案。到期日(due date)这样的指标很少考虑等待时间。然而问题通常不在于处理工作的时间,而在于等待时间。
想想由于工作依赖而造成的延迟——当涉及到需要多长时间完成工作这样的问题时,等待时间往往比实际处理工作时间影响更大。你最好是估计等待时间,而不是工作时间。等待时间通常消耗85%或更多的Flow Time。
译注:这个指标也叫PCE(Process Cycle Efficency)。
WIP Report(在制品报告)
把工作分解成更小的部分是很重要的,这些部分可以很快完成并交付。交付越快,反馈就越快。太多的在制品(WIP)(在Flow Framework中称为“流负载”),为更多的工作间依赖、更多的冲突优先级、更多的计划外工作悄悄开了口子,这会导致延迟。获取WIP趋势并将其与Flow Time结果进行比较,可以帮助我们了解组织中的WIP与速度之间的关系。