在 DevOps 引入产品思维：将想法转化为优质产品的手段

想要成功，组织需要有两样东西：客户认为有价值的产品和服务，以及提供这些产品和服务的能力……

在这篇文章中，我将展示为什么必须像对待产品或服务一样设计、实现和操作我们的交付管道（将想法转化为用户手中的产品的手段）：通过引入“产品思维”。

我将分三部分来阐述这个问题：一、“管道”（和 DevOps）是指什么；二、为什么应该将管道视为一种产品；三、什么是产品思维，以及在实践中，产品管理可以提供怎样的帮助以及如何将其引入到 DevOps 中。

什么是（交付）“管道”？

交付管道是一种工具、技术和实践，通过它，我们可以将想法转化为产品和服务，然后用户可以使用它，组织可以运营、支持和演进它。（就本文而言，DevOps 是设计、构建和操作管道的准则）。

我想从更广阔的视角来看待这个管道的端到端流程：从识别问题和机会、制定战略目标、定义流程，到解决方案设计、分析、实施和质量保证，再到合规、运营和客户支持，当然，还有产品使用，整个价值链。

管道传统的“内”循环和覆盖整个价值链的更为全面的“外”循环。（图片来自Flaticon: Elias Bikbulatov）

为什么管道很重要？

我共事过的许多组织都认为，管道是“技术性的东西”，是那些汗流浃背的工程师在地下室的某个地方照管的东西，但非技术人员（当然不是管理人员）不用操心……

事实远非如此，因为管道对于业务而言很重要，原因有三。

管道是驱动力

最基本的，管道是将想法转化为用户手中的产品（并随后进行操作和管理）的驱动力。

遗憾的是，许多组织的管道支离破碎（流程有断点，如阶段门或手动移交)、低效（手动测试、手动提供资源、有限的自助配置），或者满足了错误的要求（有些地方过度设计，有些不足却导致了其他方面的瓶颈，例如，认为难以配置的 GUI 工具比命令行更好用）。

令人惊讶的是，人们经常认为“事情就是这样”，组织和团队基本上都接受了由此所导致的冗长而笨拙的流程，其结果就是：

• 用户可用的功能比较少

• 质量比较低

• 组织的学习速度比较慢

• 并且总体上增加了交付和操作之苦（进而降低了团队的积极性）

所以，如果仅仅是为了获得良好的流程、效率和效果，而不考虑其他方面的因素，那么你无疑需要一个灵活而流畅的管道。

没有什么方法适用于所有情况

我曾与早期初创公司合作，主要目标是快速进入市场，吸引用户并积累经验，使用 Vercel 或 Heroku 等轻量级工具将 DevOps 的成本和工作量降至最低，并能够每天多次直接部署到生产环境，通过 LaunchDarkly 等特性标记工具控制特性的可用性。

我合作过的金融机构（也有许多其他机构）往往有一个多少有些零散的环境管道，包括开发、集成、UAT、过渡和生产，有时在本地，经常有非常正式的手工部署过程。最终，如何定义这些过程取决于每个组织的文化以及对风险和质量的态度。

我还曾与一个大型政府部门合作，每天在多个环境中连续部署 100 多次，这些环境全部都是自动化的，并且最大可能地提供了自助服务能力，供工程师配置资源和运行测试。

不久前，我的团队还曾与一家医疗服务公司合作。该公司曾为季度公开发布将代码和（手动创建的）发布说明刻录到 DVD 上，以满足监管要求。

关键是：虽然存在管道的最佳实践模式和范例（如持续集成、高度自动化和通过自助服务赋能），但并不存在适用于所有组织的现成管道，也不存在随着时间推移不需要调整就适用于同一组织的管道；关于如何处理想法和需求，如何创建、部署和测试代码，如何保证质量，如何生成报告，如何运行、操作和审计，组织有着不同的需求和要求，他们的需求会随战略和环境（新的战略目标、新的客户期望、新的监管要求、新技术）而变化。

