07 | 关于需求变更（上）：需求背后的需求

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

谢谢二爷的文章，知己知彼，百战百胜。 —— from 某程序员

前边分析用户提出需求那段，概括来说就是用户提出的需求往往都是他真实需求的解决办法。 从（伪）心理学的角度看，我们所在的这个社会非常鄙视那种只会提问题而不提解决方案的人，因此我们习惯于在自己提出一个问题后自行思考解决方案。 即使我们在面对一个新产品时是小白用户，但潜意识也不想承认这一点，不想让别人觉得自己是一个“没用”的人，因此在提需求的时候，往往会给设计产品的人提出一个解决需求的思路。

穿透用户诉求去找到更好的产品实现方式是好坏产品经理的分水岭

打產品經理的時候，個別好心人沒能擠進去便轉而開始勸架了

“二爷，没有你这么办事儿的。” 想知道这句话对二爷的心理影响是怎么样的。

留给产品做需求的时间，经常都是很赶的，花两三天或者一周就敲定一个可以做一两个月工期的版本，然后在实现的过程中，必然就伴随着变更了。

每天奔波在各种会议中的我，真的很想静静写文档，泪目

现在的公司没有产品，通常都是需求直接丢给我（UI ）去直接出效果图，但是又不交代清楚需求，也不留足够的时间给我去思考，感觉真的是特别蛋疼。有时候跟领导讨论需求的时候想问清楚真正的需求，以便有更好的方案去实现，领导很多时候又觉得我没必要知道那么多，按照他说的去做就行了，有点憋屈。

1.二爷今天这个观点很有意思。需求变更并不是变更需求本身，而是变更需求的实现路径。确实是这样的，用户需求是相对稳定的，不可能在短时间内发生改变。我想大部分产品经理都没有对这个提出过质疑，都是张嘴闭嘴需求变更，我也是。 2.需求变更是产品经理的必修课，发生变更有各种各样的原因，主观的和客观的。如何在工作中尽可能地减少需求变更，是产品经理在职业生涯中需要持续不断摸索和学习的。 3.5问法，很不错。学习了。另外分享一个卫哲老师的「3+1需求分析法」： 3：这个需求是从哪来的，目标用户是谁，用户特征是什么；这个需求紧迫吗，有多少人有这样的需求；用户的场景是什么，他们有什么样的痛点。 1：这个问题解决后，网站的数据有没有什么变化。 以上。 十三