分享人:雷侨
1.需求不会变，变更的是实现
2.挖掘需求背后的需求
3.给需求分析留出时间
4.变更时机的选择
5.让团队能消化需求变更
1.需求不会变，变更的是实现
很多时候需求变更好像是用户的需求发生了变化导致需求变更，其实不然，从整个团队的角度看，需求变更多半其实是指“实现变更”，实现需求的方式发生了变化。
用户的需求通常很稳定，需求变更通常是由于由于产品经理对用户需求的分析出现了偏差，或满足用户需求的手段发生了调整。
比如，产品经理说需要一匹更快的马，后来换成了要汽车。在这个过程中，用户的需求一直都是“更快到达目的地”，变更的是实现需求的方式。
2.挖掘需求背后的需求
对于产品经理来说，挖掘“一匹更快的马”背后真实的用户动机是最重要的基本功，不要停留在用户自己提出的所谓需求上，这些需求只是真正需求的一个线索。
1.观察用户的行为
2.通过真实的经历去挖掘
3.观察行业运作方式
4.五问法
5问法
所谓“5 问法”，就是针对一个问题，连续以“为什么”来提问，连问 5 次，从而追究其根本原因，找到用户背后真正的动机。这一方法是由丰田佐吉提出的，后来被用在丰田模式里。
如古话所言:打破砂锅问到底。
比如，做公司内部的订单系统，用户提出希望为订单添加根据最近修改时间排序的功能，作为产品经理不应该直接就去实现这个需求，而应该问用户为什么需要这个功能。
可能用户会说，因为每天的订单量太大，审核不完，为了防止订单过期，所以要从最久远的一份开始审核。很多产品经理到这里就结束了，但这还不够，你应该继续就这个问题问下去，比如可以问为什么订单会过期，或为什么一定要审核。
随着不断深入挖掘，后来发现有大量的审核工作是可以自动完成的，最终做了一个自动审核的功能，彻底解决了这个问题。
所以产品经理需要多问几个为什么，不要只是把需求方或用户提出的要求当作需求列表转交给开发。如果因此引发需求变更更是对团队的不负责任，同时产品经理更会受到开发人员的鄙视。
3.给需求分析留出时间
需求变更通常发生在产品功能上线之前，也就是需求分析结束，开发正在进行或测试正在进行的过程中。如果项目已经发布，一般再进行改动就叫“新需求”而不是“变更”了。那么，究竟是什么导致产品经理在项目开发的过程中提出变更呢？
如果产品经理分析需求用了两天，然后工程师接手开发六天，开发到第二天，产品经理跑来了说：“抱歉，有个小小的变更”。
第一个可能就是产品经理分析需求的时间不够，在短时间内，产品经理的方案和逻辑没有完全想透，但为了尽快出结果，紧赶慢赶的写完需求文档交给下一个阶段。
开发接手后，产品经理重新审视需求文档时，越想越觉得有问题，于是提出变更。因为“需求分析”过程没有受到足够的重视，没有给足够的时间进行需求分析
所以，产品经理需要给前期需求分析的过程留点时间和空间，让产品经理能在自己的脑子里跟自己多较较劲，把该变的需求都变完，交出尽可能稳定的方案。
经常看到行业里有人倡议不要打扰正在写代码的工程师，其实产品经理写需求文档的产品经理也需要安静，需要完整的时间，因为产品经理最重要的产出不是那个方案文档，而是方案本身，生产方案也同样是一项消耗性的脑力劳动。
建议：让需求文档发酵
产品经理在完成需求分析，写好需求文档之后，把文档放下来，不去想它，做一点别的事情，等个一两天，将自己从需求中拽出来，换一个更冷静的状态去重新审视自己的需求分析。让大脑从需求的情境中脱离出一点之后再重新去读自己写的需求文档。
4.变更时机的选择
如果变更在所难免，时机选择就很重要，并不是所有变更都“越早越好”，而是要综合平衡收益和成本。
最好的变更时机是在需求分析的过程中，这个时候在产品经理的脑子里，变更发生多少次都没关系，基本是无害的，所以产品经理要尽可能给需求分析留出足够多的时间，把方案尽可能想完整。
第二好的变更时机是在需求文档结束，工程师接手前，但这时的需求修改可能会造成需求分析的延期，但因为需求分析主要是通过脑子完成，并未投入实际开发，所以这里返工的伤害并不大，需求评审也是这个作用。
在工程师接手后，情况会变得有点复杂，这时的变更就会产生实际的开发成本了，有的变更很小，比如文案之类的，随时发现可以随时提，提的同时记得改掉文档描述。影响也不会太大。
稍微大一点的功能，则最好在发现需要变更后就立即跟开发沟通，去判断合适的变更时机，有时候工程师还没有做到这一部分，那就不会产生什么额外成本，有时候工程师已经做完了，就需要比对一下变更的优先级和可能带来的延期风险再做决定。
如果项目基本完成开发，箭在弦上准备发布了，那对于变更一定要更加慎重，这时的态度是应该是能不变就不变，可以先上线，通过运营的手段稳一下线上，然后尽快迭代做修改。在这个节骨眼上发生重大变更基本上对产品经理来说算是重大事故了。
需求变更的原则就是如果开发接手后有变更的想法，一定尽快跟工程师沟通，不要自己去猜测成本，而是让开发去做判断，然后再综合沉没成本和额外增加的成本去做评估。
5.让团队能消化需求变更
虽然大家本能上都讨厌需求变更，但永远都不可能彻底杜绝需求变更，更何况有时需求变更也有积极意义。因为变更是响应市场变化的提现，在互联网行业里，竞争激烈，瞬息万变，市场上发生的事情传递到产品和服务上，越快越好。
这个传递过程需要产品经理对市场动态的敏锐嗅觉，也需要工程师团队的理解和宽容。如果整个团队都抗拒变更，一出现变更都恨不得手撕产品经理，那么产品经理会慢慢变得保守，变得犹豫拖沓，最终伤害的是整个团队的利益。
“唯一不变的，就是变化本身。”——斯宾塞•约翰逊
By:雷侨