所以，我们要根据当前的需求来调整、演进我们的管道，这样它们才能满足我们未来的需要。

管道是战略资产，可以带来竞争优势

如果我们认为管道在组织中的内在角色是价值交付的“使能者”，并且它们的设计是环境相关的，那么我们不仅应该将其视为企业资产，而且还应该将其视为竞争优势的来源。

三年来，我的团队帮助我上面提到的那家医疗服务公司简化了监管流程：允许合规部门针对史诗和故事提出风险，将它们与功能、代码库、测试用例和测试结果（在待办事项管理工具中）联系起来，并以可跟踪、可审计的方式自动生成涵盖所有这些方面并将它们联系起来的发布说明。这将每次发布的人天量由大约 20 天减少到几乎为零，并且提高了发布文档的质量。

通过直接部署到生产环境，这家初创公司在一个竞争激烈、快速创新的领域中开展了业务，并依托更精简的机构（人员更少）和更快的上市速度（以更低的成本和更短的学习周期为客户提供更大的价值）获得了与其他公司竞争的优势。

因此，如果我们把管道做好了，那么它就不仅仅是企业的又一个驱动力，而且还可以成为竞争优势的来源。

管道很重要，所以把它们当产品来对待

如果管道很重要，那么我们不能拿一个现成的就用，我们需要仔细考虑慎重对待，知道现在和以后应该构建什么东西，并为我们的（DevOps）团队提供指导……所以换句话说，我们需要将它们视为产品，并引入产品思维。

设想一下：我们不会只是要求工程团队为我们构建电子商务网站、支付门户或社交媒体应用。我们会确定目标、研究什么对用户有价值，并将其作为背景和指导信息，提供给我们的设计师和工程师……

什么是产品思维？

产品思维是指基于组织的战略和背景，为我们的用户提供有价值的产品，并做到可持续发展（即平衡现在和未来）。

在这篇文章中，产品思维、产品意识和产品管理三个词可以互换。

产品管理的工作就是通过平衡用户合意性、商业可行性和技术可能性来创造产品-市场契合点。

在实践中，这意味着要通过平衡用户需要、想要并且发现有价值的东西（用户合意性）、我们作为一个组织需要实现（并且负担得起）的东西（商业可行性）和可能涉及的技术、文化、法律等（技术可行性），来实现产品与市场的匹配，与此同时，要谨防陷入过早优化或过早关闭选项的陷阱。

举一个小而具体但很能说明问题的例子：对于那家医疗设备组织，我们选择将 Bash 作为脚本语言，因为 DevOps 主管对它很熟悉。最终，我们意识到，客户的工程师没有 Bash 经验，而作为.Net 团队的成员，他们更熟悉 Python。如果在早期阶段添加一个以用户为中心的方法（作为产品思维的一部分），就可以防止这种错误和由此导致的返工。

如何对管道做“产品管理”？

归根结底，你只是“添加产品”。这是一种比较随意的说法，意思是你所做的事情要与做任何其他产品或服务一样。

在我共事过的一家初创公司中，这意味着首席工程师“要戴上产品的帽子”，从早期业务目标的视角来审视管道：在一个小而友好且高度可控的潜在客户群体中，使用 MVP 来衡量产品与市场的契合度。结果，他建议选择速度（如直接部署到生产环境）、管理特性可用性的特性标记、AWS Lambdas 和 AWS Cognito。然后，我们将监控业务发展，并在需要时扩展/构建更多的自定义功能（如身份认证）（而不是为可能永远不会到来的未来而构建）。

我们在之前的例子中提到的保险公司曾要求我们帮助他们构建一个平台，用于支持 100 多个微服务，而且要云无关（以确保业务连续性）。由于这个环境很复杂，所以我们增加了一个专职的产品负责人来支持 DevOps 工程师团队。首先，她组织产品和工程团队召开了一系列研讨会，以了解他们目前的工作方式以及所做的工作。她很快就发现，组织错过了向客户承诺的里程碑，因为工程师无法高效地发布代码（原因是在环境之间迁移代码和配置资源是手动进行的，而且有资源限制）。她还发现，在接下来的 12 个月里，该组织将只有三个微服务，云无关只是一个长远的目标，并不是目前的必备要求。

