关于需求变更

“唯一不变的，就是变化本身。”——斯宾塞·约翰逊

每当行业中想要黑产品经理时，首个被砸下来的罪责一定是“需求变更”，仿佛需求变更是产品经理最要命的错误，我并不这么看。所谓需求变更其实很复杂，不能一概而论，今天我们就来聊聊它。

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

“需求变更”四个字有个不好的暗示，仿佛变更是来源于产品用户的需求变化。实则不然，从整个团队的角度看，需求变更多半其实是指“实现变更”。

用户的需求通常很稳定，变更是由于产品经理对用户需求的分析出现了偏差，或满足用户需求的手段发生了调整。

比如，产品经理说需要一匹更快的马，后来换成了要汽车。在这个过程中，用户的需求一直都是“更快到达目的地”，变更的是满足需求的方式。

就像“工程师用搜索技术实现了某个查询功能，后来发现索引建立有几秒钟延迟不能满足实时查询的场景需要，又改用查数据库”的道理差不多，需求没变，实现变了而已。

挖掘需求背后的需求

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

有句关于产品需求挖掘的名言叫作“用户不需要 1/4 英寸的钻头，他需要的是 1/4 英寸的洞。”这句话后来又被继续演绎成更多版本，比如“用户需要的也不是 1/4 英寸的洞，而是在墙上挂一幅画”，甚至是“用户不是需要画，他需要房间的格调”等等。这些听起来像抬杠的演绎，其实就是不断探索和挖掘真正需求的过程。

这就是我在工作中经常用到的“5 问法”，所谓“5 问法”，就是针对一个问题，连续以“为什么”来自问，连问 5 次，从而追究其根本原因，找到用户背后真正的动机。

这一方法是由丰田佐吉提出的，后来被用在震古烁今的丰田模式里。在需求分析的过程中，这个方法尤其好用。

比如，做公司内部的订单系统，用户提出希望为订单添加根据最近修改时间排序的支持，你不应该直接去实现，而应该问为什么。

可能用户会说，因为每天的订单量太大，审核不完，为了防止订单过期，所以要从最久远的一份开始审核。很多产品经理到这里就结束了，但这还不够，你应该继续就这个问题问下去，比如可以问为什么订单会过期，或为什么一定要审核。

这是我经历过的一个真实案例，随着不断深入挖掘，后来发现有大量的审核工作是可以自动完成的，最终我们做了一个自动审核的功能，彻底解决了这个问题。

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

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

那么，究竟是什么让一个产品经理在项目开发的过程中提出变更呢？

给需求分析留出时间

举个例子，如果产品经理分析需求用了两天，然后工程师接手开发六天，开发到第二天，产品经理跑来了说：“抱歉，有个小小的变更”。

第一个可能就是分析需求的时间不够，在短时间内，产品经理的方案和逻辑没有完全想透，但为了尽快出结果，紧赶慢赶写完需求文档交给下一个阶段。

开发接手后，产品经理坐在那儿反刍的时候，怎么想怎么觉得有问题，于是提出变更。这是因为“需求分析”过程没有受到足够的重视，所以没有给足产品经理足够的时间。

据我所知，有不少项目都是先确定发布时间，然后减去测试和开发需要的时长，反过来倒逼产品经理完成需求文档的时间点。

有意思的是，很多时候这都是产品经理自愿的，因为项目发布的第一负责人通常是产品经理自己，为了上线先插自己两刀，这是行规。他很有可能在内心鼓励自己说：“晚上熬个夜，把文档出一下，用不了多久。”

没错，写个文档是用不了多久，但思考是需要时间的。在整个项目进行过程里，变更出现越早代价就会越小。

如果变更只出现在产品经理脑子里，对团队的伤害其实是最小的，如果都测试完毕，临部署上线的时候突然变更方案，基本上，团队所有的角色都要付出相应的代价。

所以，我特别建议给前期需求分析的过程留点时间和空间，让产品经理能在自己的脑子里跟自己多较较劲，把该变的都变完，交出尽可能稳定的方案。

经常看到行业里有人倡议不要打扰正在写代码的工程师，从没见过说别打扰产品经理的（只有个别好心人呼吁别打产品经理，比心）。其实他们也需要安静，需要完整的时间，因为产品经理最重要的产出不是那个方案文档，而是方案本身，生产方案也同样是一项消耗性的脑力劳动。

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

