敏捷和 TBM：让 IT 业务变得更好

*Dean Leffingwell 是 Scaled Agile Framework (SAFe®) 的创建者，也是 Scaled Agile, Inc 的联合创始人。他与公司合作，将敏捷开发规模从数个团队扩展到数十甚至数百个团队，以构建大规模系统和软件解决方案。

一位 IT 分析师对此做出了最好的总结：“就在几年前，企业还在实施一些敏捷方法，他们在敏捷项目上花费 500 万到 1000 万美元。从相对投资和治理的角度来看，如何花钱或钱花在哪里并不重要。这是一个有趣的实验，他们很喜欢结果。但现在，他们正在研究需要 5000 万至 1 亿美元或更多投资的项目，而且这些项目将以敏捷方式完成。这改变了一切。”

首席信息官和首席财务官等高管尤其意识到，他们不能再忽视敏捷，因为它即将取代公司的大多数流程。如果他们现在不实施新的财务和治理模型，他们就会被压垮。

如今，成功扩展敏捷开发的公司业务表现为更频繁的发布、更快的上市时间、更高的质量和更好的员工敬业度。生产效率可以显著提高，比如 30%-50%，上市时间通常缩短为二分之一或三分之一甚至更短。随着人们看到他们的代码更快地进入市场并从用户那里获得更快的反馈，员工敬业度会提高。

事实上，敏捷并不是一时的热潮。这是一个大趋势，正在使业务和 IT 业务变得更好。

如今，敏捷要求与企业进行不同类型的合作。过去，IT 团队可能会说：“好吧，这是你要求的”。企业可能会（在一年后）对其交付的产品做出回应，并说：“这并不是我们要的东西，顺便说一句，业务需求已经发展，现在需要其他东西了”。

传统上，IT 业务拥有很清晰的行事流程：与业务分析师合作，写下规范，做业务案例，构建解决方案，然后继续。

但实际上并非如此。在 IT 方面，现实情况是这样的：只有当您的业务所有者说它很好时，您的解决方案才是好的。是否按照规范编写并不重要。只有当企业主说解决方案解决了他们的问题并希望继续合作时，这才是最重要的。

进入敏捷开发。从这些应用程序中获得益处的业务线人员必须参与并持续参与解决方案的开发。不存在“写好规范，开好支票，然后走人”的情况。现在，对业务的影响很大，但所需的参与度也更高。找到解决方案的唯一方法是共同努力。

扩展的敏捷模型直接让企业主参与反馈、知情决策、持续确定工作优先级以及一切必要事项，以确保结果符合当前需求。传统的交接方式已经改变。敏捷解决方案开发不是一个孤立的职能或一系列规格。这不是一个从理论上证明这一观点的商业案例。相反，是人们在整个开发时间框架内共同合作。

遗憾的是，传统基于项目的资金模式不适用于敏捷项目。这类项目创建“为临时人员设置临时工作”，虽便于围绕新工作组织思路，但无法支持价值的持续流动。

在 Agile 中，您以不同的方式管理工作。这不是通过单个任务和时间的使用；而是通过您希望实时看到系统中流动的价值小片段。当有人说他们的组织是按职能组织的，他们启动项目并衡量使用情况时，影响会立即显现出来。

敏捷口号是产品，而不是项目。这代表组织考虑投资、财务和回报方式的重大转变，需要基于价值而非基于任务的工具。现在，传统会计中围绕基于项目的工作存在的大部分内容（工时表、记录和捕获）都是价值流动的巨大障碍。

敏捷的核心是灵活应对变化，而非僵化执行计划。这要求转向基于客观证据的决策：快速反馈、早期指标与可预测性。敏捷团队是否在特定时间框架内完成了既定承诺？若业务负责人需要调整方向，敏捷团队能否应对？

总体而言，该模式将从投资回报率转向假设驱动的开发和最小可行产品 (MVP)。投资回报率的理论概念与具体数字一样有吸引力，但投资回报率只是对事情按计划进行时可能获得的回报的猜测。而事情很少按计划进行。即使确实如此，数据也无法获得，直到为时已晚，因为投资回报率在开发过程中不提供反馈。

要了解敏捷的有效性，我们要寻找早期指标和所谓的创新核算措施。我们定义了良好价值的预测因子，这些预测因子在投资回报率之前就出现了。归根结底，系统不仅需要根据成本进行工具化，还需要根据用户获得的价值进行工具化。

最初的投资讨论首先是关于假设，然后是如何证明它。当然，还有达到第一点目标的成本。通常，这只是总投资的一小部分，因为团队可以在商定的时间范围内（例如几周或几个月）看到有关 MVP 的反馈。最后，将讨论继续投资还是转向其他投资。

