很显然，写这篇文章的是一位愤怒的工程师，Angry Engineer！我跟他至少有两点共鸣：
1、国内的PM确实常常折腾工程师，甚至不乏“把工程师当工具对待”的情况。
2、如果工程师有开阔的产品视野与全面的设计素养，知行合一，由工程师来驱动项目是一个完美的选择。
可惜由于教育环境的问题，国内通才太少。一个优秀的工程师，同时又是一个优秀的PM，凤毛麟角，只能人任其长，各自做自己拿手的活儿。这时候更擅长需求分析与产品设计的PM来驱动项目，也是不得已的选择。
说来惭愧。需求不靠谱，或是来来回回修改，折腾工程师的事儿我也做过不少，直到最近一年多才算是大有好转。我应该忏悔……虽然能做好PM的工程师极少，靠谱的PM其实也不算多，最后大家都得写周报对不对？
在产品行业远远不够成熟的现阶段，痛苦的来回折腾难以避免。但最起码，PM应该把工程师作为伙伴而不是工具，想法设法地站到一条战壕里去，争取他们的理解。因此抛开难以鉴定的需求的对错，仅仅从协作流程的改进上，我积累了以下的经验。
首先要得到工程师对整个项目的认同。每个月都有一场一小时的部门月会，对着PPT，我来讲下个月乃至下个阶段，我们的任务规划是什么，目标设置又是什么，详细解释制定规划与目标的原因，近景与远景分析，为咩做这件事情为咩这样去设计等等。希望工程师能认可他即将做的事情是有价值的，值得为之而努力的。为接下来PM与工程师的沟通做好铺垫。
月会上还有一个环节，详细分析本月发生的所有数据，尤其是最近发布的新功能的数据。这个环节也是为工程师准备的，使他们了解自己的工作能产生多少实际效果。
至于月会上送出的新功能礼品(以前讲过许多次)，最开始是为工程师专设的彩蛋，再后来才将PM与运营包括了进来。我得承认自己对工程师偏心眼，因为有信心能激励PM与运营，却出于沟通深度不足，需要借助更多的手段来激励工程师投入项目。
项目任务分两种，大版本与小模块。对于大版本，在基本框架定下来之后，PM提前向工程师讲解，听取技术视角对设计方向的建议。整个设计过程中还会反复讨论三五次，为技术上的合理性征求意见。小模块则在策划案基本敲定之后，与工程师共同确认一次，视觉稿出来后再通报一次。(所以PM与工程师坐得近是很有必要的)
我曾经在部门月会上公开承诺说，任何一个需求，只要工程师认为是不合理的，都可以停下来不做。直到PM能说服工程师为止。如果死活谈不下来，才由我和技术经理出面来协调。强硬要求服从的情况在我这里基本上没有，被工程师说服倒是时有发生，按工程师提出的意见来改方案。我也常常跟PM讲，小分歧你们都听工程师的，没有必要坚持己见。你让他爽一点，开发速度就快一点，大家都获益。再说你多听听技术伙伴的意见有什么不好呢？帮助你转换思考的角度，共同找到提高开发效率的方法。
最后方案定下来了，PM说OK，工程师也觉得方向大致没错，细节基本合理；进度方面则由工程师进行评估。PM觉得时间太长接受不了，再找到我和技术经理一起商量，看是分阶段砍需求呢，还是加把力加点班。除了极少数紧急修复任务外，不会由PM单方面确定开发时间安排。包括一系列任务的优先级安排，也由PM先提草案，工程师根据开发情况来调整顺序，再共同确认。
在PM提出需求的整个流程里，始终在进行不断的协商，保证工程师对任务是理解并且接受的，不会出现抗拒，或者是麻木的心态。如果遇到突发性的需求变更，更加会向工程师反复解释，请求谅解，因为浪费了他们的工作成果而心存歉意。为此而花费的时间对比更高的开发效率，稳赚不赔。虽说具体协作时还有一些不到位的地方，但态度总归是好的，基本的效果也是有的。
当然，这套流程的实施得具备两个前提。第一是有稳定的团队，如果变成提单协作，这个月一起干下个月分道扬镳，那就不可能实现共同的项目归属感。第二是工程师的个人素质基本靠谱，沟通顺畅；尤其是技术经理可以服众，协调好分歧而不护短。比如说一个功能能不能做，至少开发多久，我和PM都搞不掂，主要靠技术经理来做最终判断；如果出现开发过程中的失误，或是不按照约定好的方案进行开发，则由技术经理进行处罚。我对开发组更多作行政管理，全靠这位技术核心伙伴来负责业务管理，他也会更深入地参与到产品的结构设计，任务规划里来。
这样做，也就撇开了把工程师当工具对待的嫌疑。我觉得把任何同事当工具都挺可耻。怎样才算是伙伴呢？比如交流必要的信息，理解对方；比如能站在对方立场去换位思考；比如多一点点鼓励与帮助。
换个角度看，我这边曾经出现过由工程师来提出大致构思，PM认可并负责细节设计，再由这位工程师来实现的情况。结果皆大欢喜。我后来多次在月会或别的场合征求工程师的创意，换一换视角，引入新鲜的想法与灵感。即便想法不一致，也会非常温和地解释反对原因，绝不可能一口否决。唯恐工程师们默不出声闷头干活――听不到技术伙伴的意见是多大的损失啊。
今上有敕云：“科学发展观的核心是和谐发展。”