07 | 关于需求变更（上）：需求背后的需求
下载APP
关闭
渠道合作
推荐作者
07 | 关于需求变更（上）：需求背后的需求
2017-12-05 邱岳 来自北京
《邱岳的产品手记》
课程介绍
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="1142" height="640"><rect fill-opacity="0"/></svg>)
讲述：邱岳
时长08:56大小4.10M
“唯一不变的，就是变化本身。”——斯宾塞·约翰逊
每当行业中想要黑产品经理时，首个被砸下来的罪责一定是“需求变更”，仿佛需求变更是产品经理最要命的错误，我并不这么看。所谓需求变更其实很复杂，不能一概而论，今天我们就来聊聊它。
需求不会变更，变更的是实现
“需求变更”四个字有个不好的暗示，仿佛变更是来源于产品用户的需求变化。实则不然，从整个团队的角度看，需求变更多半其实是指“实现变更”。
用户的需求通常很稳定，变更是由于产品经理对用户需求的分析出现了偏差，或满足用户需求的手段发生了调整。
比如，产品经理说需要一匹更快的马，后来换成了要汽车。在这个过程中，用户的需求一直都是“更快到达目的地”，变更的是满足需求的方式。
就像“工程师用搜索技术实现了某个查询功能，后来发现索引建立有几秒钟延迟不能满足实时查询的场景需要，又改用查数据库”的道理差不多，需求没变，实现变了而已。
挖掘需求背后的需求
对于产品经理来说，挖掘“一匹更快的马”背后真实的用户动机是最重要的基本功，不要停留在用户自己提出的所谓需求上，这些需求只是真正需求的一个线索。
有句关于产品需求挖掘的名言叫作“用户不需要 1/4 英寸的钻头，他需要的是 1/4 英寸的洞。”这句话后来又被继续演绎成更多版本，比如“用户需要的也不是 1/4 英寸的洞，而是在墙上挂一幅画”，甚至是“用户不是需要画，他需要房间的格调”等等。这些听起来像抬杠的演绎，其实就是不断探索和挖掘真正需求的过程。
这就是我在工作中经常用到的“5 问法”，所谓“5 问法”，就是针对一个问题，连续以“为什么”来自问，连问 5 次，从而追究其根本原因，找到用户背后真正的动机。
这一方法是由丰田佐吉提出的，后来被用在震古烁今的丰田模式里。在需求分析的过程中，这个方法尤其好用。
比如，做公司内部的订单系统，用户提出希望为订单添加根据最近修改时间排序的支持，你不应该直接去实现，而应该问为什么。
可能用户会说，因为每天的订单量太大，审核不完，为了防止订单过期，所以要从最久远的一份开始审核。很多产品经理到这里就结束了，但这还不够，你应该继续就这个问题问下去，比如可以问为什么订单会过期，或为什么一定要审核。
这是我经历过的一个真实案例，随着不断深入挖掘，后来发现有大量的审核工作是可以自动完成的，最终我们做了一个自动审核的功能，彻底解决了这个问题。
如果没有多问几个为什么，只是把需求方或用户提出的要求当作需求列表转交给开发，这就是一个产品经理的渎职，如果又因此引发了需求变更，那么产品经理受到工程师鄙视也很合理。大部分产品经理在实习期以后，就不应该再犯这样的错误了。
除此之外，关于需求变更有一个值得注意的事实：变更通常发生在产品特性上线之前，也就是需求分析结束，开发正在进行或测试正在进行的过程中。如果项目已经发布，一般再改就叫“新需求”而不是“变更”了。
那么，究竟是什么让一个产品经理在项目开发的过程中提出变更呢？
给需求分析留出时间
举个例子，如果产品经理分析需求用了两天，然后工程师接手开发六天，开发到第二天，产品经理跑来了说：“抱歉，有个小小的变更”。
第一个可能就是分析需求的时间不够，在短时间内，产品经理的方案和逻辑没有完全想透，但为了尽快出结果，紧赶慢赶写完需求文档交给下一个阶段。
开发接手后，产品经理坐在那儿反刍的时候，怎么想怎么觉得有问题，于是提出变更。这是因为“需求分析”过程没有受到足够的重视，所以没有给足产品经理足够的时间。
据我所知，有不少项目都是先确定发布时间，然后减去测试和开发需要的时长，反过来倒逼产品经理完成需求文档的时间点。
有意思的是，很多时候这都是产品经理自愿的，因为项目发布的第一负责人通常是产品经理自己，为了上线先插自己两刀，这是行规。他很有可能在内心鼓励自己说：“晚上熬个夜，把文档出一下，用不了多久。”
没错，写个文档是用不了多久，但思考是需要时间的。在整个项目进行过程里，变更出现越早代价就会越小。
如果变更只出现在产品经理脑子里，对团队的伤害其实是最小的，如果都测试完毕，临部署上线的时候突然变更方案，基本上，团队所有的角色都要付出相应的代价。
所以，我特别建议给前期需求分析的过程留点时间和空间，让产品经理能在自己的脑子里跟自己多较较劲，把该变的都变完，交出尽可能稳定的方案。
经常看到行业里有人倡议不要打扰正在写代码的工程师，从没见过说别打扰产品经理的（只有个别好心人呼吁别打产品经理，比心）。其实他们也需要安静，需要完整的时间，因为产品经理最重要的产出不是那个方案文档，而是方案本身，生产方案也同样是一项消耗性的脑力劳动。
另外，我在过去的工作中经常建议产品经理在完成需求分析，写好需求文档之后，把文档放下来，不去想它，做一点别的事情，等个一两天，大脑从需求的情境中脱离出一点之后再重新去读自己写的文档。通常他们都会发现或大或小的问题，我们把这个过程叫作需求文档的发酵。
很多情况下，你需要将自己从需求中拽出来，换一个更冷静的状态去重新审视自己的需求分析。没有比把文档放到那里搁置几天更有效的办法了。
别忘了需求评审
还有一件重要的事情，就是建议增加需求评审。不一定是架上投影仪开大会，找几个人到茶水间聊一会儿也行。尽可能引入外力，比如用户代表、运营、开发、测试、老板等等，千万不要你好我好大家好，一片和气。
在方案交到开发阶段之前，把它挂起来先打个遍体鳞伤，否则开发到一半再变更，就只能把产品经理挂起来打个遍体鳞伤了。
我有一次中途接手别人的需求，需求评审我没有参加。然后开发兄弟们拼死拼活赶工，力保按期发布。部署上线之前，我组织各相关方做了个集中演示，结果需求方找我说其中一个核心页面有问题，要求改一下。讨论权衡再三最终还是没能扛住，决定延期。
我记得自己当时差不多是跪着去找前端团队的负责人，我说：“兄弟我对不起你…”他点着了烟半天没抽，目光看着远方，很久之后才开口，说：“二爷，没有你这么办事儿的。”那一刻我至今还记忆犹新。
事后我总结，问自己是不是不该做那次演示，先发上去再说。但后来还是说服了自己这么做是对的，因为需求分析不是我做的，我并不能很好地把握所有细节，那么把各方叫到一起做最后确认，保证在上线前把问题暴露出来，这是必要的。
虽然高压工作之后，在最后时刻出现延期非常打击团队的士气，但是没有让问题流出团队，或许也是个明智的选择。
回顾一下今天的内容，我们提到需求变更的本质是实现变更，从而引出通过不断追问挖掘需求背后需求的方法，同时建议给产品经理的需求分析留出充足的时间，最后提到了需求评审的重要性。
今天的话题并没有结束，在下次的文章中，我们会接着讨论如何利用具体的力量来提高需求评审的效率，以及如何选择变更时机等。
关于今天文章的内容，你有没有什么想要分享或讨论的？欢迎给我留言，我们一起交流。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享赞 25
提建议
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
06 | 产品案例分析 · The Guardian的文本之美
下一篇
08 | 关于需求变更（下） : 化变更于无形
精选留言(75)
池建强2017-12-05需求沟通确实需要技巧。上次我的研发和产品聊着聊着就急了。 研发：我特么就不给你做这个需求 产品：这个需求有用你为啥不给做 我看着就要打起来，赶紧劝，能动手就别吵吵… 后来沟通清楚了，其实需要很小的工作量就能完成这个有效的产品特征。 把话说清楚，是产品经理的必备技能。但能说清楚的，不多展开共 2 条评论56
Charles tong2017-12-05在做项目的过程中，在开需求评审会之前，我一般会先把自己的产品方案给技术看一下，简单评估下可行性，做一个简单的统一看法。 再开需求评审会的时候，最大的目的是传达整个项目的目标，统一项目中的细节，然后根据会上各方的讨论结果再给需求内容做一些合理调整。最终发邮件确定方案。 需求评审会更像是将产品经理对项目的看法和目标传达给项目参与者的过程，给团队成员统一目标。展开作者回复: 这也是个好办法 提高会议效率
共 2 条评论21
听天由己2017-12-05需求真的是产品经理的拦路虎，想要越过它，必须有足够的能力与方法。今天学习了几点，总结下： 一是 5 问法，这是破解需求的好办法。我们总说有一些伪需求，可能就是在前期并未做好充足的讨论与思考，碰到什么事情就一股脑地列入计划，不给自己留有一些缓冲余地，最后只能自己背锅。 二是，通过不断提问，学会给自己充分的思考空间，闭门造车永远都是最低效的方式，要真正验证假设，而且一定要快。 三是，我在现实工作中碰到的情况就是，需求评审这事其实大家没有放在心上，有些同事对业务并不熟悉，心态上还是以完成任务为主，对需求或是方案并未有足够的重视，简而言之，责任都是产品经理的。我一直在想，产品是靠团队的，一个人总有自己的局限。 不知道二爷对此有何高见？如何将大家的心态转变成为真正做产品而不是做项目？展开共 1 条评论21
宇宙全栈2017-12-05谢谢二爷的文章，知己知彼，百战百胜。 —— from 某程序员作者回复: 感谢宇宙全栈
20
Atom2017-12-05前边分析用户提出需求那段，概括来说就是用户提出的需求往往都是他真实需求的解决办法。 从（伪）心理学的角度看，我们所在的这个社会非常鄙视那种只会提问题而不提解决方案的人，因此我们习惯于在自己提出一个问题后自行思考解决方案。 即使我们在面对一个新产品时是小白用户，但潜意识也不想承认这一点，不想让别人觉得自己是一个“没用”的人，因此在提需求的时候，往往会给设计产品的人提出一个解决需求的思路。展开作者回复: 所以产品经理得从这里面去看到真正的需求
13
Ryan Feng2017-12-06穿透用户诉求去找到更好的产品实现方式是好坏产品经理的分水岭作者回复: 也是基本功
10
AthenaT🤘🏻2017-12-05打產品經理的時候，個別好心人沒能擠進去便轉而開始勸架了作者回复: 也可能在外头往里递砖头
10
陈颜俊2018-01-09关于5问，有一个说法我印象比较深刻，那就是永远别相信自己的Plan A，你一定可以想出更好的Plan B7
啊啊啊是我啊2017-12-18“二爷，没有你这么办事儿的。” 想知道这句话对二爷的心理影响是怎么样的。作者回复: 内疚了很长时间
7
蔡文渊Eric2017-12-23前公司是一个硅谷团队，当时有一个重大产品需求美国的产品团队研究和讨论了一年多才开始研发。当时国内团队大部分同事都不理解为什么美国团队一直在讨论需求迟迟不肯开发，看看国内互联网团队一周一个新功能效率翻倍。事后回顾真的很佩服产品经理能hold住，一个重大产品需求应该多花时间研究和讨论才能确定，因为需要的开发资源也是翻倍的。6
zhang2017-12-12留给产品做需求的时间，经常都是很赶的，花两三天或者一周就敲定一个可以做一两个月工期的版本，然后在实现的过程中，必然就伴随着变更了。作者回复: 唉，心痛
5
郭郭2017-12-05我居然少问了4个「为什么」。5
Hand2017-12-05每天奔波在各种会议中的我，真的很想静静写文档，泪目作者回复: 实在不行就少睡点儿…
5
田小川2018-01-07现在的公司没有产品，通常都是需求直接丢给我（UI ）去直接出效果图，但是又不交代清楚需求，也不留足够的时间给我去思考，感觉真的是特别蛋疼。有时候跟领导讨论需求的时候想问清楚真正的需求，以便有更好的方案去实现，领导很多时候又觉得我没必要知道那么多，按照他说的去做就行了，有点憋屈。作者回复: 别急，达到大家愿意跟你充分沟通之后，有些东西才能走通，循序渐进
4
时间之树2017-12-25其实，无论是需求分析出现偏差，还是需求方式进行变更，都体现了产品经理需求分析的能力。而在需求变更开始之后，考验的就是产品经理沟通和平衡能力。无论是过程中哪一环出现问题，都是产品经理的责任。虽然没有完美的产品经理，但是有不断完善自己的产品经理。4
卿宗伟2017-12-061.二爷今天这个观点很有意思。需求变更并不是变更需求本身，而是变更需求的实现路径。确实是这样的，用户需求是相对稳定的，不可能在短时间内发生改变。我想大部分产品经理都没有对这个提出过质疑，都是张嘴闭嘴需求变更，我也是。 2.需求变更是产品经理的必修课，发生变更有各种各样的原因，主观的和客观的。如何在工作中尽可能地减少需求变更，是产品经理在职业生涯中需要持续不断摸索和学习的。 3.5问法，很不错。学习了。另外分享一个卫哲老师的「3+1需求分析法」： 3：这个需求是从哪来的，目标用户是谁，用户特征是什么；这个需求紧迫吗，有多少人有这样的需求；用户的场景是什么，他们有什么样的痛点。 1：这个问题解决后，网站的数据有没有什么变化。 以上。 十三展开作者回复: 谢谢十三
共 2 条评论4
宅男丁2017-12-05评价更多集中在后面几点，也是二爷展开的较多的部分，可能是经历更多，大家也更容易形成共鸣和共识。 想分享对第一点的理解。 首先，需求是不变的，而且需求绝大多数情况终会被满足，产品解决的是其中效率和成本的问题，所以核心是找到需求，然后寻找或者建立工具去不断提高，工具可以是系统，可以是算法，也可以是人，很多情况是这几种的集合。 其次，变更的是实现，或者通俗一点，就是解决方案在变。非常同意二爷的，变更在产品经理大脑里发生是影响最小的，但是会有产品进到追求最优解决方案的自我陷阱里，忽视了对效果的追求，更好的解决方案是对处理静态的世界是ok的，但是糙快猛更长期来看更有效果。 产品的价值不是完成解决方案，而是持续满足需求。展开4
琚致远2017-12-05二爷，没你这么办事儿的😂4
菡萏如佳人2017-12-08如果产品经理能做到二爷说的50%，那就阿弥陀佛了…作者回复: 向着 100% 努力，能做到多少随缘了，佛系产品经理
3
Bonnie Mei2017-12-06感觉对不起开发。。3