优秀的产品负责人拥有塑造产品愿景的天赋，但如果负责人在产品的初始构想阶段就没能与工程师有效沟通，结果只会浪费时间、机会和人才，这样下去最后可能会毁掉一个项目。

本文最初发布于builtin.com，经原作者授权由InfoQ中文站翻译并分享。

所有成功的软件公司都有一个共同点，那就是他们能够开发出让客户为之买单的产品。

但是，构建一款成功的产品需要做大量工作。这些工作包括了解用户需求、集体讨论用户流程、设计界面和架构，然后是实现、测试，最后推出产品功能。

所有这些环节都需要许多拥有不同技能的团队成员参与。但是，即使在鼓励协作的敏捷环境中也普遍存在一个问题，那就是产品负责人会独自承担塑造产品愿景的职责，并且常常无法采纳其他团队成员的意见。

这些产品负责人会独自提出关于产品功能形态和实现方式的想法。然后，他们将相关的规范或故事转交给开发人员，让后者去评估和实现。

在这种情况下，客户需求在到达开发人员之前已经经历了一系列反馈循环。在前期，开发人员对一开始出现的问题一无所知；他们只知道产品负责人要他们做出来哪些功能。

在实践中，一个例子就是用户故事的接受标准被强加了一个特定的技术实现。

想象一下你正在构建一个电子商务平台。产品负责人要求你保留产品价格的历史记录。他们还不知道如何将其呈现给用户。但是他们希望有某种价目表，其中包括每次价格更改的日期，以及一个显示当前值的字段。

当你询问如何在验收会议上验证此类需求时，他们会告诉你质量检查小组将在数据库中检索产品，并检查产品是否具有价目表和当前值的属性。

这个用户故事在很多层面上都是错误的：首先，它不会为用户带来任何有用的价值，因为它是后端的更改，不会影响用户体验。其次，产品负责人强行指定了解决这个问题的方法，但他的方法可能不是最佳解决方案。

其实用不着为当前值和价目表提供属性，只需保留一个包含价格和日期的数组即可，例如：

const prices = [{price: 16, date:”12-04-2020”}, {price: 15.99, date:”20-04-2020”}]

在程序中，我们可以从价格更改的日期推断出最新的价格就是当前价格。
上面的例子描述了一种简单的情况。对于更复杂的用户故事而言，强行让开发人员使用某种解决方案，不仅会减慢开发团队的速度，而且还会引入软件设计错误。

多数人认为某些工程决策会导致软件质量下降，而实际上这是软件项目管理不力的表现。

以我的经验，失败的软件项目过程大都类似：产品负责人希望构建一个特定的解决方案，却没有明确指出他们要解决的是什么问题。

对于产品的第一次迭代而言，这可能可以理解。但随着产品逐渐成熟，产品负责人应该对产品要解决的问题有更清晰的认识，并与团队一起寻找合适的解决方案。

否则，功能和需求的反复横跳会迫使团队花费大部分时间来重建各种东西，或者他们得被迫使用某种老式的软件决策系统，最后拖累新功能发布的速度。

开发人员对功能请求的反应可能有所不同。有些人可能会接受这些要求，并完全按照需求描述来执行这些要求，而不会提出任何问题，还有人会提出问题并了解需求背景。在开始实现功能之前，他们会首先尝试找出潜在问题。他们会提出另一种选项，来了解产品负责人都考虑了哪些因素，以及为什么负责人决定走这一条路而不是另一条。

我们将这类开发人员称为产品工程师。这些人能够将自身强大的技术背景与对业务的透彻理解结合起来运用，他们在完善产品的过程中起到了至关重要的作用。

正如Atlassian的产品经理Sherif Mansour在他关于产品工程师的文章中所述（https://medium.com/@sherifmansour/product-engineers-f424da766871）：

作为一门年轻的学科，我们花费了大量时间来研究“如何”构建软件，而这依旧是学校教育的重点所在。但是一旦有了基础，我们就需要那些积极探索“为什么”这样做的开发人员。这类开发人员是渴望使用技术解决人类/用户问题的工程师。他们富有同理心，渴望探索奇妙的旅程。这就是我在书中定义的产品工程师。……低水平的产品工程师会绕很多远路，但伟大的工程师知道，团队在构建MVP产品的阶段就需要有足够的思考深度。

产品工程师提出了不同的解决方案，但他们也能够快速估算出各种方案的可行性。产品工程师通常会对潜在实现所需的工作量有更准确的判断。这样他们就可以迅速评估多种解决方案。

也许产品工程师提出的解决方案是产品负责人一开始就放弃的，因为后者担心这种方案需要的投入太大，也许产品负责人甚至都不知道有这么一种可行的方案选项。

在为开发人员开发产品的公司中，产品工程师是必备的角色。我之前在Crate.io的一个团队中任职，我们负责的产品是一个分布式SQL数据库。那时我得以同许多有能力的产品工程师共事。我们的产品负责人知道如何在产品构想阶段就调动起这些产品工程师对问题解决方案的热情。

那些工程师拥有丰富的知识和影响力：每个人都向他们提出各种问题。当然，他们没有那么高大上的头衔；他们只被称为软件工程师而已。

我要讲的重点并不是要为他们的职位换上好听的头衔和描述（尽管这可能会有所帮助）。热情的产品工程师确实存在，而且他们的专业知识非常宝贵。优秀的产品负责人具有塑造产品愿景的天赋，但若负责人无法利用产品工程师的独特经验和见解，就是对机会和人才的浪费。

跨职能协作会带来最佳结果。产品工程师可以提供有关解决方案可行性、可用性和安全性问题的见解；产品负责人可以提出产品愿景：管道中有哪些功能，为什么？

正如Marty Cagan在这篇文章（https://svpg.com/the-most-important-thing/）中所解释的那样，赋予产品工程师权力，并不只是让他们自由选择代码基础和架构就够了：

赋予工程师权力，意味着你可以让工程师了解你要解决怎样的问题，了解业务的战略背景，这样他们就能够利用技术来找出解决问题的最佳方法。

判断你是否已赋予工程师权力的一种简单方法是，如果你的工程师第一次看到产品创意是在Sprint计划会上，那么你们显然就只是一支功能团队，而你的工程师在任何层面上都没有得到充分的权限。

我一直在说，如果你只是让自己的工程师写代码，那么你所获得的价值就只是他们潜力的一半而已。

这样可以确保工程师与产品团队保持一致，并帮助他们了解产品决策背后的意图。要打造成功的产品，团队合作是必不可少的：拥有不同技能的人们需要团结起来。应当鼓励工程师尽早参与讨论。如果将他们排斥在外，那么代价就会体现在产品之中。

作者介绍：

Meriam Kharbat是Field Intelligence Inc.的高级软件工程师。

原文链接：https://builtin.com/software-engineering-perspectives/product-engineers

创作场景

这是一篇工程师对产品经理的吐槽