DevOps 转型不仅仅是开发和运营团队的事情。 它也与组织的其他部分相关。 这些新的合作者可以为开发团队提供新的见解，以保持与客户需求的协调一致。
本文介绍了让您业务的其他部分参与 DevOps 的方法。
与营销和销售团队合作
产品和服务公司需要在 DevOps 转型中考虑其销售和营销团队。 DevOps 可以帮助打破销售、营销和开发之间的孤岛。
支持新产品发布的销售和营销团队需要持续了解开发项目的进度。 我还认为开发人员利益相关者应该了解营销活动。 在 DevOps 文化中，营销材料中出现技术不准确的意外情况不应再发生。 销售组织可以将客户反馈和需求传递到开发周期中，以便增量版本可以包含客户要求的功能。 您可以通过以下几种方式增加这种参与度：
- 如果您还没有使用，可以使用 开源群聊工具，例如 Mattermost 或 Rocket.chat 来设置上市 (GTM) 或产品发布渠道，以共享产品信息。
- 将销售和营销纳入构建发布周期，允许他们接收演示甚至使用测试版本。
- 在开发周期中，让您的销售和营销团队可以访问文档。
自动化是 DevOps 中的优先事项。 您有责任让您的营销团队了解自动化如何改变您的组织在内部和外部交付软件的方式，使其成为您公司故事的一部分。 我还建议研究如何从您的持续集成/持续开发 (CI/CD) 工具链中自动化数据报告，以使营销受益。
在用户故事开发、产品定义、用户文档和营销材料中与营销合作和共享角色，使用项目计划来支持这些活动，从而创造新的意义。
加速和自动化技术内容创建
技术作家和其他内容开发人员该坐在 DevOps 的桌子旁了。 这是我在之前的一篇 Opensource.com 文章中讨论的主题。
以下是一些让技术和营销内容创建者参与您的 DevOps 流程的方法：
- 打破您的技术作家和项目团队之间的任何文化或时间安排孤岛，让作家参与进来，首先将作家嵌入到团队中。
- 使用与管理持续交付类似的工具链或管道模型来管理任何与项目相关的内容，使用自动化文档工具，例如 docToolchain, Hugo, 或 Jekyll.
- 采取一种 渐进主义 而不是完美主义的方法来对待内容，以便内容开发与产品开发保持同步。
- 引入一种 持续文档模型 (或类似的方法) 以加速内容开发到 DevOps 速度。
[另请阅读： DevOps 文档指南]
向您的法律部门寻求许可指导
即使是您的法律和财务部门，在您的 DevOps 流程中也具有潜在作用。 虽然公司律师可能不会直接将时间花费在您的 DevOps 项目上，但他们的工作存在于您的开源和商业软件许可的某些方面。 以下是一些让您的法律部门参与 DevOps 的方法：
- 让您的公司律师之一负责开源软件许可，并鼓励法律部门和您精通开源的开发人员之间进行协作。
- 中型企业应将法律代表纳入任何开源卓越中心或其他专注于开源软件的跨职能团队。
- 大型企业应将法律代表纳入其 开源项目办公室。
与您的会计和财务部门一起监控成本
财务运营 (FinOps) 和云成本优化是当今数字化转型项目中不可或缺的要素。 成本 监控 和优化应成为任何 Kubernetes 部署的一部分。
除了选择使 Kubernetes 成本监控成为现实的工具之外，您还需要尽早与您的会计和财务部门合作。 工程师或解决方案架构师应与会计部门代表合作，将财务控制和监控纳入 DevOps 的规划阶段。
为您的管理人员实施自助服务报告
有时，您可能需要在您的 DevOps 流程中让您的执行团队参与进来。 不，您不希望他们与您的团队并肩工作。 相反，您希望通过明智和创新地使用分析和报告来利用您的后端数据。 一些例子包括：
- 应用程序变更时间，即代码提交和部署之间的时间。
- 问题量，捕获员工和客户在给定时期内报告的问题数量。
- 价值实现时间，是衡量从功能请求到业务价值实现之间所花费时间的业务指标。
当您为您的 DevOps 工作建立适当的报告和审计跟踪时，您还可以获得一个新的渠道来与利益相关者沟通项目成功和挑战。 更重要的是，您现在拥有可操作的数据来支持您报告的内容。
最后的想法
最终，DevOps 可以而且应该改变您的业务。 除非您的开发和运营团队开始与其他业务部门合作以实现公司范围内的 DevOps 目标，否则不会发生全面转型。 虽然许多组织都在谈论跨职能团队的力量，但让不懂代码的人参与到 DevOps 流程中最终是一种文化实践，因为它打破了组织中更多的孤岛。
3 条评论