devops 业务模型

几年前，当我的公司首席执行官告诉我，我需要专注于业务的收益而非技术时，我正在为DevOps转型开发业务案例。 多年来，这一直困扰着我，随着DevOps将其重点转向文化而非技术，他的建议被证明是正确的。 技术实际上是转换的简单部分。

发现业务需求

转型真的很难。 因此，您必须以清晰而令人满意的方式回答以下问题：为什么您的企业需要DevOps？ 如果仅仅是因为您想要特定的工具或者您更喜欢DevOps文化，那么您将需要更多的理由说服决策者（当然，除非您是CEO和/或董事会主席）。 您需要找到并说明DevOps可以解决的当今公司中缺少或缺少的内容。

以下是您的公司应考虑过渡到DevOps的一些迹象：

• 交付功能是否需要很长时间？
• 功能使用不足吗？
• 您不知道功能的利用吗？
• 在维护或部署窗口期间，您是否有停机时间？
• 您的客户是否知道您的网站已关闭？
• 是否出于相同的原因反复发生中断？
• 客户功能请求的实施方式实际上无法满足客户的需求吗？

请注意，这些问题都没有询问变更管理负担或运营效率低下。 您可能每天都会看到这些，但这并不是企业所看到的问题。 他们看到了客户损失，机会成本和战略影响。 为了解决此问题，您还需要了解您公司的策略。

您的公司策略可能会在首席执行官或董事会的文件中清楚列出。 这是一个不错的起点，但可能无法说明全部内容。 您需要与不同的业务负责人联系，并学习他们的策略。 我是一个极端内向的人，所以如果我能做到，你也可以。 人们喜欢谈论自己和他们的想法，因此您甚至不需要进行很多交谈。 邀请他们共进午餐，并向他们询问有关他们的策略的问题，以便您可以更好地了解他们的方向和他们今天遇到的痛点。 您将把这些添加到业务案例的收益部分。

一旦您对公司的整体战略有了更好的了解，您可能还已经弄清楚了谁真正在做决策或谁在影响决策者。 这是您可能没有想到的决策者或影响者的好清单 。 在编制业务案例时，您需要强调解决或缓解的问题。 假设午餐进行得很顺利，您还将希望建立这种关系和信任。 不要轻率地这样做，否则可能适得其反。

使DevOps研究工作

现在我们已经获得了更多的背景信息并更好地理解了业务问题，我们可以开始收集与DevOps如何解决它们有关的内容。 有一些非常好的数据资源可以帮助销售这种类型的转换。 最好的收集来自DevOps研究与评估 （DORA）团队。 自2014年以来，妮可·福斯格伦（Nicole Forsgren）与人偶实验室（Puppet Labs）共同领导了DORA的《 DevOps状态报告》。DORA的研究是开放的，并已为所有人造福。

2017年《 DevOps状态报告》包含许多有价值的信息，这些信息可能会吸引高管。 例如，高绩效团队实现利润，市场份额和生产率目标的可能性是其两倍以上。 他们的部署频率提高了46倍。 他们的变更准备时间比绩效低下的团队快440倍。 他们的平均恢复时间快了96倍。 他们发生变更失败的可能性只有五分之一。 当我们将这些映射回业务需求时，我们可以开始支持为什么DevOps可以帮助解决这些业务需求的论点。

如果您还可以给公司更多的员工时间，该怎么办？ 研究表明，高绩效团队在返工和计划外工作上的时间减少了21％，在新工作上的时间减少了44％。 这就像免费将您的员工增加近一半一样！

DORA的另一篇研究论文《 DevOps ROI白皮书》 ，包含了更多有关您可能希望包含在业务案例中的信息。 它谈论的不是仅关注转换的成本节省方面。 我完全同意这一点，我的前任首席执行官也同意。 您需要将业务案例集中在价值驱动的类别上。 本文提供了一个很好的计算方法，可以确定仅通过节省返工时间即可创造的价值：

（技术人员人数）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 $ 100M（产品业务）= $ 140K回报

该文档将进行一些其他计算，以确定将有助于您将其纳入业务案例的预期ROI和预期投资回收期。

另一个很棒的资源是卡内基·梅隆（Carnegie Mellon）的SEI Insights博客。 它有很多关于DevOps的文章，并且在高管中是众所周知的。 一篇文章讨论了DevOps如何降低部署风险 ，从而提高敏捷性。 它还讨论了合规性问题，这对于在受监管实体内进行转型时理解至关重要。 SEI Insights的另一篇文章指出， 安全已成为企业的头等大事 ，代表着真正的商业价值。 这对于记录文档非常重要-在当今的环境中，这可能就是您需要接受的全部条件。 不过，您会希望首席安全执行官先站在您这边。

既然您拥有强大的业务案例，则可以通过调查同事来对其进行修改。 先前的计算取决于您已经准确评估了公司的当前状态。 最好预先投资一点钱进行调查，以便您的数字更加准确。 您还可以通过自己进行非正式的调查来节省一些钱。 目标是确定公司当前的绩效水平。

寻找合作伙伴证明成功

现在，您已经开发了一个令人印象深刻的业务案例，其中包含大量数字，描述了如何为公司节省大量资金并为创新提供更多时间，您需要证明这一点。 您的公司可能会遵循特定的方法，并且不可能在一篇文章中涵盖所有这些差异。 无论您的公司采用何种流程，您都需要先证明其成功， 然后公司才能确定这是错误的投资。 以我的经验，这是三到六个月。

为此，您将需要找到一个准备好进行变更的团队。 还记得你吃过的那些午餐吗？ 这个人最让谁兴奋？ 谁与您保持联系？ 那可能是一个很好的候选人。 您需要与他们合作，以确保您有时间按时间表进行。 这也是使用免费和开放源代码软件（FOSS）和云环境的绝佳时机，因为您希望保持低成本和高敏捷性。

实施小的更改，并衡量它们对团队和产品的影响。 随着团队的发展，您应该能够看到业务案例中描述的好处。 最好在业务案例中证明尽可能多的指标。 然后，您将要呈现此数据。

您应该定期与批准该业务案例的执行发起人进行跟进。 这些可以是非正式会议，但它们需要传达胜利并保持赞助商的积极性。 与赞助商的上级会面也是您和您的赞助商促进所做的良好工作的好方法。

当然，这不只是更换一个团队。 您还需要安排与公司中其他人的定期会议。 我经常将这些会议保留为公开邀请会议，欢迎大家参加，我们会记录下来以便以后共享。 使用尽可能多的途径来传播这个词。 您不能过度传达成功。

既然您已经有一个团队来证明您的业务案例，那么您就可以很好地执行整个公司的业务案例。 您将要重复这些步骤，并逐步进行转型，将其转移到公司的每个部门。

翻译自: https://opensource.com/article/18/2/how-build-business-case-devops-transformation

devops 业务模型