需求不会变更，变更的是实现

“需求变更”四个字有个不好的暗示，仿佛变更是来源于产品用户的需求变化。实则不然，从整个团队的角度看，需求变更多半其实是指“实现变更”。用户的需求通常很稳定，变更是由于产品经理对用户需求的分析出现了偏差，或满足用户需求的手段发生了调整。

挖掘需求背后的需求

对于产品经理来说，挖掘“一匹更快的马”背后真实的用户动机是最重要的基本功，不要停留在用户自己提出的所谓需求上，这些需求只是真正需求的一个线索。

这就是我在工作中经常用到的“5 问法”，所谓“5 问法”，就是针对一个问题，连续以“为什么”来自问，连问 5 次，从而追究其根本原因，找到用户背后真正的动机。
这一方法是由丰田佐吉提出的，后来被用在震古烁今的丰田模式里。在需求分析的过程中，这个方法尤其好用。

如果没有多问几个为什么，只是把需求方或用户提出的要求当作需求列表转交给开发，这就是一个产品经理的渎职，如果又因此引发了需求变更，那么产品经理受到工程师鄙视也很合理。大部分产品经理在实习期以后，就不应该再犯这样的错误了。

除此之外，关于需求变更有一个值得注意的事实：变更通常发生在产品特性上线之前，也就是需求分析结束，开发正在进行或测试正在进行的过程中。如果项目已经发布，一般再改就叫“新需求”而不是“变更”了。
那么，究竟是什么让一个产品经理在项目开发的过程中提出变更呢？

给需求分析留出时间

举个例子，如果产品经理分析需求用了两天，然后工程师接手开发六天，开发到第二天，产品经理跑来了说：“抱歉，有个小小的变更”。
这是因为分析需求的时间不够，在短时间内，产品经理的方案和逻辑没有完全想透，但为了尽快出结果，紧赶慢赶写完需求文档交给下一个阶段。
“需求分析”过程没有受到足够的重视，所以没有给足产品经理足够的时间
所以，我特别建议给前期需求分析的过程留点时间和空间，让产品经理能在自己的脑子里跟自己多较较劲，把该变的都变完，交出尽可能稳定的方案。

他们也需要安静，需要完整的时间，因为产品经理最重要的产出不是那个方案文档，而是方案本身

我在过去的工作中经常建议产品经理在完成需求分析，写好需求文档之后，把文档放下来，不去想它，做一点别的事情，等个一两天，大脑从需求的情境中脱离出一点之后再重新去读自己写的文档。通常他们都会发现或大或小的问题，我们把这个过程叫作需求文档的发酵

别忘了需求评审

千万不要你好我好大家好，一片和气。在方案交到开发阶段之前，把它挂起来先打个遍体鳞伤，否则开发到一半再变更，就只能把产品经理挂起来打个遍体鳞伤了。

讨论

1.极客时间CEO：
“需求沟通确实需要技巧。上次我的研发和产品聊着聊着就急了。

研发：我特么就不给你做这个需求
产品：这个需求有用你为啥不给做

我看着就要打起来，赶紧劝，能动手就别吵吵…

后来沟通清楚了，其实需要很小的工作量就能完成这个有效的产品特征。

把话说清楚，是产品经理的必备技能。但能说清楚的，不多
”
做一个能把话说清楚的产品经理

2.在开需求评审会之前，我一般会先把自己的产品方案给技术看一下，简单评估下可行性，做一个简单的统一看法。
再开需求评审会的时候，最大的目的是传达整个项目的目标，统一项目中的细节，然后根据会上各方的讨论结果再给需求内容做一些合理调整。最终发邮件确定方案。
需求评审会更像是将产品经理对项目的看法和目标传达给项目参与者的过程，给团队成员统一目标。