价值更快

如今,有一种普遍的“智慧”,即软件开发应能更快地发展。 从敏捷到持续交付和DevOps,一切都与速度的需求有关。

但是许多人都难以理解“更快”的好处。

从直觉上讲,人们认为走得越快,他们的能力就越强。 但是是否一定更好?

任何系统的吞吐量都受到其最弱子系统的吞吐量的限制。

如果企业的目的是向客户交付价值,而发展的目的是修改或创建软件,则企业通过软件交付价值的能力取决于其软件开发过程的吞吐量。 要增加吞吐量,您需要增加系统容量或系统流量。

您的企业是否受限于其通过软件交付价值的能力?

一个简单的经验法则是在软件开发生命周期之前查看需求队列中的变化。 它是静态的,还是队列大小在增加? 您是否需要从队列中清除项目? 队列中的停留时间是否增加?

如果对这些问题中的任何一个的回答为“是”,则您的软件开发生命周期将成为向客户交付价值的瓶颈。 我还从未见过一个组织,在这个组织中,用户和客户都在努力思考要实施IT的新想法。

同样,大多数人都从“直觉”的角度理解这一点,但是在软件开发中改变吞吐量很难。 增加容量的成本很高,并且收益递减。 增加流率是困难的,并且软件开发过程中固有的开销意味着交付小的更改的成本在天文上是很高的。 测试,发布和部署都增加了单个变更的成本,这使它的成本过高,因此将变更汇总到大型,长期项目中。

组织必须决定在哪里分配稀缺资源。 您是否将其委托给“改进项目”(解决吞吐量等问题)或“新计划”,为组织提供一些新功能或系统?

大多数组织中都有一套完善的工具来评估特定投资的财务收益。 它着重于衡量项目在ROI,NPV或IRR等方面提供的定量价值。 本质上,当选择要执行的项目时,组织将选择对组织回报最大的项目。

从外观上看,投资回报率可以用下图表示:

初始投资是一种成本,随着时间的推移会逐渐累积,直到项目实施并开始产生收益。 然后,它赚取了最初的投资,并(希望)随着时间的流逝将价值返回给组织。

曲线右端下方的面积越大-值越高。

但重要的是要记住,几乎所有投资都有持续的成本。 对于软件,这通常是持续的支持成本,例如基础结构,许可,更新和服务台支持。

将这些因素考虑在内会侵蚀项目后期的收益。 通常,ROI模型忽略了足够远的计划,无法包括特定计划的更换或更新成本。 对于软件,这些成本通常在短短2-3年内出现,并且可能对项目的商业可行性产生重大影响。

那么“走得更快”的财务收益是什么?

如果您可以将大型项目分解为可以迅速交付的较小变更,该怎么办?

使用我们已建立的模型,可以很容易地看到更快交付的财务收益。

如果您能够更快地交付较小的块,而不是交付大型的整体项目,那么可以更快地实现价值。 较小块的值由上方曲线和下方整体项目之间的区域表示。

或反过来,这就是“延迟成本”-进行大型项目的成本。

延迟成本是一种完善的投资财务模型。 要测量特定投资的延迟成本,您只需要为特定产品建模上面的曲线,然后计算由一个月延迟引起的成本变化。

当在针对其他变量(例如销量变化或项目支出变化)的敏感性分析中使用时,很明显显而易见,延迟成本(通常)是产品价值回报中最重要的因素。

例如,研究表明,延误的成本是航空公司调度的重要因素(参见Kara,Ferguson,Hoffman和Sherry 2010)。 结果表明,即使在燃油价格上涨和时间表更加严格的时期,航空公司还是选择减小飞机尺寸,而不是减少时间表并增加飞机尺寸。 从机场的角度来看,较少的,较大的飞机每趟可运送更多乘客是很经济的; 但是对于航空公司而言,经济因素有所不同,主要因素不是机场的处理成本,而是延误成本。

一旦您考虑了正确的指标,机场的“简单化”经济学就不会那么简单。

软件开发也是如此。

大型项目仍然是众人瞩目的焦点,但这只是因为我们使用了错误的措施。 与其围绕大型项目构建复杂的业务案例,我们不如直接提供连续的较小变更流,并在组织中释放数百万美元的价值。

与大多数国家一样,在澳大利亚,我们遇到了一些重大的大型IT项目失败:昆士兰薪资项目; 西澳州Fiona Stanley医院的海关服务综合货运系统和Victorian HealthSmart项目以及IAM项目。 每个组织都有其自己的祸患,但是重大的失败通常掩盖了更平凡的问题-所有IT项目中的80–90%无法实现他们承诺的价值[Victorian Ombudsman,2011]。

通过减少项目规模,我们减少了失败的风险。 通过更早,更小批量地交付价值,我们限制了更大的系统故障的风险。 而且,较小的周期还有另一个好处-更快的学习周期。 通过交付较小的块,我们可以缩短规划周期,从而可以更快地响应市场或消费者的变化。

越小 越快

那么为什么大型项目在许多组织中占主导地位?

组织通常会奖励表现出色的人,而大型项目则提供了许多成为明星的机会。 赞助商,项目经理和领导者都可以从英勇地交付困难项目的“光环效应”中受益。 但是,在一百个较小的片中,安静有效地传递相同的值的荣誉就少得多。

通过标准化(或自动化)软件开发生命周期中的重复性任务,您不仅可以更快地交付,而且可以使其更具可预测性。 用统计术语来说,您减少了系统中的“常见原因”变化,这使您可以将精力投入到复杂的软件开发领域的“特殊原因”变化中。

较小的可重复块是从软件中释放价值的途径。

那你会从哪里开始?

违反直觉,要做的第一件事就是减小批量大小。

这就是所谓的“降低水位去看岩石”。

通过减少批处理大小,您可以揭示系统固有的瓶颈和约束。 如果将批次大小减少到一周的工作量,但是更改和发布过程需要两周才能完成,那么系统的约束就会变得显而易见。

通过减小批量大小,您可以发现并解决阻碍吞吐量的障碍。

这就是工作的开始。