优点是，这种精益模式在很大程度上不受沉没成本的影响。在传统世界中，如果您已经进行了 500 万美元的投资，那么它必须得到回报。利益相关者不喜欢称之为浪费或实验。心理防御机制可能会生效，例如再批准 1000 万至 2000 万美元以保持念想，无论价值是否存在。

敏捷企业不会依赖传统项目资金模式。通过滚动式资金拨付、MVP、忽略沉没成本，并基于创新核算的客观度量进行决策—以每次验证一个假设的方式推进工作。

在敏捷开发中，无需为任何事项等待数年。对于重大项目，前 6 至 12 周即可获得验证依据。经过数个计划增量周期，客观证据将指明是否继续推进长期计划。

间接与直接指标均可衡量敏捷交付产品的价值。间接层面可度量速率或团队在单位时间内完成的故事数量及故事点数。无需依赖工作分解结构，即可评估历史相似工作对该产能的利用情况。

首先要看是否具有可预测性 - 您是否在规定时间内实现了承诺的价值？然后，您可以进行调整并开始讨论为什么这个目标比其他目标更重要。检查 NPS 分数之类的指标来评估与企业主的合作成果也很简单。您的信心程度如何？您会将接受评估的团队推荐给其他人吗？

从瀑布式到敏捷式的转变对传统的资本支出和运营支出处理提出了挑战。FASB 规定，在可行性得到证实、管理层签字同意的情况下，可以将劳动力资本化，并在项目的使用寿命内计提折旧，从而影响收入。

瀑布模型中，在需求和设计确定并获得批准后，就可以进行资本化。而在敏捷方法中，则没有这样的门槛。您可以逐一构建解决方案，但仍然可以资本化。

还有很多工作涉及创新、研究、基础设施以及与向系统添加功能没有直接关系的各种事情。这仍然没有资本化。但在敏捷中，您有实现新功能的“故事”。如果您有某个功能（例如新的单点登录机制）的故事，则可以资本化。您甚至可能不需要时间表来完成此操作。但资本化需要解释，必须进行对话。

今天，规模化敏捷正在影响负责治理和投资的利益相关者。由于 IT 部门通常仍然以有限的成本透明度运作，因此对 IT 财务管理的看法可能是：“这是我们的大型成本中心。这是一笔支出，随着时间的推移，我们会得到各种业务成果，是的，我们很难将这些成果与投资联系起来。我们将成本分摊出去。”

为了展示敏捷转型带来的价值，IT 领导者需要了解如何衡量持续开发的财务影响和价值，何时将劳动力资本化，以及如何提供对资助计划的可见性。您需要适当程度的透明度来确定您是否以正确的方式投资于 IT 领域的正确事物。这就是 IT 领导者利用科技业务管理 (TBM) 的地方。

技术业务管理 (TBM) 是一门通过为企业提供将技术投资转化为业务价值的标准化方法以提升业务成果的学科。TBM 定义了管理技术业务所需的工具、流程、数据与人员。它依托标准化 TBM 分类体系与框架支撑，结构化解决技术与业务领导者面临的难题—包括规模化敏捷资金配置。

TBM 具有标准化的分类和报告，无论瀑布模型还是敏捷模型。这些功能可帮助企业为基于敏捷的应用程序开发提供财务指标的可见性，并将资源和成果组织到价值流特定的活动中。结果是与业务成果保持一致，业务价值获得增长。

全球部分大型企业约拥有 1 万名 IT 员工，其中约 5000 至 6000 人从事应用程序开发，这是一笔巨大的开支。这属于成本中心还是投资中心？虽取决于视角判断，但若想明晰资金使用情况，必须掌握敏捷开发的追踪方法。该过程需要规划敏捷产品的启动、资金配置与成效评估方式。

要被视为谈判桌上的增值合作伙伴，您必须了解价值流以及数据和通信方面的支出。这些担忧很重要，但话题正更多地转向如何与新的解决方案竞争。

人们很自然地希望所有事情都具有预测性、符合计划、与未来预算相关，但再加上费用，它就会受到限制。

是的，您想提前知道什么是不可知的，并确保不可知的投资回报率，但这并不现实。当您能够在董事会中与高管级业务利益相关者站在一起，解释当前的投资和结果，而不是承诺多年计划时，您就可以参与竞争。

好消息是，敏捷用实时客观证据取代了所有这些投资回报率的猜测。你不再需要花两年的时间来研究需求，而只需要想出第一个方案并交付给客户。现在

敏捷的最大优势在于能将重大战略举措拆解为多个模块，近乎即时交付价值。这样做的好处是能更早验证方向正确性。

科技的快速发展意味着更多的公司必须采用敏捷方法论，例如 Scaled Agile Framework (SAFe)，以快速响应不断变化的商业模式、市场和科技。因此，他们必须管理不断增加的科技支出并提高 IT 成本的透明度。组织可以结合使用 TBM 和 SAFe 以提供更多价值和透明度，以实现更高的业务敏捷性和与企业更好的合作伙伴关系。