08 | 关于需求变更（下） : 化变更于无形

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

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

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

“具体”的力量

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

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

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

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

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

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

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

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

变更时机的选择

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

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

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

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

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

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

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

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

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

让团队能消化需求变更

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

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

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

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

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

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

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

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

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

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

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

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

到这里，我们关于需求变更的分享就结束了。大家有没有在自己的项目中遇到过需求变更，你又是如何处理的？如果重新回到那个场景中，你能不能找到更合适的解决方案？不妨在留言中一起讨论。

!

戳此获取你的专属海报