优界网

首页 > 产品经理 > PM与工程师,在“对立”中协作

PM与工程师,在“对立”中协作

30

0

0

2015-05-14 13:30:32

江大可

分享一下,又不会怀孕!

本作品为转载作品,版权为作品原作者所有,感谢上传者的分享!

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

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

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

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

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

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

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

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

2、做足调研(产品需求/功能点)功课

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

2.1、如果有竞品

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

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

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

3、产品方案如何平衡

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

QQ截圖20150209235036

* 竞品逻辑一定要看

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

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

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

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

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

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

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

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

4、产品与工程师文化

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

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

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

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

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

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

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

5、写在最后

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

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

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

* 保持开放的心态

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

已有0人赞过

+1赞

认真评论的都成大咖了

还可输入1000个字

我要评论 我要评论
  • 刚刚
  • 登录优界网 ×