很多情况下，你需要将自己从需求中拽出来，换一个更冷静的状态去重新审视自己的需求分析。没有比把文档放到那里搁置几天更有效的办法了。

别忘了需求评审

还有一件重要的事情，就是建议增加需求评审。不一定是架上投影仪开大会，找几个人到茶水间聊一会儿也行。尽可能引入外力，比如用户代表、运营、开发、测试、老板等等，千万不要你好我好大家好，一片和气。

在方案交到开发阶段之前，把它挂起来先打个遍体鳞伤，否则开发到一半再变更，就只能把产品经理挂起来打个遍体鳞伤了。

我有一次中途接手别人的需求，需求评审我没有参加。然后开发兄弟们拼死拼活赶工，力保按期发布。部署上线之前，我组织各相关方做了个集中演示，结果需求方找我说其中一个核心页面有问题，要求改一下。讨论权衡再三最终还是没能扛住，决定延期。

我记得自己当时差不多是跪着去找前端团队的负责人，我说：“兄弟我对不起你…”他点着了烟半天没抽，目光看着远方，很久之后才开口，说：“二爷，没有你这么办事儿的。”那一刻我至今还记忆犹新。

事后我总结，问自己是不是不该做那次演示，先发上去再说。但后来还是说服了自己这么做是对的，因为需求分析不是我做的，我并不能很好地把握所有细节，那么把各方叫到一起做最后确认，保证在上线前把问题暴露出来，这是必要的。

虽然高压工作之后，在最后时刻出现延期非常打击团队的士气，但是没有让问题流出团队，或许也是个明智的选择。

回顾一下今天的内容，我们提到需求变更的本质是实现变更，从而引出通过不断追问挖掘需求背后需求的方法，同时建议给产品经理的需求分析留出充足的时间，最后提到了需求评审

“拥抱变化。”——阿里巴巴价值观之一

上面的内容，我聊到了需求变更的原因，以及通过引入需求评审来尽可能避免需求变更，并在文章的最后提到了一次并不成功的项目经历。

这次项目已经根据项目流程开过了需求评审会，却没有在这个环节暴露问题，直到临发布的最后一刻才引入了变更。那么，怎样改进需求评审才能避免未来可能的变更呢？

“具体”的力量（产品需求要尽可能具体，最好做一个与实际情况没有太大差异的Demo做评审）

大部分的需求评审会都是过场，大家下面玩玩手机，产品经理在上面对着需求文档读一遍，再开开心心散会，除了浪费了时间，什么用都没有。

这里最大的问题不是参会的人员不负责任，而是需求评审时的方案不够“具体”。

我曾听说在微信团队里，不少产品在做出来之后，需要先交给张小龙上手体验一下之后才决定生死。因为只有实际使用才能作出更准确的判断，还听说有不少东西已经做出来了，但没有通过实际使用测试，所以一直压着没能发布。

我想，或许你也有同感，一个东西画在线框图上总是觉得很远，只有在指尖动一下才能有真切的体会和判断。

所以对一些关键性的特性，在资源配置合理的情况下，尽可能做一个与实际情况没太大差异的 Demo 来做评审。数据可以是假的，架构可以是假的，但看起来和用起来要尽量保真。

我记得以前有一次观摩一场游戏 Demo 制作比赛，团队在上面试玩展示，游戏角色在地图上能跑能跳，我特别不解地问旁边人：“这不都做好了吗，为啥还要参加比赛拿投资做开发？”他告诉我，虽然这看起来很完整了，其实后面都是空壳，大头还没开始呢。

在此之后，我经常提醒自己，对于重要的功能也要尽可能在前期把 Demo 做得具体。最好是动态的，让评审的人可以有真切的体验，把可能的问题都尽早暴露出来。有很多工具可以做到这一点，重一点的 Axure、轻一点的墨刀。如果实在不想学，用 PowerPoint 和 Keynote 也可以。

哪怕没有做成动态的，只是一张张截图，在评审的时候你也可以通过讲故事的方法让它变得具体。比如你可以展示一个界面，边引导大家边说：“现在我是一个从朋友圈打开 xx 的用户，我看到的页面是这个样子。”——这样代入具体场景，才能让大家产生真感觉。

变更时机的选择

如果变更在所难免，时机选择就很重要，并不是所有变更都“越早越好”，而是要平衡收益和成本。

