我领导公司的产品团队，并且在我职业生涯的大部分时间里一直担任与产品相关的角色。我也认为自己很幸运，过去的一些角色涉及与开发人员合作并向其销售产品。这有很多原因，但主要的原因之一是它让我在 DevOps 原则和实践方面获得了丰富的经验。现在，作为产品负责人，我开始相信愿意从 DevOps 中借鉴许多想法并将其应用于整个组织的团队会带来巨大的好处。

对于不熟悉的人来说，DevOps 是敏捷方法的延续。敏捷打破了产品和工程之间的壁垒，将软件开发转变为迭代过程，并使跨职能产品开发团队能够快速适应不断变化的市场和客户需求。 DevOps 通过将软件的开发和运营责任分配给相同的团队来扩展此模型。理论是，如果开发人员负责构建和操作软件（而不是将这些职责分配给单独的团队），他们将在功能（构建新功能）和可操作性（稳定性和性能）之间做出正确的权衡。结果是更好的产品质量、更高的速度和更快乐的客户。

虽然并非每个 DevOps 实践都适用于每个功能，但我确定了三个我认为值得更广泛采用的实践，尤其是在产品团队中。这三个 DevOps 原则体现了无可指责的文化、对衡量的坚定信念和主人翁精神。

无罪文化

无可指责的文化不应被误认为是一种随意的、“随遇而安”的精神。相反，在 DevOps 的背景下，它承认操作软件是复杂的，尤其是在快速增长的企业中，您正在突破规模和速度的界限。在这种环境下，错误（事件）就会发生。但是，当他们这样做时，重要的是不要将它们视为失败，而是将其视为学习和改进的机会。只有当相关人员知道他们不会因犯错而受到惩罚时，这种改进才会发生，因此才会对发生的事情持开放态度。于是就有了“无罪”的原则。

这如何应用于产品管理？嗯，大多数数字产品所有者都致力于建立新的用户体验。无论您是在优步并彻底改变当地旅行，还是您是一家通过建立在线订购平台来应对大流行的餐厅，您都不太可能从第一天起就建立完美的体验。使您的体验更好的唯一方法是尝试和学习。它是快速制定假设、测试它们、测量和重复。这一切的关键是创造一种庆祝实验的文化，无论结果是成功还是失败。

为什么庆祝失败的实验很重要？嗯，正如任何参与过实验工作文化的人都知道的那样，失败的实验通常比成功的实验提供更多（或更多）的价值。我仍然对某些结果的反直觉感到震惊。例如，当多个客户经常在他们通过网站“旅程”的某个时间点停滞不前时，以当时出现的链接或弹出框的形式显示有用的信息似乎是合乎逻辑的。事实上，情况往往并非如此。事实证明，工作流程中的（任何类型的）干扰通常会降低转化率。发现这一点——在关键点显示有用的信息可以降低转化率——是实验和数据收集过程的成功。事实上，在无可指责的文化中，每个人都明白成功是因为过去的失败，而不是尽管过去的失败。

那么，实验反模式，即指责文化，是什么样的？在这种情况下，人们不会冒险，因为他们担心负面后果。任由责备文化生根发芽是扼杀创新的最简单方法之一。

指标和测量

成功的 DevOps 流程需要对团队正在运行的系统立即提供反馈。这意味着有关服务正常运行时间、应用程序响应时间、操作负载等的指标。为确保客户获得良好体验，需要测量每次用户交互并立即报告异常情况。

这种对测量的关注对于数字产品所有者来说同样重要。每个新功能或 UI 调整都应该从我们期望它移动的指标的假设开始。数据应该推动我们的路线图决策。并且每次更改都需要具备追踪其影响的能力。在对上述实验的讨论之后，人们可能会说，实验中的一个真正错误是无法衡量实验所产生的影响。如果同时运行多个实验，则团队必须能够区分每个更改的影响。

您在非数据驱动的组织中看到的一种常见反模式是，路线图决策或实验想法主要由 HiPPO（最高薪酬人员意见）决定。此外，在非数据驱动的组织中，开发工作的成功通常是通过在时间轴上启动多少来衡量的，而不是新功能所带来的实际影响。

你建造它，你拥有它

另一个重要的 DevOps 原则是强烈的所有权文化。简单地说，构建功能或服务的团队就是操作代码的团队。如果生产中出现问题，他们会收到通知，并且会修复它。

同样的原则也适用于数字产品所有权。伟大的数字产品所有者将他们的产品或所有权领域视为一项业务——他们负责移动 KPI。他们和他们的扩展团队有权确定路线图的优先级，以产生企业正在寻找的结果。

在数字产品所有者的世界中，“你构建它，你拥有它”的反模式过分强调了新事物。这在绝大多数投资用于新功能（下一个新的闪亮对象）的团队中很明显，并且团队没有时间迭代和改进现有功能。从长远来看，这是一种失败的商业策略。首先，它常常导致产品变得过于复杂。其次，这意味着团队没有从他们发布的功能中获得全部价值，因为他们没有在发布后优化这些功能。这是非常短视的，因为可以通过对现有功能进行小规模迭代来实现最大的影响——例如，即使稍微提高可发现性也可以显着提高采用率。

结论

DevOps 策略的出现是为了优化现代软件的交付和优化，但它们的经验教训是广泛适用的，即使对于可能永远不会编写一行代码的团队也是如此。这些原则通常看起来有悖常理，但庆祝失败的实验、使用数据而不是直觉并投资优化现有产品将确保您为客户提供最佳体验并为您的业务提供最佳结果。

原文：https://www.informationweek.com/devops/what-product-teams-can-learn-fro…

本文：