ASK MO第72期 | 如何化解产品经理与项目经理的“矛盾”？

我的回答是：这种矛盾是不可化解的。

就好比你既要马跑，又要马儿不吃草。学过项目管理的都知道，项目管理铁三角：范围，成本，时间。这三者是相互制衡的。在保证基本质量的前提下，如果你的范围太大，那么要么就要增加成本，要么就要增加时间，其他两者不变是不可能的。所以项目经理这个时候要控制好产品经理的欲望。项目经理这个时候就承担了跟产品经理制衡的这样一个角色，你需要控制产品经理的欲望。

一般来说很多项目经理他是开发出身，那么他刚刚转项目经理的时候，他会面临一个问题，就是他连自己的欲望都控制不了，他希望多做一些事情，这样代表他对团队的贡献，但是其实是错误的，他如果没有控制产品的欲望，会导致最后压榨的是时间和质量。反映出来的最后结果就是项目经理做得不好。

敏捷在一定程度上可以更好地平衡，也就是说敏捷不是专注需求的数量，而是专注需求的价值。

比如：这个版本我有10个需求，在这个时间要求下，只能做满5个需求，所以我挑最有价值的5个需求来做，做完进行交付。

但是团队转敏捷之后，你能在本来完成5个需求的时间内完成10个需求，那显然是不可能的。

又不是哈利波特的魔法。

这个现象其实是在告诉你，测试人员不够，需要增加测试人员。

除此之外，你现在的处理方式，其实是有欠妥当的，“准备”这个事情，偶尔做下就好了。

现在可以做两件事情：

1、让开发去帮助测试跑跑用例。

2、有这个时间可以安排培训和学习，进行能力提升。

3、可以做一下非业务需求，比如重构。

但是我只是提个建议，最好的是你团队自己发现这个问题，自己去解决，你不如在这次迭代完成之后，做个迭代总结 ，大家认识到问题，和一起讨论出来的解决方案，才是最能被认可，最能被执行的。

PMO的职能因公司而异，准确地说是因问题而异。

如果你的公司是那种比较传统的公司，商业模式和业务都比较稳定，IT的能力比较弱，使用瀑布流程进行开发，然后又是重流程的，那么你可以建立控制型的PMO，过CMMI流程，根据公司业务建立公司流程体系，建立度量体系。

如果你的公司是属于互联网型的公司，商业模式和业务都不太稳定，IT的能力比较强，使用敏捷方法进行开发，比较轻流程的，那么你可以建立咨询型PMO，这种PMO主要是先深入团队，找到团队的问题，然后根据问题去输出解决方案和建议，帮助团队解决他们的问题，建立团队规范和指导手册。对团队执行的效果进行宣传，并把价值进行量化，让团队不断肯定PMO其存在的价值。

这样说来你其实不是scrum master，你需要参加我的敏捷实干派ACP弟子班，因为你连敏捷能干什么都还不知道，如果你的公司已经开始做敏捷了，但却没有人告诉你敏捷能干什么，你公司的敏捷转型大概率会失败。

敏捷是为了应对不确定性环境的一套方法和实践，在一些领域我们不知道怎样才是用户想要的，我们可以通过敏捷方法不断快速低成本地去试错。当然调动大家积极性也是副产品，因为在试错过程当中，我们的商业模式本身就是不稳定的，领导也不知道用户的喜好，只好赋能一线人员，让他们快速试错，探索用户喜好，让用户为其产品买单，这个调动大家积极性的方式总称：赋能。

Sprint0，一般在产品从0到1的阶段，这个时候一个迭代，主要是在做一些准备工作，比如定项目章程，做项目团建，明确产品目标和里程碑目标，进行总体架构设计，这个过程不要每次都做。

这个Sprint0并没有有形的交付物产生，所以很多团队都没有去做这个实践，都是在Sprint1的过程中完成了这些任务，所以需不需要Sprint0，不是太重要，重要的是定项目章程，做项目团建，明确产品目标和里程碑目标，进行总体架构设计，这些过程是需要有的。

敏捷实干派，就是一切都向实干看齐。躬身入局。

· · ·END· · ·