在深入了解了“价值”对于组织而言究竟意味着什么之后，所有人都一致认为，现在团队需要构建和发布高质量的功能，并达成向客户承诺的里程碑。因此，产品负责人与团队重新调整了优先级，制定了一个路线图，重点是消除只有两名工程师能够手动将代码部署到过渡环境和生产环境所导致的障碍，然后通过基本的自助服务（基于标准化模板自助配置新的微服务和其他资源）为工程师赋能。最初，他们会专注于一家云提供商，但也会考虑未来的云无关性。他们还指出，目前只有三个微服务，后续随着复杂性的增加，要解决构建微服务网格的问题……

对管道做产品管理的工具

一般来说，用于对管道做“产品管理”的工具和技术与“平常”用于产品管理的工具和技术一样。可以从下面这个“框架”入手：

1. 确定环境

从设定场景开始。理解管道的运行环境。定义并达成一致：

• 交付管道需要支持什么近期、中期和长期目标

• 有什么重要的机会，有什么问题可以解决

• 关键约束是什么，有什么可能性

还记得医疗服务的例子吗？最初的任务概要是将现有的应用程序容器化，并迁移上云。虽然这样做是有必要的，但我们在分析过程中发现，单靠这一点并不能帮助组织实现预期的吞吐量提升，那只能通过简化监管审批流程来实现。

在这个阶段，对现有任何流程建模都非常有用，特别是考虑到瓶颈和已错失的机会。

2. 识别潜在用户

第二步，了解谁将使用管道，谁从管道受益，并受管道影响。这里要纵观全局。

你会想到一些常见的岗位，如工程师、QA、DevOps 工程师，但我建议你扩大受众范围，包括产品人员、销售和市场营销人员、专业涉众，如医疗软件示例中的合规和监管机构。涉众地图或涉众洋葱是我的首选模型，不过简单的列表也可以。

医疗服务组织的涉众洋葱图示例，重点关注法规遵从性涉众。

3. 识别用户的工作、需求、收获和痛点

在接下来的步骤中，你会希望了解这些用户需要完成什么工作、他们的基本需要、相关的收获和痛点、他们的期望和需求。价值主张画布或类似的模型，或用户角色，在这里很有效。在接下来的步骤中，我们可以使用这些工具开始为每个“需求”确定潜在的解决方案。

注意，你可能不知道从哪里开始，但你也不想过度分析。这里，服务蓝图或体验地图可以派上用场了，我们可以利用它们将用户、需求和痛点联系起来，这样就可以确定哪些地方值得花费更多的精力分析。体验地图或服务蓝图也是很好的交流工具，我们甚至可以用它们来显示进展。

回到医疗服务公司的例子，考虑一下合规经理：他们要考虑识别风险，他们的需求之一是证明可追溯性（解决方案：集成风险管理和待办事项跟踪），但是创建发布文档的过程很冗长且容易出错（解决方案：自动生成文档），并且他们希望可以将所有的文档都直接提交给监管人员（解决方案：集成）。

Futuris 改版的构思画布（Ideation Canvas），用于识别用户期望和潜在解决方案（作为 Strategzyer 价值主张画布的替代方案）。

说明过程和痛点的体验图。

4. 定义优先级

最后，你需要基于前面的所有工作确定优先级：首先做什么，下一步提供什么支持。在这方面，功能图是一个完美的工具。这里，最好的做法是将特性分组，放到实现组织和团队长期目标的不同版本中，然后回过头来与第一个活动中确定的目标建立联系，创建我们的产品路线图。

对于医疗服务公司来说，这意味着：

1. 实现一个基本的端到端流程，以便团队可以轻松地跨所有环境部署代码

