产品经理和项目经理的分工与合作，真的很难严格区分，在工作过程中紧密结合，以实际经验为例，项目前没有项目经理，过程由产品经理负责，主要是完成需求确认过程，项目后，一般项目经理是开发或测试负责人，然后问题来了。

这个问题肯定会遇到，更大的项目将指定另一个项目经理来协助产品经理，以确保项目最终在线，这种情况在大公司很常见，小公司不会说，否则如何抱怨产品经理。在接触了几个这样的项目后，我觉得这种合作模式很难达到一个非常和谐的程度。项目经理从项目审批开始跟进项目，到项目在线，以确保项目允许delay；产品经理干预较早，早期用户研究、需求确认等已参与，到项目实施过程和最终在线运营，需要参与，如果不敏捷开发，没有严格的迭代控制，需求变化不可避免，自然会影响项目进度，这里不以敏捷开发为例，以普通瀑布为例。

1、评估工作量

一般来说，产品经理应该背诵某个项目的在线运营KPI指标，在线时间，所以如果早期需求研究时间长，后期会非常紧张，希望加快开发和测试，难点是加班；项目经理会从实际工作量的角度进行更多的评估，通常一开始评估的工作量会让产品经理感到惊讶，产品经理认为，只要20个工作日，项目经理说需要40个工作日，仍然保守估计，此时，为了确保项目按时上线，需要协商，我个人认为这里有一个共识问题，也就是说，在早期阶段，开发人员没有参与需求的讨论，或者产品经理没有解释需求实现的价值、意义和项目经理，所以会有理解上的偏差，当你为了做任务而做任务时，你可以想象没有紧迫感，但如果从产品的角度来看，这将是完全不同的事情。因为个人建议在解释需求时，不要盲目地只解释功能点和实现的逻辑点，我们必须说，在协调工作量的过程中会有很多的共识，所以在协调工作量问题的过程中会很好。

2、理解需求的角度

产品经理更多的是从业务的角度来理解和设计，而大多数项目经理都是从技术实现的角度来考虑的。从不同的角度来看，会有很多冲突。例如，当产品经理设计需求功能时，认为该功能是必要的功能，满足业务要求；项目经理觉得代码量巨大，想阻止功能点，只做其中一部分，甚至建议不做，或者会影响性能，但不能给出更好的解决方案，建议暂时不做功能。在这种情况下，会有很大的矛盾，这次你需要建立一个责任制，听谁，是产品经理还是项目经理，理论上没有任何功能是技术无法实现的，应该由产品经理评估决定是否最好做这个功能。

3、容忍需求变化

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

保每次变更都是能让各方接受的；二是要严格控制版本，减少变更的次数和降低变更的频率，做好迭代周期的规划。

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

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