过节前看到一篇文章，讲产品项目就应该由工程师来主导，但国内让PM去驱动项目，搞得乱七八糟，很恼火，怎么可能做出一款好产品来呢？
很显然，写这篇文章的是一位愤怒的工程师，Angry Engineer！我跟他至少有两点共鸣：
1、国内的PM确实常常折腾工程师，甚至不乏“把工程师当工具对待”的情况，
PM与工程师交互设计
。2、如果工程师有开阔的产品视野与全面的设计素养，知行合一，由工程师来驱动项目是一个完美的选择。
可惜由于教育环境的问题，国内通才太少。一个优秀的工程师，同时又是一个优秀的PM，凤毛麟角，只能人任其长，各自做自己拿手的活儿。这时候更擅长需求分析与产品设计的PM来驱动项目，也是不得已的选择。
说来惭愧。需求不靠谱，或是来来回回修改，折腾工程师的事儿我也做过不少，直到最近一年多才算是大有好转。我应该忏悔……虽然能做好PM的工程师极少，靠谱的PM其实也不算多，最后大家都得写周报对不对？
在产品行业远远不够成熟的现阶段，痛苦的来回折腾难以避免。但最起码，PM应该把工程师作为伙伴而不是工具，想法设法地站到一条战壕里去，争取他们的理解。因此抛开难以鉴定的需求的对错，仅仅从协作流程的改进上，我积累了以下的经验。
首先要得到工程师对整个项目的认同。每个月都有一场一小时的部门月会，对着PPT，我来讲下个月乃至下个阶段，我们的任务规划是什么，目标设置又是什么，详细解释制定规划与目标的原因，近景与远景分析，为咩做这件事情为咩这样去设计等等。希望工程师能认可他即将做的事情是有价值的，值得为之而努力的。为接下来PM与工程师的沟通做好铺垫。
月会上还有一个环节，详细分析本月发生的所有数据，尤其是最近发布的新功能的数据。这个环节也是为工程师准备的，使他们了解自己的工作能产生多少实际效果。
至于月会上送出的新功能礼品（以前讲过许多次），最开始是为工程师专设的彩蛋，再后来才将PM与运营包括了进来。我得承认自己对工程师偏心眼，因为有信心能激励PM与运营，却出于沟通深度不足，需要借助更多的手段来激励工程师投入项目。
项目任务分两种，大版本与小模块。对于大版本，在基本框架定下来之后，PM提前向工程师讲解，听取技术视角对设计方向的建议。整个设计过程中还会反复讨论三五次，为技术上的合理性征求意见。小模块则在策划案基本敲定之后，与工程师共同确认一次，视觉稿出来后再通报一次。（所以PM与工程师坐得近是很有必要的）
我曾经在部门月会上公开承诺说，任何一个需求，只要工程师认为是不合理的，都可以停下来不做。直到PM能说服工程师为止。如果死活谈不下来，才由我和技术经理出面来协调。强硬要求服从的情况在我这里基本上没有，被工程师说服倒是时有发生，按工程师提出的意见来改方案。我也常常跟PM讲，小分歧你们都听工程师的，没有必要坚持己见。你让他爽一点，开发速度就快一点，大家都获益。再说你多听听技术伙伴的意见有什么不好呢？帮助你转换思考的角度，共同找到提高开发效率的方法。
最后方案定下来了，PM说OK，工程师也觉得方向大致没错，细节基本合理；进度方面则由工程师进行评估。PM觉得时间太长接受不了，再找到我和技术经理一起商量，看是分阶段砍需求呢，还是加把力加点班。除了极少数紧急修复任务外，不会由PM单方面确定开发时间安排。包括一系列任务的优先级安排，也由PM先提草案，工程师根据开发情况来调整顺序，再共同确认。
在PM提出需求的整个流程里，始终在进行不断的协商，保证工程师对任务是理解并且接受的，不会出现抗拒，或者是麻木的心态。如果遇到突发性的需求变更，更加会向工程师反复解释，请求谅解，因为浪费了他们的工作成果而心存歉意。为此而花费的时间对比更高的开发效率，稳赚不赔。虽说具体协作时还有一些不到位的地方，但态度总归是好的，基本的效果也是有的。
当然，这套流程的实施得具备两个前提。第一是有稳定的团队，如果变成提单协作，这个月一起干下个月分道扬镳，那就不可能实现共同的项目归属感。第二是工程师的个人素质基本靠谱，沟通顺畅；尤其是技术经理可以服众，协调好分歧而不护短。比如说一个功能能不能做，至少开发多久，我和PM都搞不掂，主要靠技术经理来做最终判断；如果出现开发过程中的失误，或是不按照约定好的方案进行开发，则由技术经理进行处罚。我对开发组更多作行政管理，全靠这位技术核心伙伴来负责业务管理，他也会更深入地参与到产品的结构设计，任务规划里来。
这样做，也就撇开了把工程师当工具对待的嫌疑，
电脑资料
《PM与工程师交互设计》(https://www.unjs.com)。我觉得把任何同事当工具都挺可耻。怎样才算是伙伴呢？比如交流必要的信息，理解对方；比如能站在对方立场去换位思考；比如多一点点鼓励与帮助。换个角度看，我这边曾经出现过由工程师来提出大致构思，PM认可并负责细节设计，再由这位工程师来实现的情况。结果皆大欢喜。我后来多次在月会或别的场合征求工程师的创意，换一换视角，引入新鲜的想法与灵感。即便想法不一致，也会非常温和地解释反对原因，绝不可能一口否决。唯恐工程师们默不出声闷头干活——听不到技术伙伴的意见是多大的损失啊。
以上来自：/uidesign/20110503/91582.html
也谈：PM与工程师
来自：/uidesign/20110503/91582.html
看了纯银写的《PM与工程师》，也参加了PMCAFF深圳3月份的活动聚会，就这个话题聊聊自己的感想。
PM与工程师最容易产生冲突的地方在于需求和进度：产品需求变更折磨工程师、项目进度延迟、产品质量不过关，影响到产品的上线和运营。
大体上，可以通过下面几点来避免：
(1) 认同，归属感
在产品规划阶段，跟工程师多聊聊，聊一聊项目背景、市场机会、我们做这个产品对公司有什么好处、以及很关键的一点是产品的成败对我们切身利益的影响。建议工程师的认同感，归属感，并唤起他们的主人翁意识。
归属感这点：在抄送邮件时，我也会主动提起某某工程师的名字，对他们的配合表示感谢，对他们的工作表示赞同。
（2）产品评审，可行性分析
快速产出一个产品DEMO，召集工程师、运营人员等相关人员评审，简单再讲讲产品背景，我们要做的是什么；这个版本是拿来投石问路的，一方面是可行性分析，另一方面集思广益。
在这个评审会议上，产品的主要方向和功能点都能确定下来。
（3）需求传达清楚
产品设计文档描述清楚，产品逻辑合理，产品定位清晰。
（4）版本规划、进度安排
功能优先级划分：根据业务需求，制定功能优先级，优先开发主要功能。再根据项目上线要求，安排工作进度，确定几个关键的时间节点；
通常互联网产品都讲求敏捷，小版本快速迭代的思路，如果需求比较大，制定版本规划，1期实现核心功能和主要功能，2期实现次要功能和附加功能。
砍需求：这个是最容易出现的情况，对于一些技术上比较难实现的有些工程师往往会跟你讨价还价；对于商业价值不大的需求，往往也会被领导砍掉。通常，评审之前对于哪些需求会被砍，是心里有数的。
（5）开发协调、进度把控
理论上，在产品评审会议上有进行过需求解释，但是实际上在开发过程中也会产生种种疑惑（有的是需求没理解到位，有的是产品设计不完整），在开发过程中，PM要保持跟进，尽量不产生偏差。
进度把控：开发中通常会有其他任务插入，比如紧急的需求和人员被抽调出等，这个时候要协调好资源
（6）取舍
有舍有得，这个是真谛。开发过程中,一些零碎的小需求，以及用户体验上的小东西，实现上工程师会跟你有争议。通常小范围无关大局的可以从了工程师，但是原则上的东西一定要坚持。
切忌，别跟工程师死磕，也别把工程师逼得太狠了，团队和谐的气氛很重要。
（7）需求明确，尽量少变更
业务层次上的需求变更是没办法的，如果有对工程师工作推到从来的情况，最好多跟工程师沟通好，比如“领导决定的，我也很委屈”，表明自己也受伤害了。
对于功能层面的，PM在做产品规划时要考虑清楚再下手，产品设计过程中，为什么要这样做，为什么不这样做，要有合理的根源；有疑议的地方最好拿出来和大家讨论清楚，或者等需求明确了再下发。
头脑清醒，内心强大，这是最PM追求的境界。而无数次评审会练就强大的内心力量。
（8）技术基础
最好能多去了解一些基本的技术原理，HTML/CSS/PHP数据库。工作中也要多问，虚心地向工程师请教，一般工程师会很乐意为你解答的。
（9）沟通、协调
配合好，积极主动的工程师真的很难得。有产品意识的工程师更是可遇而不可求。和工程师的交谈，最好能站在他人的立场上，用工程师的语言来沟通。
沟通能力、协调能力甚为关键，这两点也不是三言两语就能说清了，这里就先不多说了。
人情练达即产品，路漫漫其修远兮。