如何确定DevOps变更的优先级？

任何IT项目都在努力获取正确数量的资源，并在正确的时间进行正确的工作。那么，您如何才能帮助和交流现在应该解决的最高优先级的问题呢？以下是一个简单的过程：

这通常是最容易的部分。它们在CI/CD管道中吗？它们在工具中吗？他们是流程吗？您是否经常错过项目截止日期？清楚地概述和定义您所看到的痛点。

通常，事情越痛苦，投入时间解决问题就越有价值。

让我们从行业术语定义开始：

需求分析是一个过程。虽然一个企业的生产量多少会取决于其生产能力，但是必须努力产生对其产品的潜在需求。

对于工程团队而言，这实际上意味着我们需要了解是否确实有解决这些痛点的需求，或者这仅仅是单一资源所苦苦挣扎的事情。这通常是工程师和管理人员不同意的地方。对于像我这样具有强大工程背景的人，这需要真正跨出您的舒适区域，并换上另一个镜头才能看到工作。

我很高兴与之合作的最伟大的商业领袖之一告诉我：“我们不能仅仅因为重视IT而从事IT工作，而是必须从事能够为企业带来价值的工作。”

因此，可以说今天在多个环境中的部署是手动完成的，这对于系统工程师来说是一个痛苦的时刻。他们希望使这项工作自动化，并且管理层正在推迟其优先级。为什么会这样呢？也许是因为我们每月仅发布一次新版本的软件？也许是因为我们只有4种环境可将代码推送到其中？也许是因为只有一个人需要这样做，并且从来没有遇到过完成工作后的问题？

尽管我无法描述所有可能的情况并给出示例，但我的最佳建议是从时间，人员和金钱方面考虑您的痛点。参与某事的人越多，花费的时间越多通常意味着更多的经济影响。经济影响越大，首先解决的问题就越痛苦且最可行。

解释这一点的最简单方法是将其称为概念的证明阶段。花时间创建和定义计划。事物的实际当前状态是什么？您想要达到的目标状态是什么？

不要尝试一次自动化整个过程或所有事情。就像敏捷原则一样，将其分解为一小部分变更，测试结果并分析数据。使用它可以为继续进行此工作的价值管理提供更多证据。

现在，您已经有了一个计划和一些数据，可以开始计算出所建议的工作领域的价值所在，分析起来应该很简单。这项改变将要实施多少麻烦？完全需要多长时间？值得投资吗？

这应该可以帮助您从自己的团队，管理层以及整个交付团队中获得支持！最终成功的变更意味着相关人员已经融入了新流程。

DevOps很难。该术语涵盖了SDLC的各个方面，并且在改进方面从未缺少任何想法。作为DevOps的工程师，我们需要帮助降低错误并找到真正的方向，从而为业务带来收益。只要您看到应该完成的工作项目，就可以按照此过程进行操作，您将迅速影响更高级别的项目任务。