2个策略，应对临时需求变更

　　频繁的需求变更对团队和产品都是巨大的消耗和打击，作为产品经理，如何让团队能够相对轻松的应对变更？
　　大家好，我是白白。产品经理在实际工作中会遇到很多坑，有些是与程序员的，有些是与老板的。临时需求变更以及需求沟通不畅是产品经理界普遍存在的问题。
　　无论是B端的产品经理还是C端的产品经理，矛盾对象主要是两类人：一个是程序员，另一个是老板或者甲方。
　　有两类问题发生的最为普遍。第一个类是程序员与产品经理对需求理解不一致而产生的矛盾，这种情况发展的主要特征就是“相互甩锅”，第二类是临时的需求变更，特别是对于老板的临床加需求显得非常无奈。
　　本文只是总结一下作者工作中的一些经验，在不同的公司由不同的应对方式，大家可以抓住中心思想灵活应对。这两个策略在作者公司已经施行多年，取得了比较好的效果。
　　一、三次评审策略
　　由于专业知识不同，对事物认知体系不同总会产生出多多少少的沟通障碍。有些产品经理认为非常简单的改动，往往会导致程序员吐槽。在产品demo开发完成之后，也可能会因为bug不断而被产品经理吐槽，总之，产品经理与程序员的沟通已经在业界讨论了不下10年之久。
　　在笔者的公司，这种情况也经常发生，对于产品经理与程序员间的交流问题解决办法分为2个方面。
　　第一个方面是自我约束
　　自我约束是指双方在交流时每句话都需要谨言慎行，必须经过认真的思考之后才能阐述。
　　产品经理提需求前需要认真思考，程序员提出质疑时前也需要认真思考。双方都需要对自己的言论负责，只有经过认真思考后表达的观点才能减少冲突。
　　可惜的是，自我约束只是一个建议，或者说是一项要求，它很难用制度来规范化，所以也就自然不好管理。
　　第二个方面是通过制度来管理双方的交流问题
　　三次评审机制可以减少产品经理与程序员的沟通不畅，这个机制是笔者在公司中长期推动使用，并取得了良好的效果。
　　一般来讲，产品规划至少提前3个版本或更多，PRD至少提前2个版本。假设在产品1。3上线的时候，可以进行1。5版本PRD的评审与技术预估，v1。5版本的PRD需要进行三次评审。
　　第一次评审主要沟通需求，需要产品经理进行详尽的PRD讲解，开发工程师从技术角度可以提出各种问题。产品经理无法解答的要一一记录在案，会后继续思考完善。
　　第二次评审产品经理需要回答上次开发工程师提出的疑问或给出的修改建议，不做出修改的阐述坚持理由。
　　第三次评审需要解决所有问题，双方达成一致准备开发。三次评审机制必须在1。4版本上线前完成，而且每次需要谨慎对待，避免把责任推到下一次会议上。
　　图1三次评审机制流程
　　简而言之，“三次评审”是通过双方的多次对话，使沟通障碍降低到最小。三次评审之时间可以间隔很短，只是给双方预留时间来消化对方的信息，在经过自己的思考加工成自己的内容予以表达。
　　二、总裁特权策略
　　产品经理直接与老板沟通，经常听到的一句话就是“XXX，来一下，我这有个需求，这个版本马上就要”。产品经理此时肯定是十万头神兽在心头奔过，无论是否是敏捷开发，无论多么快速的产品迭代，临时加需求都会带来不可预估的工作量。如果功能简单还好，如果涉及复杂逻辑，那真是欲哭无泪。
　　笔者认为临时加需求本身是合理，谁叫你不是老板，但是这种任意更改的行为需要付出代价。所以，笔者在公司中有提倡建设了分级特权制度。
　　分级特权制度在于提前预留buffer给所要加的功能，不过并不是每个人都有。
　　在创业公司中，成为“CEO特权”，通常每一个月有3次机会可以增加需求：第一次免费使用，第二次使用扣除3000工资，第三次使用扣除5000工资，更多的变更原则上是可以拒绝的。
　　如果在大厂，由所在事业部总经理最终背锅。该制度在于让所有变更都具有代价，从而谨言慎行。在创业公司或中型公司中，该制度较好实现。由于与工资挂钩，在一些大厂并不容易实现。该制度实现并不容易，在笔者公司中也遇到层层阻力。但是制度就是用来约束人的，如果高层都不遵守，公司更难以成体系。
　　在产品经理的世界中，很有很多坑需要去躲避。不过以后你会感谢这些“坑”，它给你带来了谦卑，让你懂得做事留有余地，也让你懂得了忍耐克己。