改进与成就是组织中应该存在的一种持续的紧张状态。成就关于是否在朝着成效前进,而改进指标关于是否在领域内做得更好。它们能帮助组织变得更好。
做了多少与贡献了多少价值是不同的。由于价值难以衡量,有时也无法量化,因此在没有价值度量的情况下,正在进行的活动或工作就变成了替代性的度量标准。
瀑布式软件开发方法是度量完成的工作而不是交付的价值的典型例子。将产品周期分解为多个步骤:需求收集、特性和架构设计、编码和实现、测试、投产使用。如果需求没有不确定性,开发过程中没有战略或市场条件的变化,技术平台和集成没有意外发生,生产环境和开发环境之间没有差异,那么这就是一个完美的模型。我们很久以前就认识到这实际上是不可能的,敏捷软件开发方法就是这样诞生的:解决瀑布方法缺乏灵活性和适应性的问题。
瀑布方法的另一个有趣的症状是,项目几乎总是看起来是在正轨上,直到即将完成。需求收集、设计、编码——这些阶段客户还不能使用系统,因此没有向客户交付任何价值。然而,从工作完成的角度来看,项目团队进展顺利,庆祝了一个又一个里程碑——整洁的文档和信息板在整个流程中被完美地生成和呈现。通常,项目预警在编码和测试的后期才会响起。如果软件突然要投入使用的话,只有20%的特性可以投入生产,而不是完成了80%。项目状态一夜之间从绿色变为深红色。计划被推迟了,预算增加了。根据《哈佛商业评论》的一项分析,平均项目成本超支27%,其中六分之一的项目超出成本200%,进度延迟70%。
使用经典的敏捷方法和精益的持续改进思维模式——了解当前状态,设置目标状态,持续迭代——是数字化转型的基本思路。它支持捕获较弱的信号,帮助更早地识别约束,鼓励探索和学习活动,培养试验心态。
改进指标还有一个额外的好处:比传统的量化度量标准更易于解释,使那些不熟悉这种工作方式的人习惯,还能提供定性的见解。
一些有用的改进指标示例包括:
质量
缺陷减少量、自动化测试覆盖率、调用次数减少量、了解新信息后得以停止的工作量。
生产力
累积流图用于确定需要改进的方面(包括等待时间或交接时间)、团队待完成的工作量、已有能力与所需能力之间的对比。
吞吐量
在一段时间内交付的价值量、验证想法的周期时间。
可预测性
如不确定性圆锥体,无论是在容量规划、技能规划、财务规划,还是在能够利用的想法的数量上,都应该看到可预测性随着时间的推移而增加。
财务
花费的资金与交付的价值、单位价值成本、探索和维持业务之间的投资组合平衡、成效的投资回报(ROI)、每件工作交付对客户价值成效的影响。
敏捷软件交付和持续交付方法强调:从工作中抽取一小部分,从头到尾完成,在进入下一个部分之前就交付价值。这也是在数字化转型过程中提倡的精益切片方法的根基(见第3章)。这种迭代、增量的方法创建了度量端到端价值(而不是活动和完成的工作)的基础和可能性。敏捷方法并不能保证度量价值,事实上,我们已经看到太多敏捷软件项目使用类似于瀑布项目的方法(不完全相同)来度量和报告已经完成的活动和工作。
人们对记录完成了多少工作、投入了多少努力似乎存在一种强烈的制度愿望。这就是我们看到的一些“管理游戏”。为了预算的目的把工作量和竞标捆绑在一起,最终会得到虚构的承诺,还将花费大量时间来管理信息以展示进展或为缺乏进展进行辩护。
改进度量是组织需要建立的关键能力,以便优化客户价值并消除交付的限制。改进度量能显示数字化转型是否推动了预期的改变和进步。在第12章中,我们将讨论建立持续学习和持续改进文化的重要性。认识并实施改进指标将有助于加强这种文化。