13518219792
看了纯银写的《PM与工程师》，也参加了PMCAFF深圳3月份的活动聚会，就这个话题聊聊自己的感想。
PM与工程师最容易产生冲突的地方在于需求和进度：产品需求变更折磨工程师、项目进度延迟、产品质量不过关，影响到产品的上线和运营。
大体上，可以通过下面几点来避免：
（1）认同，归属感
在产品规划阶段，跟工程师多聊聊，聊一聊项目背景、市场机会、我们做这个产品对公司有什么好处、以及很关键的一点是产品的成败对我们切身利益的影响。建议工程师的认同感，归属感，并唤起他们的主人翁意识。
归属感这点：在抄送邮件时，我也会主动提起某某工程师的名字，对他们的配合表示感谢，对他们的工作表示赞同。
（2）产品评审，可行性分析
快速产出一个产品DEMO，召集工程师、运营人员等相关人员评审，简单再讲讲产品背景，我们要做的是什么；这个版本是拿来投石问路的，一方面是可行性分析，另一方面集思广益。
在这个评审会议上，产品的主要方向和功能点都能确定下来。
（3）需求传达清楚
产品设计文档描述清楚，产品逻辑合理，产品定位清晰。
（4）版本规划、进度安排
功能优先级划分：根据业务需求，制定功能优先级，优先开发主要功能。再根据项目上线要求，安排工作进度，确定几个关键的时间节点；
通常互联网产品都讲求敏捷，小版本快速迭代的思路，如果需求比较大，制定版本规划，1期实现核心功能和主要功能，2期实现次要功能和附加功能。
砍需求：这个是最容易出现的情况，对于一些技术上比较难实现的有些工程师往往会跟你讨价还价；对于商业价值不大的需求，往往也会被领导砍掉。通常，评审之前对于哪些需求会被砍，是心里有数的。
（5）开发协调、进度把控
理论上，在产品评审会议上有进行过需求解释，但是实际上在开发过程中也会产生种种疑惑（有的是需求没理解到位，有的是产品设计不完整），在开发过程中，PM要保持跟进，尽量不产生偏差。
进度把控：开发中通常会有其他任务插入，比如紧急的需求和人员被抽调出等，这个时候要协调好资源
（6）取舍
有舍有得，这个是真谛。开发过程中，一些零碎的小需求，以及用户体验上的小东西，实现上工程师会跟你有争议。通常小范围无关大局的可以从了工程师，但是原则上的东西一定要坚持。
切忌，别跟工程师死磕，也别把工程师逼得太狠了，团队和谐的气氛很重要。
（7）需求明确，尽量少变更
业务层次上的需求变更是没办法的，如果有对工程师工作推到从来的情况，最好多跟工程师沟通好，比如“领导决定的，我也很委屈”，表明自己也受伤害了。
对于功能层面的，PM在做产品规划时要考虑清楚再下手，产品设计过程中，为什么要这样做，为什么不这样做，要有合理的根源；有疑议的地方最好拿出来和大家讨论清楚，或者等需求明确了再下发。
头脑清醒，内心强大，这是最PM追求的境界。而无数次评审会练就强大的内心力量。
（8）技术基础
最好能多去了解一些基本的技术原理，HTML/CSS/PHP数据库。工作中也要多问，虚心地向工程师请教，一般工程师会很乐意为你解答的。
（9）沟通、协调
配合好，积极主动的工程师真的很难得。有产品意识的工程师更是可遇而不可求。和工程师的交谈，最好能站在他人的立场上，用工程师的语言来沟通。
沟通能力、协调能力甚为关键，这两点也不是三言两语就能说清了，这里就先不多说了。
人情练达即产品，路漫漫其修远兮。
文章来源：行者的产品设计博客 转载请注明出处链接。
