CIO的沟通以“冲刺”(sprint，敏捷开发中的迭代周期)为单位，CFO的沟通则以季度为单位，这种语言障碍是研发预算被削减的首要原因。
过去十年里，工程部门与财务部门的关系一直由一种暂时的休战状态所定义。只要利率接近零，且增长是首要任务，CFO就愿意将研发视为一个“黑匣子”，其任务很简单：聘请最优秀的工程师，采用最快的方法，并占领市场。在这种环境下，敏捷开发是完美的运营体系，它优先考虑速度、适应性和持续交付。
但经济形势已经改变，“不惜一切代价求增长”的时代已被“效率经济”所取代，休战状态也已结束。
在接连不断的董事会会议室里，我看到了一种新的摩擦正在出现。工程团队交付的代码比以往任何时候都多，他们庆祝着创纪录的开发速度，并成功完成了复杂的敏捷转型，然而，财务部门看到的却截然不同，他们看到运营成本上升，资本资产停滞不前，而云服务费用增长速度超过了营收增长。从CFO的角度来看，敏捷转型看起来不像是一个创新引擎，更像是一个黑洞：资本投入其中，但清晰度却大打折扣。
问题不在于敏捷开发本身出了问题，问题在于敏捷开发与财务部门使用的是两种截然不同的语言，而现在，缺乏“翻译”正让CIO失去信誉。
部落方言：故事点数与资产价值
这场冲突的核心在于这两个部门如何定义价值。
现代工程团队生活在“史诗(epics，敏捷开发中大型的用户故事)”“用户故事(stories)”和“速度点数(velocity points)”的世界里，成功通过燃尽图(burn-down chart)来衡量，该图表跟踪工作完成的速率，这是一个纯粹的运营指标，它告诉你开发速度有多快，但并未说明经济目标是什么。
产品债务审计
敏捷仪表盘追踪的是速度(活动)，而此仪表盘追踪的是资本化(价值)。在对一个“高绩效”团队的调查审计中发现，75%的产能被非增值性的维护工作所消耗。CFO认为这不是研发投资，而是折旧资产，ROI仅为25%。
财务部门生活在资本化、摊销和减值的领域。对CFO来说，软件开发不仅仅是工作，它是一项旨在创造长期资产的投资活动。当一家公司花费1000万美元用于支付工程师薪资时，CFO需要知道这笔支出中有多少用于构建可以资本化并随时间摊销的新资产，又有多少仅仅是必须立即计入费用的维护工作。
我回忆起与一家大型企业级SaaS公司CFO的一次关键会议，我正在介绍我们的路线图，其中充满了“重构”和“偿还技术债务”等内容，他打断我说：“Richard，我不关心你的代码质量，我关心的是每股收益(EPS)，如果你告诉我这是维护工作，我今天就必须将其计入费用，这会损害我们的收益，如果你告诉我这是在增强资产，我就可以将其在五年内摊销，帮我个忙，也帮帮你自己。”
那是一个顿悟的时刻，他并不是想扼杀创新，他是在努力管理公司的估值，我们没有使用同一种语言。
如果没有一个“翻译层”，敏捷开发的持续性在审计人员看来就像混乱。在现代环境中，一个团队可能在一个下午就完成错误修复、新功能开发和代码重构，财务信息就会淹没在噪音中。
资本化矩阵
为了解决这种“翻译”失败的问题，我不再试图向财务部门传授敏捷开发知识，而是开始向工程部门传授资本化知识，我与一组工程经理合作，创建了我们称之为“资本化矩阵”的工具。
这是一个简单的2×2网格，我们在每次冲刺计划会议上都会对其进行审查。纵轴是“功能”(新功能与现有功能)，横轴是“架构”(新架构与现有架构)。
如果一项任务涉及在新架构上开发新功能，那么它显然属于资本性支出(CapEx)，如果它是在现有架构上开发现有功能(如错误修复)，那么它显然属于运营性支出(OpEx)，摩擦总是出现在灰色地带：重构代码以支持未来的扩展。
工程师将重构视为一项关键投资，财务部门则将其视为维护工作。为了弥合这一差距，我们在Jira(一款项目管理工具)中引入了“叙述性标签”。如果工程师将一项重构任务标记为CapEx，他们必须写一句“资产辩护”，解释这项工作如何延长了软件的使用寿命或启用了特定的新营收能力。
这迫使工程师从经济角度思考问题，他们不能只是说“清理代码”，他们必须说“重构数据库以支持企业级版本的发布”。
影响是深远的，我们的资本化率稳定下来，CFO不再审计我们的冲刺，工程团队也感到更有权力，因为他们理解了技术决策如何影响公司的损益表(P&L)，我们将一项合规任务变成了一项战略对齐工具。
“相信我”经济的终结
多年来，技术领导者一直采用“相信我”模式运营，他们认为软件开发是一种艺术形式，本质上不可预测，且抗拒标准会计的严格约束。
如今，这种文化屏障已经消失，随着美国财务会计准则委员会(FASB)更新指导方针，明确承认迭代开发，“跟踪起来太复杂”已不再是一个可接受的借口。
我在指导委员会会议上经常看到这种情况，CIO展示了一份充满令人兴奋的技术倡议的路线图，CFO听着，点头，然后问一个问题：“这如何摊销?”
这听起来像是一个官僚问题，但实际上是一个战略问题。如果这项工作不能资本化，它将立即影响损益表，并降低每股收益，如果它可以资本化，它将把成本分摊到五年内，并保护盈利能力。
我建议的最成功的CIO已经停止与这种现实抗争，相反，他们向团队解释了原因，他们向工程经理解释，资本化不是一个会计把戏，它是公司能够聘请更多工程师的机制。通过保护损益表免受即时费用的影响，合理的资本化为人员增长创造了财政空间。
治理解决方案：定义资产
Gartner的研究强调，高绩效组织并不是通过强迫工程师成为会计来解决这个问题，而是在开发过程中建立明确的资本化触发点。
这始于我称之为技术重要性的概念，并非每一行代码都是资产，微小的增强、用户界面调整和常规依赖项更新都是业务成本，能够延长平台使用寿命或创造新营收潜力的实质性功能才是资产。
定义这些阈值可以保护团队，当工程领导者能够说明，由于他们正在偿还债务以加速第四季度的速度，因此本次冲刺低于资本化阈值时，他们就改变了对话，问题从“你为什么这么慢?”变成了“我们选择投资于稳定性”。
此外，指标必须超越速度，领先的组织现在追踪维护与创新的比率，当工程时间追踪显示，绝大多数努力都严重偏向于维持系统运行，那么组织实际上已经进入了技术破产状态，相反，如果一个团队声称他们将100%的时间用于创新，而维护时间为零，那么这立即就是审计风险的红色标志。
麦肯锡关于开发者速度的研究强调，顶级公司积极管理这种平衡，使用清晰的数据来确保创新能力不会因未计划的维护工作而逐渐削弱。
结论：CFO作为合作伙伴
这种“翻译”的目标不仅仅是合规，它是为了对齐，当CIO能够走进董事会会议室，用创造的资产和部署的资本来解释他们的路线图，而不是仅仅用交付的功能来解释时，动态就发生了变化。CFO不再讨厌敏捷转型，因为他们终于理解了它，他们可以看到冲刺中混乱、迭代的工作与资产负债表上清晰、长期的价值之间的直接联系。在效率经济中，财务流利度是技术领导力的终极软技能。
