浅谈项目经理与产品经理的协作

　　浅谈项目经理与产品经理的协作，南京PMP项目管理培训，小编与您分享

　　1、对工作量的评估

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

　　2、对需求的理解角度

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

　　3、对需求变更的容忍度

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