如今,首席财务官、首席信息官和首席技术官正处于相互交织的十字路口。原因何在?软件开发成本上升、不断努力寻找价值创造的源泉以及推动业务敏捷性。软件开发成本占项目预算的 63%,因此,这种挣扎是显而易见的。
大多数工程领导者都面临着一个共同的两难选择--要么将预算提高到顶峰,要么以较低的成本牺牲质量。这种思路在过去曾有过一些轶事,即以优化软件成本的名义打击开发人员的创新能力。这种常见的误解导致许多人陷入财政拖累、产品失败和令人难忘的客户体验。
如今,所有垂直行业的高管都在疯狂地试图找到一个单一的真相来源,以了解和优化工程支出,同时促进财务问责。
这正是DevFinOps改变游戏规则的地方。
DevFinOps 集开发、运营和财务于一体,功能强大。
将 DevFinOps 称为工程领域的 "亨利-福特 "时刻并没有错。就像福特引入自动化来加速生产和降低成本一样,工程团队也必须管理工程成本。
这样做的目的是使开发工作与财务目标保持一致,从而使团队的每项工程投资都能创造最大价值,使软件开发的每一分钱都能产生更多的收益。
传统的软件开发遵循 "先构建,后成本 "的方法,在这种方法中,成本优化最初被放在了次要位置,后来又因盲目提供财务买断而受到 C 级管理人员的指责。
有了 DevFinOps 的帮助,工程团队现在可以在关注开发成本的同时构建产品。它还可以转化为战略资产,这些资产可以资本化,而不是费用化,从而减轻任何财务负担。
DevFinOps 是 FinOps 的自然演进,它将财务审慎扩展到云之外的所有工程垂直领域--云、问题跟踪器、维护成本、软件许可证、培训和开发、原型设计和 VCS。基本上,这就是开发的核心。
造成这种文化转变的第一大原因是 IT 支出激增。仅在 2022 年,企业的 IT 支出就高达 7830 亿美元,并将以 10% 的年均复合增长率很快达到 1 万亿美元,而这仅仅是 IT 方面的支出。
在经济不确定的情况下,高收费、高加价和 IT 价格可能会让人沮丧,甚至会给本已劳累不堪、工程需求不均衡的工程团队带来更大的压力。
工程团队转向 DevFinOps 的其他原因:
如今,DevFinOps 原则已成为白热化趋势,甚至被一些全球领先企业所采用。Shopify 在采用 DevFinOps 方面的传统对许多人来说都是一种激励。这家电子商务巨头通过云迁移、采用Kubernetes 和绘制每一元钱的工程图(得益于 Shopify 以数据为导向的文化),降低了10% 的基础设施成本。
尽管 DevFinOps 有这么多好处,但其实施仍然很少,而且进展缓慢。原因何在?
Gartner最近就开发周期采用新方法的问题对全球 C-suite 高管进行了调查。结果令人吃惊。尽管 52% 的首席执行官以优化成本增长比为目标,但他们很难充分利用已实施的战略。另外 59% 的首席执行官感到沮丧,因为这些文化转变需要很长时间才能产生效益。DevFinOps 的采用也有类似的情况。
在工程组织中,DevFinOps 无法在 excel 表文化主导的人工环境中扩展。不断要求了解当前工程工作的可视性可能会导致反弹,对组织造成损害,而不是带来任何好处。缺乏以数据为导向的文化也会导致团队摩擦、员工沮丧,继而导致工程或财务双方辞职。这些问题的根源在于无法获取历史数据,而这些数据本可以帮助团队事先预测成本动态。
另一个问题是复杂的 工程工作流程。在开发、测试和部署之间不断切换会带来一系列财务问题。要确定每项行动的成本影响,就像要解开一张复杂的网。
此外,引入 DevFinops 还意味着要调整报告和项目管理操作,以纳入新的实践。任何改变,尤其是已经不堪重负的工程团队,都需要付出代价。这种变革往往会遇到阻力。要获得团队中几乎每个人的支持,是一件很难的事情。
说服团队采用新的 DevFinOps 方法可能就像赶猫一样。开发人员和管理人员对熟悉的日常工作习以为常,而改变这些日常工作会带来新的学习曲线,需要时间(这是工程团队所不具备的)、分散开发人员的注意力,甚至会影响质量。
这种阻力往往源于知识鸿沟、对工程活动的近视,以及缺乏各级团队的参与。开发团队可能擅长编写代码,但当涉及到理解财务术语时,他们就会陷入迷茫。弥合技术才华与财务智慧之间的鸿沟,说起来容易做起来难!
所有这些都会导致开发团队的工作作风下降,影响开发人员的工作效率。Cloudzero最近的一项调查揭示了烧钱的软件成本对工程生产力的影响--41% 的开发人员面临更高的中断率,甚至持续到下一个冲刺阶段,而这一切都是因为内部成本问题。
要克服这些挑战,就必须转变观念,不断学习,并大力开展合作。
工程界有句老话--在改进之前,你需要先衡量它。在企业中采用 DevFinOps 也是如此。DevFinOps 有限成功背后的一个核心原因是可见性有限。这就像基本数学一样简单--团队对其工作流程的可视性越高,协作就越多,工程流程的脉搏就越清晰。
工程分析通过提供端到端的可视性、实时可行的洞察力和团队更新来实现这一点--所有这些都集中在一个面板上。以工程支出的上下文数据为支撑的可视性消除了工程团队和财务团队之间的盲点,帮助团队实现共同目标,同时回答以下棘手问题:
有了关于开发进度和成本的实时数据,两个团队就能共同决定所有热点问题--未充分利用的资源,或是否加快时间进度或分配额外资源。
DevFinOps 中工程分析的另一个用例是找到 OpEx 和 CapEx 成本之间的平衡点。在可操作数据的帮助下,团队可以自动进行成本资本化,而无需过多的人工干预,甚至可以在每次运营开支超过团队阈值时对其进行控制。
一言以蔽之,数据不仅是新的石油,也是开启企业 DevFinOps 的钥匙!
在制定 DevFinOps 战略的过程中,我们会遇到许多令人惊喜的时刻--仅仅了解工程工作流程是不够的。这是一项持续的工作,需要财务和工程团队两方面的定期支持。
限制软件预算以优化成本是一种狭隘的方法。而 DevFinOps 带来的是一种新的视角,让非技术业务团队了解工程团队的工作,甚至为工程团队的运营和支出提供了新的行为准则。
如今,DevFinOps 处于卓越成本和成功工程的交汇点。持续改进的精神在数据驱动的团队中茁壮成长。DevFinOps 是一条值得走的道路--一条将开发、财务和运营结合在一起的道路,以创建一个无缝、具有成本效益和价值驱动的流程。