这时工程师就有意见了，觉得后续的修补太多，浪费时间，希望发布第一个版本的时候能够谨慎一些，周全一些。但这其实和“敏捷风格”是相悖的。

    我想了想，问题并不在于工程师不认可这个敏捷风格，而是不理解为什么要做这个，为什么要调整那个。我们的PM把设计案写得清晰完整，这是“提交任务”的环节，可是还漏了另一个环节，即“解释说服”的部分。

    去年看一篇介绍Facebook的文章，讲他们的PM权力很小，PM必须用自己的方案吸引住工程师，才能换得他们的投入，而工程师又必须去说动交互与视觉设计师，为这项开发提供支持。总之，如果不能说服配合你的人，在Facebook寸步难行。

    初看这篇文章时，觉得简直是PM的噩梦，后来细细一想，又大有道理。如果某个方案都不能说服自己的同伴，是否隐患多多呢？换个角度，即便方案最后被证实是错误的，当初支持过它的所有人都会共同承担责任――主要是精神上的自责，而不会互相埋怨造成内耗。

    只不过，Facebook这个管理文化还有两项大前提，轻易照搬不动。

    1、只聘请最优秀的工程师，有较高的产品素养

    2、每个员工都是自家产品的用户，感同身受，有不错的用研基础

    所以其他公司盲目学习Facebook这一套，必死无疑，但其中的道理是共通的。怎样让团队齐心协力呢？必要条件是对自己的任务有认同感。这个认同感不是靠升职加薪换来的，也不是靠请吃饭拉关系换来的，而是你必须说服他，做这个事情是有价值的，值得你花时间去弄。大到产品方向，小到交互优化，都不例外。

    每个月的月初，我会开一小时部门例会，滔滔不绝地讲近期的版本路线。每次花两三个小时来准备PPT。在我看来，在座的每一个人都是我的客户，我希望靠说服力(而不是权力)来打动他们，接受我的产品计划。在每周的策划运营例会上，在我跟策划组与运营组的单独沟通中，这种演说不断持续――虽然有点唠叨，但可以保证沟通充分，不存在对任务的抵触情绪。

PM与工程师的协作，也应该学习我这个态度。PM既不是请求工程师去做这个，更不是安排工程师去做那个，而是通过绘声绘色的说明，与工程师达成共识，我们下阶段就应该做这个做那个。

因此，我在每周四下午安排了一场30-60分钟的会议，PM与工程师参加。PM这边有一份庞大的需求总表，大约涵盖了2-3个月的开发需求，随时增补修订。然后在会议上根据优先级，对工程师讲解与讨论接下来的开发计划，并确定下周的发布内容（紧急需求除外）。对这种讨论之前其实是有要求的，但如果不予以流程化，制度化，就容易荒废掉，口号永远只是一滩糖稀屎。“提单-接单”的传统协作形式必须被“讲解-倾听-讨论”所替代。

上周我在新浪发了条微博，说产品协作的根本出路是让工程师加入设计讨论，共同确认方案，共同对结果负责。这条微博的回复很多。不少人提出，工程师哪里有这么多时间参与产品设计？又有人说，所有人都负责，相当于所有人不负责。这些都是误解。工程师只在几个关键节点（架构提出/方案确认/进度安排）参与进来，占用时间有限；而所谓“共同负责”，意思是当初你不出声反对，事后就得同甘共苦；当初你接受了这份开发计划，便不会指责PM拍脑袋瞎折腾。对产品负责到底的必然是PM，他同时还需要说服所有同伴接受自己的方案。

在我这里，这个做法是可以被执行下去的。又有人留言说，第一，沟通能力足够强的PM比较少，没有能力说服别人；第二，对产品有感觉的工程师比较少，固执的工程师却很多。他说的也是常见情况。这属于团队建设的问题，团队经验与内部磨合都支撑不了协作上的民主，但换个角度来看，这样的团队是否也很难做好产品呢？与其独裁管理，不如多花心思在招聘与培训上。

另外还有一种情况，在创业阶段，打算做点创新的事情。由于用户反馈很少，多半凭主观感觉去摸索，说服力有限，容易发生分歧。而创业最怕的就是内耗，一争执，一慢下来就完了。这时PM与工程师的合力很难形成，更不适合搞一言堂――摸索中的试错成本加重了内部矛盾。肿么办？所以牛逼的创业团队都是技术主导，带头大哥兼具工程师与PM的双重属性，自己想清楚了，挽起袖子就写代码，雌雄合体知行合一，非此不足以杀出血路。