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

2020-05-21 22:00:00

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

本文最初发布于 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. 的高级软件工程师。

这是一篇工程师对产品经理的吐槽相关推荐

这是一篇程序员对产品经理的吐槽~~~
图片来源于节目<程序员吐槽大会> 开发和产品普遍存在相爱相杀甚至互相敌对的情况记得有段时间,某公司产品经理要求程序员实现"APP随手机壳改变主题色"的需求,被程序员暴 ...
中科研研究生：从算法工程师转行产品经理之后
向AI转型的程序员都关注了这个号???????????? 机器学习AI算法工程公众号:datayx 2020年7月21日,从算法工程师转行AI产品经理的第一天,到现在满两个月了.说来我的路径也比 ...
工程师、产品经理、数据工程师是如何一起工作的？
做为一名工程师,免不了与产品经理打交道,如果公司大一些,数据量多一些,还会有数据工程师这个角色.今天会和你主要聊一聊在工作中,产品经理和数据工程师在哪些方面对我们工程师的帮助最大,以及我从他们身上都学 ...
招聘：IT-互联网相关职位。如：手机客户端、iphone\ios\、PHP 开发工程师，产品经理...
招聘:IT-互联网相关职位---JD 工作地点:北京有意请发e-mail:happy.liu2010@hotmail.com Q:970446462 职位1:手机客户端研发工程师 ...
北京赞同科技发展有限公司产品开发部招聘高级软件工程师及产品经理
北京赞同科技发展有限公司是一家金融软件行业的专业公司,目前公司已经形成包括前端(柜台)系统.大前置(中间业务)系统.通讯前置(通讯中间件)系统.业务集中监控管理系统等多条产品线,公司客户主要有中国工商 ...
原创100篇文章，产品经理大百科到底写了啥？
100篇文章,我都写了啥?我很好奇的理了理.这个过程就像拼图,把碎片重新组成完整的自己,最终组成了产品经理大百科的公众号主题. 这100篇涵盖了8个方面:方法论干货18篇,产品吐槽16篇,成长经验13 ...
〖产品思维训练白宝书 - 产品思维认知篇⑦〗- 聊一聊产品经理的工作内容与职责划分
大家好,我是哈士奇 ,一位工作了十年的"技术混子", 致力于为开发者赋能的UP主, 目前正在运营着 TFS_CLUB社区.
〖产品思维训练白宝书 - 产品思维认知篇⑨〗- 像产品经理一样去思考解决问题
大家好,我是哈士奇 ,一位工作了十年的"技术混子", 致力于为开发者赋能的UP主, 目前正在运营着 TFS_CLUB社区.
产品经理和售前工程师_如何区分产品经理和产品工程师的能力
产品经理和售前工程师谁是产品工程师? 有时很难区分产品经理和产品工程师. 在这篇文章中,我们将尝试找出答案. 在一百一十一个职位中,产品经理也许是最令人困惑的. 事实是,从战略产品经理到电子商务或产 ...

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

这是一篇工程师对产品经理的吐槽相关推荐

最新文章

热门文章