2. 创建一个经过监管机构认证的实际运行环境

3. 实现合规文档自动化

4. 实现强大的自助服务功能

显示四个“版本”和功能优先级的功能地图示例，基于 Jeff Patton 首创的故事地图概念。

自建还是购买？

经常出现的一个问题是，在哪里投资和创新，在哪里构建，哪些方面要自有，哪些方面要外包、购买或租赁。

我发现，在做这方面的决策时，沃德利（Wardley）地图是一个很好的工具，因为它根据整个价值链的相关内容和各种解决方案的行业成熟度来指导我们的战略方针，然后告知我们是“构建还是购买”，是实现商品化还是尽力防止商品化，以及如何促成或防止商品化。

医疗器械公司的沃德利地图示例，说明了在创新法规遵从性流程方面具有的竞争优势。

回到医疗服务公司，其交付管道的沃德利地图证实，有个好的集成服务器很重要，但也是商品化的，显然，我们应该选择一个最好的解决方案。更重要的是，它表明，合规过程的自动化是效率和竞争优势的来源，但没有现成的解决方案，这是一个我们应该进行创新的领域。沃德利地图随后提出的问题是，我们是应该对这一过程进行知识产权保护并保持其专有性，还是应该与竞争对手和监管机构合作创建一个行业标准，哪一种做法更有利。

什么时候才算完成了呢？

上述活动在管道工作的早期阶段特别有用，例如在启动阶段。这个启动工具包为我们提供了用来制定计划的模式和模板。不过，就像开发任何产品一样，这个过程永远不会结束；产品管理是一个持续性的活动，而不是一次性的。

组织的目标会变，用户的期望会变，有的技术会过时，也会有新的技术出现。因此，管道也得调整和演进。想想不断变化的合规环境，或者一个组织今天还在某个市场的某个行业中，明天所处的市场却已完全不同；此外，我们如何从本地托管迁移上云，再到无服务器，还有大数据和 ML 等新技术在基础设施方面提出了不同的要求。

该怎么办？

引入产品思维是有好处的

我从团队和客户那里得到的反馈，以及那些可度量的改进（吞吐量、周期时间、质量、价值交付），都清楚地表明，在 DevOps 中引入产品思维不是可有可无的，而是必须的。

对于 DevOps 工程师来说，它使他们的生活更轻松，它使他们可以专注于正确的事情，它赋予他们能力：最基本的，它消除了噪音和担忧，使他们知道该做什么，使他们能够创建一个流畅的管道，让每个人都生活得更轻松；在最好的情况下，它使 DevOps 可以为组织创建战略资产。

对组织来说，它可以保证价值交付，它使产品交付成为可能，并可以保证我们合理地使用资金，通过支持管道的创建，组织的所有部门都将朝着实现战略目标的方向努力，降低因为团队不确定应该做什么、不清楚应该听取谁的意见或不知道该专注于哪个解决方案而导致的风险和浪费。

到底该怎么办？

我们可以用一种非常轻量级的非正式方式“引入产品思维”：“只是在心里记着”。或者，我们可以用一种更正式的方式，增加一个专门的产品专家来支持 DevOps 工程师。也就是说，团队可以根据自己的喜好、文化和预算进行选择。

当你觉得我建议的工具和实践适合自己，当你觉得这样会让自己很舒服，就没有理由不尽快采用它们。你甚至不需要做“每一件事”：我上面提到的任何一种技术，本身都可以带来增量价值。

或许这一切对你来说都有点新鲜，不用担心，只要找一个产品的同事，让他们或多或少地参与下你的分析和决策过程……

想要进一步了解这个主题或收听会议发言录音的话，请点击这里。

原文链接：

https://www.infoq.com/articles/product-mindset-devops/

相关阅读：

DevOps的未来是无代码

DevOps 团队结构类型汇总：总有一款适合你

什么是 DevOps？看这一篇就够了！

如何让 DevOps 发挥期望的效益