持续部署如何影响整个组织

在持续部署 (CD) 软件发布策略中，任何通过自动化测试阶段的代码提交都会自动发布到生产环境。自动化取代了许多手动步骤，并促使软件交付和运营发生巨大变化。

虽然在谈论 CD 的影响时，开发和运维部门最受关注，但它的影响以各种方式扩展到您的 IT 组织之外。

CD 和组织绩效

缩短上市时间是公司甚至联邦机构（通过政府授权，例如 Cloud Smart 战略）的重要目标，旨在改善员工、客户和选民的体验。

关于 CD 对组织的影响，已经有一些值得注意的分析和评论。其中最著名的是 Nicole Forsgren 和 Jez Humble 的文章“持续交付在 IT 和组织绩效中的作用”。Forrester 等分析公司、云服务提供商 (CSP) 和 DevOps 工具供应商也是研究和分析 CD 如何影响组织的其他来源。当您阅读这些报告（质量可能参差不齐）时，请注意 CD 如何影响您的组织，以及如何开辟新的沟通渠道，以减轻 CD 对您业务部门的影响。

为了让您的组织适应 CD，您需要创建一种文化，让每个人——而不仅仅是您的 IT 部门——都欢迎新想法。您必须培训您的员工向他们的经理汇报坏消息，并主动解决 CD 给交付周期带来的问题。您组织的所有级别都必须学会将失败视为学习机会，而不是通往人力资源部的单程票。

除非您在实施 CD 前后衡量绩效，否则您无法了解 CD 对您组织的影响。

实施 CD 之前

• 收集状态报告，记录您在应用程序和服务交付方面的成功和失败
• 记录应用程序和服务交付方面已知的挑战，例如已知的解决方法或使开发和运营复杂化的不成熟流程
• 从您的开发和运营团队收集关于前 CD 时代哪些方面有效和哪些方面无效的见解
• 收集关于您的开发人员、IT 运营部门和其他部门之间业务协作的见解
• 查看客户和销售反馈，了解您的产品和服务交付效率
• 采访您的销售和客户成功团队，了解交付挑战

实施 CD 之后

• 为您的 CD 管道配备有意义的分析和报告，供业务和技术利益相关者使用
• 培训您的开发人员、IT 运营人员和利益相关者使用您 CD 管道中的分析和报告工具
• 与管理层和首席开发人员定期举行审查会议，讨论从报告和反馈中收集到的 CD 的影响
• 监控您的传统客户反馈渠道，并增加您的销售反馈渠道

有很多种方法可以将这些数据传达给您的利益相关者。无论您选择哪种特定技术、演示文稿还是其他方式来传递内容，都不要忘记人际联系。亲自传递衡量结果。进行对话。准备好获得反馈并回答问题。认真倾听。主动采取任何后续行动。

CD 和文化变革

持续部署为组织带来了必要的文化变革。一些员工会欣然接受它。另一些人可能会认为这是他们工作职责的巨大转变。一些学派认为它会带来一个 情绪周期，包括恐惧和暴怒，这取决于您的企业文化。

文化挑战出现在 CD 如何改变人们的工作方面——不仅仅是开发人员和运营人员。由于 CD 的加速发布周期，培训师可能必须更快地学习新功能，或者销售经理可能在为团队设定成功目标方面面临挑战。或者，高管可能会更强烈地要求不属于新发布周期的一次性更改。

各部门的直线经理和高级团队成员需要承认这些反应。行业内有很多关于变革管理的信息。我总是相信一线员工能够最好地管理员工对变革的反应。设置渠道、工具和框架，让这一切发生，而无需过度设计。

推广 CD 为您的组织带来的文化变革非常重要。这不仅仅是拥有一支变革管理团队。这意味着采取以人为本的方法来宣传 CD，包括

• 通过向受人尊敬的中层经理和高级职员展示 CD 如何帮助解决他们的一些痛点，来赢得他们的支持。
• 在所有将受到转向 CD 影响的部门之间创建开放的沟通渠道
• 沟通客户和项目方面的成功案例，其中 CD 是决定性因素（例如，由于 CD 帮助更频繁地交付功能，因此一位新客户加入）。

CD 跨部门

有很多关于 CD 如何影响开发和运营团队的文章和书籍。在匆忙进行变革的过程中，往往会忘记对其他部门的影响。组织必须建立支持框架，以帮助其他部门接受 CD 为企业带来的好处。

以下是 CD 如何影响 IT 部门以外部门的一些方式。

高管层

CD 的影响甚至可以波及到高管层。开发经理、产品经理和产品负责人有责任在与高管团队沟通的同时，更多地管理他们的发布周期。您最不希望看到的是高管劫持您新的 CD 周期，用于与您的产品路线图背道而驰的一次性功能和个人项目。

与您的 C-suite 建立关系，并与您的执行利益相关者就您的产品路线图进行早期和频繁的沟通。您还需要通过报告和收集他们的意见来管理他们对您新 CD 周期的期望。

产品路线图是帮助高管适应 CD 新世界的最佳方式。与他们合作，以避免任何功能蔓延的念头，并坚持业务重点。

项目和项目管理

引入 CD 意味着可能是时候拆除您老旧的项目管理办公室 (PMO) 战情室了，那里所有的墙上都贴满了甘特图。CD 需要不同类型的项目和项目管理。当您转向 CD 时，您大规模“计划和执行”交付和管理模型的日子已经结束。

您的 PMO 可能需要帮助学习新的敏捷项目管理技术，例如最小可行性证明点，以及如何与内部或客户团队验证它们。这通常意味着

• 派遣关键项目经理参加敏捷或 DevOps 培训
• 打破您的 PMO、开发和运营组织之间的任何隔阂，直至解散您的集中式 PMO 并将项目经理嵌入团队中
• 将项目管理数据迁移到 SaaS 应用程序，以便项目中的每个人都可以查看项目数据和进度。

市场营销和销售

持续部署甚至会影响市场营销和销售的工作。无论您的市场如何，您都希望他们渴望为您的客户服务。帮助他们的一种方法是给他们更多可销售的东西，而持续部署可以为您的销售团队实现这一点。

转向 CD 的一部分是为您的市场营销和销售人员配备信息。例如，您可以

• 邀请市场营销人员在发布前测试新功能和版本
• 争取营销传播部门在持续交付的基础上提供支持，以沟通新功能和版本
• 让合适的技术人员作为主题 matter 专家 (SME) 来创建营销材料

如果您能够帮助营销部门向您的员工和客户讲述您的 CD 故事，营销部门可以成为您转向 CD 的新盟友。

技术写作

技术作者经常被排除在企业 DevOps 讨论之外。作为一名技术作者，我承认这部分是我们的错，但很大程度上是组织造成的。

持续交付对您的技术作者意味着某些事情。首先，他们必须部署工具和策略，以便在 CD 模型中交付文档。帮助他们的一些方法包括

• 解散您的集中式文档团队，并将技术作者嵌入到您的开发和运营团队中
• 将文档开发作为您整体交付周期的一部分进行管理——包括依赖项——而不是作为事后考虑单独安排
• 通过更早地让作者参与发布周期，培养您的作者更注重功能

最终想法

CD 为组织带来了根本性的变化，因为旧的调度和开发周期消失了。当您转向 CD 时，您需要让您的整个组织——而不仅仅是您的开发和运营团队——都参与进来，以便充分利用每一项优势。