最好的变更发生在需求分析过程中，在产品经理脑子里，变更发生多少次都没关系，基本是无害的，所以刚才说要尽可能给产品经理留出足够多的时间，让他先自己跟自己打一架，把方案尽可能想完整。

第二好的时机是在需求文档结束，工程师接手前，这是的修改可能会造成需求分析延期，但因为需求分析主要是通过脑子完成，所以这里返工的伤害并不大，需求评审也是这个作用。

在工程师接手后，情况会变得有点复杂，这时的变更就会产生实际的开发成本了，有的变更很小，比如文案之类的，随时发现随时提，提的同时记得改掉文档描述。

稍微大一点的功能，则最好在发现变更后就立即跟开发沟通，去判断合适的变更时机，有时候工程师还没有做到这一部分，那就不会产生什么额外成本，有时候工程师已经做完了，你要比对一下变更的优先级和可能带来的延期再做决定。

如果你的项目组里有专职的 QA，这时候最好也让 QA 参与进来。如果涉及流程和架构上的重大变更，更要立刻与整个项目组沟通，有可能连设计都要推翻重做，这种情况挨骂是肯定的，态度好点儿，可能可以躲一顿打。

如果项目基本完成开发，箭在弦上准备发布了，那对于变更一定要更加慎重，这时的态度是应该是能不变就不变，可以先上线，通过运营的手段稳一下线上，然后尽快迭代做修改。在这个节骨眼上发生重大变更基本就可以领盒饭走人了。

我在职业生涯里遇到一次特别大的临发布的变更，是因为不可抗力造成的。那个项目涉及一百多人，我当时头皮都是麻的，跟人说话甚至都有些口吃。

总之，原则就是如果开发接手后有变更的想法，一定尽快跟工程师沟通，不要自己去猜测成本，而是让开发去做判断，然后再综合沉没成本和额外增加的成本去做评估。

让团队能消化需求变更

虽然大家本能上都讨厌需求变更，但我们永远都不可能彻底杜绝需求变更，更何况我认为有时需求变更也有积极意义。因为变更是响应变化，在互联网行业里，每天刀光剑影，瞬息万变，市场上发生的事情传递到产品和服务上，越快越好。

这个传递过程需要市场行销人员和产品经理的敏感，也需要工程师团队的宽容。如果整个团队抗拒需求变更，甚至建立流程对抗需求变更，久而久之就会越来越不敏感。

我体验过一个叫作“需求基线”的环节，就是需求确认结束以后大家签字画押，承诺绝对不变，连文档的编辑权限都封存，然后开发才接手，所有需求变更都必须审批到高管，启动一个冗长的评审程序。

这个制度导致的直接结果就是大家开始互相推诿，然后文档变得极其庞杂，效率降低，需求冻结以后，即便发现了问题和错误大家也不乐意提，就眼看着错的做出来了以后再说，整个产品线的节奏越来越慢，士气很快就磨没了。

没过多久，这些问题很快有了民间解法，产品经理和工程师在半夜的烧烤摊上把酒言欢，沟通需求变更，产品把变更的内容私下发给工程师，工程师直接改，等项目结束文档冻结解除之后再去改文档。

项目经理睁一只眼闭一只眼，工程师继续调侃这帮产品经理天天变，产品经理自嘲两句，然后咣咣请客吃夜宵，团队士气却一点点回来了。

后来大家慢慢意识到，这个本意用来限制甲乙方权责的流程不该在互联网公司中采用，也就逐渐废掉了。

产品经理脸皮虽然厚，但也是肉做的。如果整个团队都抗拒变更，一出现变更都恨不得把产品经理点了，他们也会慢慢变得保守，变得犹豫拖沓，最终伤害的是整个团队的利益。

尤其在互联网行业，变化是永恒的，你不可能规划好路线一帆风顺，你总要随时准备好用最快的速度追击或躲闪，这才是求胜的不二法门。

记得多年前，我在某次开发过程中又一次变更了需求，于是我主动找到对应开发负责人那里“自首”，我扭捏地说：“不好意思啊兄弟，又变更了。”

他抬头看了我一眼，轻描淡写地说：“正常，不怪你，还是要怪我们自己做得不够快。如果已经做完了，你这就是一个新需求，而不是变更了。”

我喜欢跟这样的硬汉合作。