在接触了几个这样的项目之后，感觉这种配合模式比较难达到非常和谐的地步，项目经理从项目立项开始跟进，到项目上线，其要保证项目不被delay;产品经理介入的会更早，前期用户调研，需求确认等等就已经参与了，到项目执行的过程和最终上线运营，都需要参与进去，中间如果不是敏捷开发，没有严格的迭代控制，那么需求变更不可避免，自然就会影响到项目的进度，这里就不以敏捷开发为例了，就以常见的瀑布式为例。

　　之前有写过一篇文章《如何区分产品管理与项目管理》，里面就大概讲了一下产品经理与项目经理的分工和协作，真正要严格的区分开来是比较难的，在工作过程当中都是结合的比较紧密的，拿亲身经历的实际例子来说，一个项目在立项之前，是没有项目经理的，这个过程全部都由产品经理负责，主要是要完成需求确认的过程，待到项目立项之后，一般项目经理都是开发负责人或者测试负责人，这时问题就来了。

　　1、对工作量的评估

　　产品经理一般对某个项目的上线运营是要背kpi指标的，在多长时间内上线，因此如果前期需求调研时间长了，后期就会很紧张，就会希望开发和测试加快速度，难听点就是加班;项目经理会更多的从实际工作量的角度去评估，往往一开始评估出来的工作量都让产品经理大跌眼镜，产品经理认为只要20个工作日的，项目经理说需要40个工作日，都还是保守估计，这个时候为了保证项目的按时上线，是要协商的，个人觉得这里有一个共识的问题，就是前期没有让开发人员参与需求的讨论，或者产品经理没有将需求实现的价值、意义和项目经理讲清楚，这样就会存在认识上的偏差，当为了做任务而做任务的时候，可想而知是没有什么紧迫感的，但要是从产品的角度出发，完全会是两码事。因为个人建议在进行需求讲解的时候，不要一味的只讲功能点和实现逻辑，一定要说实现的产品价值，给大家一个主人翁的共识，这样在协调工作量问题的时候会好很多，而且后续的过程当中也会顺畅很多。

　　2、对需求变更的容忍度

　　对于产品人员来说，需求变更是家常便饭，哪个产品在做的过程当中没有进行过需求变更，这个产品的不靠谱指数估计就会很高，因此对产品经理们来说，需求变更时很正常的，虽然也要控制变更的频率，太过频繁的变更就证明产品的框架结构有问题了，或者已经偏离了原来的主要方向。但开发人员不是这么认为的，当一个功能辛辛苦苦开发出来，马上接到通知说这个功能不要了，要换成另外一种，这种情况发生的次数多了，换成任何一个人都会觉得是被耍了，毕竟都是自己的成果，说不要就不要了，说改就得改了，而且变更的次数多了也会影响项目进度，如果开发负责人是项目经理的话，问题就来了。这种情况一是一定要让项目经理理解需求变更的目的及其价值所在，做好沟通 ，确保每次变更都是能让各方接受的;二是要严格控制版本，减少变更的次数和降低变更的频率，做好迭代周期的规划。

　　现在有一种新的方式来解决协作问题，那就是引入pmo来做项目经理，既不是产品经理也不是开发人员、测试人员，总之是不在产品团队里面的，只是过来管理项目的。这样有个好处是避免了项目管理的束缚，整个产品团队可以安心的做产品，但问题也很显然，第一是pmo只是来管理项目的，必然是以项目进度为重;第二是pmo不一定懂产品策略，出现问题的时候沟通比较麻烦。个人是不建议把一个项目周期掐的很死的，要控制单可以适当的根据实际情况来调整，把项目是否delay看成是一个kpi的话，会比较杯具。敏捷开发的话会稍微好一点，只有一个大周期，所有人员都是置身其中的。

　　3、对需求的理解角度

　　产品经理更多的是从业务的角度去理解去设计，而项目经理大多是从技术实现的角度来考虑，看问题的角度不一样，决定了会有很多冲突。比如产品经理在设计某个需求功能时候，认为这个功能是必备的功能，且是满足业务要求的;项目经理看了之后觉得实现的代码量巨大，就想对这个功能点进行拦腰斩，只做其中一部分，甚至建议不做，或者说会影响性能却又给不出更好的方案时提议能否暂时不做这个功能。这种情况下就会产生很大的矛盾，这种时候就需要建立一种负责制，遇到分歧的时候到底听谁的，是产品经理说了算还是项目经理说了算，理论上来说没有任何功能是技术无法实现的，应该由产品经理来评估决定最好到底要不要做这个功能。

　　中国人有个特色，无官一身轻，有点官了就要摆官架子，互联网行业还稍微好点，但大公司里还是容易滋生官僚主义，所以说小型公司适合创业适合做产品，因为没有那么多的流程约束。其实多数情况下一个项目里面都只有产品经理，个人觉得这样比较好，虽然比较难，但就不存在多头领导了，搞那么多leader，把大家都弄晕了不说，还容易出现矛盾。