这是我很喜欢的两位拳手，一位是出生于拳击世家未尝过败绩的美国人梅威瑟，另一个是叱咤拳坛的菲律宾国宝帕奎奥。听说两人将在今年5月份在米高梅中心来一场世纪对决，一想到这个场面，就激动不已。

本文要写的PM与工程师之间，肯定不会像拳击比赛一样充满火药味儿，但“对立”的情况是肯定存在的。一方寻求用户体验，一方寻求实现方案性价比，在评审过程中会发生很多的“摩擦”。PM需要推动摩擦到和谐的转化，推动产品在“航线”上前进。

工程师与产品经理的“对立”从产品评审开始，一直到Debug结束。有的时候，可能从产品需求确定环节就已经开始了。经常出现的场景是：工程师会说XX功能不重要，自己都不会去用，产品经理也会说工程师嫌麻烦而要求简化产品与交互逻辑…工程师与产品经理之间的“对立/冲突”会经常发生，从需求，逻辑，交互，图形等各个环节都会出现。

PM脑袋会大，工程师脑袋也会大。这个过程是痛苦的，但是必经的，当PM能够缩短对立时间，最大化产品评审效率，那么自己就成长了。我在自己的产品工作经历中，遇到过就一个功能被工程师问得哑口无言，也被工程师挑战过产品逻辑的合理性，这样的例子有很多，也曾经花两天时间就一个默认选项的问题“说服”工程师。所谓说服，并不是让对方听自己的，而是另对方心悦诚服，这样才能更好的开展接下来的工作。如果协作双方都有抵触情绪的话，项目进展不顺利也就可想而知了。以下是自己与工程师协作过程中的经验，与大家分享。

以下是从PM角度出发的观点

1、选择哪种类型的工程师与自己配合？

要选择一个“针对你”的工程师。这里所说的“针对”，指的是独立思考，拥有较强的逻辑思维能力，喜爱产品（有产品思维）。在与这类工程师协作时，你将经常被挑战，迫使自己在与工程师沟通时要做足功课。如果自己遇到了这样的工程师，不该扫兴（因为他经常能把你挑战的体无完肤），而是应该庆幸，因为他能帮助你快速提升自己的能力。如果工程师按照你的设计一五一十的完成研发，最终的结果不一定是最好的。

有些PM会觉得工程师不懂产品，他们的意见无关痛痒，但这种观念是错误的。工程师也是用户，也在体验产品，有自己的观点。要把工程师当做用户看待，他们的建议要听并去分析，很多点子可能PM连想都没有想过。

2、做足调研（产品需求/功能点）功课

有些公司工程师是不介入功能点决策环节的，有的公司则会介入，小型产品团队，工程师介入到功能点决策环节的情况比较多。介入是好事儿…

2.1、如果有竞品

下载5个主流的竞品app以及几个非主流竞品app，把相关功能点做分类对比，分析出优缺点，然后找到最合理的解决方案。要保证你用过的相关产品比工程师多，就算工程师用过一个“偏门”，由于你用过了更多的app，那么对于他的问题也是可以回答的。很多产品经理就盯着一个或两个竞品app看，然后就得出了结论，这个往往是不够的。“嫁接”不可取，需要因地制宜。当工程师提出“这个功能没啥用吧”，你会给出客观依据，同时自己要成为自己产品的重度用户，这样才能从客观和主观体验上给予论据

2.2、如果没有竞品或竞品中没有此功能

给出用户使用场景，尽量量化场景。什么情况下，谁用，怎么用，多少人会用。量化场景是最难的，无法直接量化就间接量化。同时从使用角度出发给出重度用户的主观使用体验。很多时候PM都会遇到这样的反馈“这个功能强度有那么大吗？会有人用吗？”，此时给出直接或间接定量数据就显得很重要的，不过也有很多时候是无法量化的，那就只能凭借主观体验，经验判断和个人魅力了

3、产品方案如何平衡

产品方案（产品逻辑或交互流程）是另一个评审的重点部分，因为涉及到开发的性价比，产品经理在考虑用户体验的前提下，也要保障能够提升研发效率。一般的做法是，给出多个产品方案。首先要调研竞品逻辑，然后再给出自己的产品逻辑，结合自己产品的实际情况列出方案优缺点。评审的时候就多个方案展开，并选出最终方案

* 竞品逻辑一定要看

* 至少给出两个产品方案（不为给方案而给方案，如果逻辑简单，一个方案也OK），尽量从产品角度考虑全面

在评审过程中经常会遇到如下两种情况：

3.1、整体产品方案由于技术限制不可行，如何解？

* 如果技术限制是有限的，那么就在评审时记下并在会后对方案进行调整

* 如果逻辑复杂，那么就需要在方案设计时就去找工程师评估可行性，得到确认后再继续完成全部

* 产品经验丰富后，PM自己就能够总和筛选方案了

3.2、产品方案优缺点各异无从选择，如何解？

产品方案都与产品目标相符，且方案各有特点，或无直接或间接数据印证好坏，尤其是PM与工程师各执一词。如果出现这样的情形，则选择其中一个方案上线，然后根据具体情况再做迭代优化

4、产品与工程师文化

团队文化直接影响着产品的推进。有的公司是产品主导的文化，产品话语权较重，那么工程师更倾向于执行；有的公司是工程师文化，工程师会在产品未设计前就开始了demo的研发，产品随后介入进行设计。这两种公司我都经历过，也都有过错误的认识。

* 当我在产品主导的团队时，我会觉得自己说了算，自己的设计没有问题，工程师直接去开发就好了，他们无需对需求和核心逻辑产生什么异议；

* 当我在技术主导的团队时，我又觉得研发先行产品随后介入的工作方式是本末倒置，从而丧失了主动性和积极性

经历过后深刻的体会到，这两种想法并非客观也并非高效

* 产品主导是有前提的，那就是不能以抑制工程师思想为前提，产品中一定要有他们的声音。工程师不是机器，他们有思想，是用户，且很可能还是重度用户

* 技术主导时，工程师与产品工作是并行的，且是相向而行的。PM更应该做足功课，积极地参与到项目中来

当工程师的想法被接纳或心悦诚服的采纳PM的方案，当技术先行的demo由于产品经理的建议更好而被优化，那么就不仅仅的PM或工程师的胜利，而是整个产品团队的胜利

5、写在最后

* PM与工程师是合作关系，过程中的对立是正常的，是成长的基石。PM要勇于接受来自工程师的“挑战”

* PM要做足功课，让自己处于产品的核心，成为项目中各个环节的纽带

* 适应公司或团队文化，发挥产品经理的特长，诚服于人

* 保持开放的心态

希望我的分享能够帮到大家，并给大家带来启发

本文由作者ZHENG（公众号ID：liushizheng-pm）投稿发布，转载请注明来源于人人都是产品经理并附带本文链接