几年前，当我为一个 DevOps 转型制定商业案例时，我公司的 CEO 告诉我，我需要关注业务的收益，而不是技术。多年来，这句话一直萦绕在我耳边，随着 DevOps 将重点转向文化而非技术，他的建议被证明是正确的。实际上，技术是转型过程中容易的部分。
让我们卷起袖子，构建您启动 DevOps 转型所需的商业案例。
发现业务需求
转型真的很难。这使得您必须以清晰且令人满意的方式回答以下问题：为什么您的企业需要 DevOps？如果仅仅是因为您想要某个特定的工具或者您更喜欢 DevOps 文化，那么您需要更多的理由来说服决策者（除非您是 CEO 和/或董事会主席，当然）。您需要找出并解释当今公司中缺少或不足之处，而 DevOps 可以解决这些问题。
以下是一些表明您的公司应考虑转型到 DevOps 的迹象
- 交付功能是否需要很长时间？
- 功能是否未被充分利用？
- 您是否不知道功能的利用率？
- 在维护或部署窗口期间，您是否遇到停机？
- 在您知道之前，您的客户是否告诉您您的网站已关闭？
- 是否由于相同原因反复发生中断？
- 客户的功能请求的实现方式是否实际上并未满足客户的需求？
请注意，这些问题均未询问变更管理负担或运营效率低下。您可能每天都看到这些问题，但这并不是企业看到的问题。他们看到的是客户损失、机会成本和战略影响。为了解决这个问题，您还需要了解公司的战略。
您的公司战略可能会在 CEO 或董事会的文件中清楚地列出。这是一个很好的起点，但这可能并没有讲述完整的故事。您需要与不同的业务领导者联系，并了解他们的战略。我是一个极度内向的人，所以如果我能做到，您也可以。人们喜欢谈论自己和自己的想法，因此您甚至不需要说太多话。邀请他们共进午餐，并询问他们有关其战略的问题，以便您可以更好地了解他们的方向以及他们今天遇到的痛点。您将把这些添加到您的商业案例的收益部分。
一旦您更好地了解了公司的总体战略，您可能也弄清楚了谁是真正的决策者或谁在影响决策者。这是一个您可能没有想到的作为决策者或影响者的领域的好清单。在制定您的商业案例时，您将希望突出显示他们的问题已得到解决或缓解。假设午餐进行得很顺利，您还需要建立这种关系和信任。不要虚情假意地这样做，否则很可能会适得其反。
将 DevOps 研究付诸实践
现在我们已经获得了更多背景信息，并且更好地了解了业务问题，我们可以开始收集与 DevOps 如何解决这些问题相关的内容。有几个非常好的资源，其中包含可以帮助推销这种转型的数据。最好的集合来自 DevOps 研究与评估 (DORA) 团队。自 2014 年以来，Nicole Forsgren 一直与 Puppet Labs 合作领导 DORA 的 DevOps 现状报告。DORA 的研究是公开和发布的，供任何人受益。
2017 年 DevOps 现状报告包含许多有价值的信息，这些信息可能会引起高管的兴趣。例如，绩效卓越的团队超额完成其盈利能力、市场份额和生产力目标的可能性是其他团队的两倍以上。他们的部署频率高出 46 倍。他们的变更交付前置时间比绩效较差的团队快 440 倍。他们的平均恢复时间快 96 倍。并且他们发生变更失败的可能性降低五分之一。当我们将这些映射回业务需求时，我们可以开始加强我们的论点，说明 DevOps 如何帮助解决这些业务需求。
如果您还可以为您的公司节省更多员工时间呢？研究表明，绩效卓越的团队在返工和计划外工作上花费的时间减少 21%，而在新工作上花费的时间增加 44%。这就像免费增加近一半的员工！
另一份 DORA 研究论文 DevOps ROI 白皮书 包含更多关于您可能想要包含在商业案例中的具体信息。它讨论了不要仅仅关注转型的成本节约方面。我完全同意这一点，我的前任 CEO 也同意。您需要将您的商业案例重点放在价值驱动的类别上。本文提供了一个很好的计算方法，可以确定仅通过节省返工时间创造的价值
(技术人员规模) x (平均工资) x (福利乘数) x (不必要的返工时间百分比) = 每年避免不必要的返工成本
一个小公司的例子可能是
150（技术人员）x 105,000 美元（平均工资）x 1.5（福利乘数）x 7%（低绩效者的返工）= 每年节省 170 万美元
仅在时间上就节省了大量资金。但是，这些节省下来的时间可以用来做什么呢？新工作！我们现在可以计算出为企业增加的价值。
(回收并再投资于新功能的时间) x (创收功能) = 来自再投资的潜在收入
首先，我们需要了解如何计算创收功能
(每个业务线的实验频率) x (组织中的业务线) x (创意成功率) x (创意影响) x (产品业务规模) = 创收功能
以下是使用与之前相同的小公司的示例
7%（回收时间）x 2（实验/年）x 3（业务线）x ⅓（成功率）x 1%（影响）x 1 亿美元（产品业务）= 14 万美元的回报
该文档逐步介绍了其他一些计算方法，以确定预期的 ROI 和预期的投资回收期，这将有助于包含在您的商业案例中。
另一个很棒的资源是卡内基梅隆大学的 SEI Insights 博客。它有很多关于 DevOps 的文章，并且在管理人员中广为人知。其中一篇文章讨论了 DevOps 如何降低部署风险，从而提高敏捷性。它还讨论了合规性问题，这对于在受监管实体内进行转型时至关重要。另一篇 SEI Insights 文章指出，安全性已成为首要业务重点，并代表着真正的商业价值。这将是需要记录的重要内容——并且在今天的环境中，这可能就是您获得支持所需要的一切。不过，您首先需要首席安全主管站在您这边。
现在您有了一个强有力的商业案例，您可以通过调查您的同事来对其进行修订。之前的计算依赖于您已经准确评估了公司当前的状态。最好预先投入少量资金进行调查，以便您的数字更准确。您也可以通过自行进行更非正式的调查来节省一些资金。目标是确定公司当前的绩效水平。
寻找合作伙伴来证明成功
现在您已经制定了一个令人印象深刻的商业案例，其中包含大量数字，描述了您将如何为公司节省大量资金并为创新提供更多时间，您需要证明这一点。您的公司可能会遵循特定的方法，并且不可能在一篇文章中涵盖所有这些差异。无论您公司的流程如何，您都需要在公司认为这是一项错误的投资之前证明成功。根据我的经验，这在三到六个月之间。
为此，您需要找到一个准备好接受变革的团队。还记得您吃过的所有午餐吗？谁是最兴奋的人？谁与您保持联系？那可能是一个不错的候选人。您需要与他们合作，以确保您在他们的日程安排中有时间。这也是使用免费和开源软件 (FOSS) 和云环境的好时机，因为您希望保持低成本和高敏捷性。
实施小的更改并衡量它们对团队和产品的影响。随着团队的发展，您应该能够看到您的商业案例中描述的收益。最好尽可能多地证明您的商业案例中的指标。然后，您需要展示这些数据。
您应该定期与批准商业案例的执行赞助商进行后续跟进。这些可以是非正式会议，但它们需要传达胜利并保持赞助商的积极性。与赞助商的上级会面也是您和您的赞助商宣传正在完成的良好工作的好方法。
当然，这不仅仅是改变一个团队。您还需要安排与公司其他人员的定期会议。我经常将这些会议作为公开邀请会议，欢迎所有人参加，并且我们记录这些会议以供以后分享。尽可能多地利用各种渠道来传播信息。您不可能过度宣传成功。
现在您已经有一个团队证明了您的商业案例，您已经很好地走上了为整个公司执行商业案例的道路。您需要重复这些步骤并逐步推进，将您的转型推广到公司的每个部门。
评论已关闭。