最近两篇优秀的博文都谈到了我自五月份 OpenStack 峰会以来一直纠结的一个话题：产品管理职能在 OpenStack 开发流程中的作用是什么？如果有的话。
第一篇文章，Evan Scheessele 写的“呼吁所有“用户领域”人士领导 OpenStack 超越云端”，谈到了 OpenStack 的“真实用户”——那些需要交付能够为其组织带来某种价值的解决方案的人。另一篇文章，Rob Hirschfeld 写的“到底谁说了算？…”，讲述了 OpenStack 生态系统中如何做出决策（哪些 OpenStack 功能被纳入或排除）的动态。
像大多数人一样，我在职业生涯中担任过各种职位。我几乎都很喜欢。但我尤其喜欢产品管理。我热爱深入了解客户的需求。（这远远超出了询问客户想要什么，正如我在这里解释的那样。）我热爱帮助开发人员理解这些需求的过程。我喜欢看到这些开发人员提出我从未梦想过的创造性解决方案。然后我可以看到客户对这些非常酷的解决方案的反应。我不能说我“喜欢”决定给定版本中包含哪些功能以及排除哪些功能的界限，但我知道这是产品管理领域的一部分。产品管理是理解市场机会、客户需求、了解技术如何解决问题，然后看到客户在看到能够改善他们世界的东西时的反应的核心。这不是很棒吗？
我们大多数人都可能经历过以下情况：一位工程师或一小组工程师对产品有一个想法。他们对其进行研究，然后，当它具有一定程度的关键功能并且看起来正在解决一个实际问题时，其他人开始注意到它。产品管理看到了价值。公司管理层可能会开始介入。它可能会向销售组织甚至客户公开。该项目从以实验室为中心的工作过渡到成为公司的正式计划。
我认为 OpenStack 现在正处于这个转折点。一直以来和现在被它吸引的开发人员对开发 OpenStack 功能很感兴趣。由于许多人长期以来的努力，OpenStack 现在拥有了足够有趣和有价值的功能，因此另一种类型的人正在被它吸引：那些需要决定他们将构建和交付解决方案的云技术的人。这些人对开发在 OpenStack 上运行的应用程序感兴趣并且需要这样做，但他们对编写 OpenStack 本身不感兴趣。
OpenStack 开发人员（贡献者）需要有一种方法来彻底了解这些用户是谁以及他们的需求是什么。这就是“产品管理”可以提供帮助的地方。它是一门学科，可以细分这些用户，确保他们被充分了解，并确保开发部门拥有非常清楚地阐述其需求的信息——以便开发部门可以确定并专注于解决这些问题。
但是 OpenStack 是使用开源模式开发的。社区，而不是个人，决定给定版本包含和不包含什么。功能根据其自身的优点和它们提供的价值获得动力并被接受。这是一个好的想法得到良好实施就能生存下来的环境…… 应该如此。
OpenStack 的产品管理是明智之举还是不明智之举？两者都是。将产品管理的“决策”角色（即决定给定版本中包含哪些功能和排除哪些功能的功能）引入 OpenStack 流程将是不明智的。这将不仅仅是不明智：这将是一场灾难。作为一名致力于 OpenStack、开源和产品管理的人，我认为这样做会违反开源的核心原则（？）：社区决定应该具备哪些功能。
然而，丰富关于用户、他们的角色、构建跨 OpenStack 项目的用户故事等的信息和文档，我认为对 OpenStack 非常有帮助。当前的 OpenStack 用户画像小组（我正处于早期阶段的参与）正在增加这种价值。我当然希望人们有兴趣让这项工作不仅继续下去，而且还要扩展，以便 OpenStack 开发社区能够获得关于谁最终是这种卓越的开发方法和由此产生的技术的受益者的丰富背景信息。此功能绝不是“管理”。没有涉及任何管理。它只是努力彻底了解一群人，然后将其充分记录下来并与编写代码的人员进行沟通。
本文最初发表于Accelerated Insight。经许可转载。
评论已关闭。