08 关于需求变更（下） ： 化变更于无形
“拥抱变化。”——阿里巴巴价值观之一
上一次的文章中，我聊到了需求变更的原因，以及通过引入需求评审来尽可能避免需求变更，并在文章的最后提到了一次并不成功的项目经历。
这次项目已经根据项目流程开过了需求评审会，却没有在这个环节暴露问题，直到临发布的最后一刻才引入了变更。那么，怎样改进需求评审才能避免未来可能的变更呢？
“具体”的力量
大部分的需求评审会都是过场，大家下面玩玩手机，产品经理在上面对着需求文档读一遍，再开开心心散会，除了浪费了时间，什么用都没有。
这里最大的问题不是参会的人员不负责任，而是需求评审时的方案不够“具体”。
我曾听说在微信团队里，不少产品在做出来之后，需要先交给张小龙上手体验一下之后才决定生死。因为只有实际使用才能作出更准确的判断，还听说有不少东西已经做出来了，但没有通过实际使用测试，所以一直压着没能发布。
我想，或许你也有同感，一个东西画在线框图上总是觉得很远，只有在指尖动一下才能有真切的体会和判断。
所以对一些关键性的特性，在资源配置合理的情况下，尽可能做一个与实际情况没太大差异的 Demo 来做评审。数据可以是假的，架构可以是假的，但看起来和用起来要尽量保真。
我记得以前有一次观摩一场游戏 Demo 制作比赛，团队在上面试玩展示，游戏角色在地图上能跑能跳，我特别不解地问旁边人：“这不都做好了吗，为啥还要参加比赛拿投资做开发？”他告诉我，虽然这看起来很完整了，其实后面都是空壳，大头还没开始呢。
在此之后，我经常提醒自己，对于重要的功能也要尽可能在前期把 Demo 做得具体。最好是动态的，让评审的人可以有真切的体验，把可能的问题都尽早暴露出来。有很多工具可以做到这一点，重一点的 Axure、轻一点的墨刀。如果实在不想学，用 PowerPoint 和 Keynote 也可以。
哪怕没有做成动态的，只是一张张截图，在评审的时候你也可以通过讲故事的方法让它变得具体。比如你可以展示一个界面，边引导大家边说：“现在我是一个从朋友圈打开 xx 的用户，我看到的页面是这个样子。”——这样代入具体场景，才能让大家产生真感觉。
变更时机的选择
如果变更在所难免，时机选择就很重要，并不是所有变更都“越早越好”，而是要平衡收益和成本。
最好的变更发生在需求分析过程中，在产品经理脑子里，变更发生多少次都没关系，基本是无害的，所以刚才说要尽可能给产品经理留出足够多的时间，让他先自己跟自己打一架，把方案尽可能想完整。
第二好的时机是在需求文档结束，工程师接手前，这是的修改可能会造成需求分析延期，但因为需求分析主要是通过脑子完成，所以这里返工的伤害并不大，需求评审也是这个作用。
在工程师接手后，情况会变得有点复杂，这时的变更就会产生实际的开发成本了，有的变更很小，比如文案之类的，随时发现随时提，提的同时记得改掉文档描述。
稍微大一点的功能，则最好在发现变更后就立即跟开发沟通，去判断合适的变更时机，有时候工程师还没有做到这一部分，那就不会产生什么额外成本，有时候工程师已经做完了，你要比对一下变更的优先级和可能带来的延期再做决定。
如果你的项目组里有专职的 QA，这时候最好也让 QA 参与进来。如果涉及流程和架构上的重大变更，更要立刻与整个项目组沟通，有可能连设计都要推翻重做，这种情况挨骂是肯定的，态度好点儿，可能可以躲一顿打。
如果项目基本完成开发，箭在弦上准备发布了，那对于变更一定要更加慎重，这时的态度是应该是能不变就不变，可以先上线，通过运营的手段稳一下线上，然后尽快迭代做修改。在这个节骨眼上发生重大变更基本就可以领盒饭走人了。
我在职业生涯里遇到一次特别大的临发布的变更，是因为不可抗力造成的。那个项目涉及一百多人，我当时头皮都是麻的，跟人说话甚至都有些口吃。
总之，原则就是如果开发接手后有变更的想法，一定尽快跟工程师沟通，不要自己去猜测成本，而是让开发去做判断，然后再综合沉没成本和额外增加的成本去做评估。
让团队能消化需求变更
虽然大家本能上都讨厌需求变更，但我们永远都不可能彻底杜绝需求变更，更何况我认为有时需求变更也有积极意义。因为变更是响应变化，在互联网行业里，每天刀光剑影，瞬息万变，市场上发生的事情传递到产品和服务上，越快越好。
这个传递过程需要市场行销人员和产品经理的敏感，也需要工程师团队的宽容。如果整个团队抗拒需求变更，甚至建立流程对抗需求变更，久而久之就会越来越不敏感。
我体验过一个叫作“需求基线”的环节，就是需求确认结束以后大家签字画押，承诺绝对不变，连文档的编辑权限都封存，然后开发才接手，所有需求变更都必须审批到高管，启动一个冗长的评审程序。
这个制度导致的直接结果就是大家开始互相推诿，然后文档变得极其庞杂，效率降低，需求冻结以后，即便发现了问题和错误大家也不乐意提，就眼看着错的做出来了以后再说，整个产品线的节奏越来越慢，士气很快就磨没了。
没过多久，这些问题很快有了民间解法，产品经理和工程师在半夜的烧烤摊上把酒言欢，沟通需求变更，产品把变更的内容私下发给工程师，工程师直接改，等项目结束文档冻结解除之后再去改文档。
项目经理睁一只眼闭一只眼，工程师继续调侃这帮产品经理天天变，产品经理自嘲两句，然后咣咣请客吃夜宵，团队士气却一点点回来了。
后来大家慢慢意识到，这个本意用来限制甲乙方权责的流程不该在互联网公司中采用，也就逐渐废掉了。
产品经理脸皮虽然厚，但也是肉做的。如果整个团队都抗拒变更，一出现变更都恨不得把产品经理点了，他们也会慢慢变得保守，变得犹豫拖沓，最终伤害的是整个团队的利益。
尤其在互联网行业，变化是永恒的，你不可能规划好路线一帆风顺，你总要随时准备好用最快的速度追击或躲闪，这才是求胜的不二法门。
记得多年前，我在某次开发过程中又一次变更了需求，于是我主动找到对应开发负责人那里“自首”，我扭捏地说：“不好意思啊兄弟，又变更了。”
他抬头看了我一眼，轻描淡写地说：“正常，不怪你，还是要怪我们自己做得不够快。如果已经做完了，你这就是一个新需求，而不是变更了。”
我喜欢跟这样的硬汉合作。
到这里，我们关于需求变更的分享就结束了。大家有没有在自己的项目中遇到过需求变更，你又是如何处理的？如果重新回到那个场景中，你能不能找到更合适的解决方案？不妨在留言中一起讨论。
- 听天由己 👍（11） 💬（0）
最近就遇上了需求变更，是在项目开发过程中发生的，早先的需求文档讨论都已确认，可在真正开发过程中却发现因为数据结构与真实性考虑，将原有流程重新拆分。此时面临着马上就要发布版本的情况下，好在开发还没做到这一步，临时变动还有挽回空间，只是项目上线压力更大了，最后那个例子看完了真的深有感触，我也希望遇见心态如此淡定的开发同事。 回顾工作，我的经验就是两点：一是需求评审一定要细致；二是产品迭代一定要迅速。 我们总说要设立项目里程碑与节点，可实践中却总是有各种问题，可能和公司整个管理方式有关吧。 继续修行。
2017-12-07 - 野山门 👍（13） 💬（1）
写的很具体，很有参考价值。很喜欢和这样的产品经理一起工作，可以有很多机会蹭烧烤吃哈哈。
2017-12-07 - Bonnie Mei 👍（12） 💬（1）
把需求文档凉了半天再去看，发现调整的地方还是有的，以前是不想看自己已经做完的东西，现在要勇敢面对。
2017-12-21 - Atom 👍（10） 💬（1）
哈哈哈哈哈哈我用PS+PPT，不仅做静态原型，偶尔还做小动效。PPT打到屏幕上还是比用网页好的，6的屏幕750*1334，两侧空出黑色留白，视觉效果很集中。
2017-12-07 - 张楚琪 👍（6） 💬（1）
看过一个段子： 「产品经理经常变更需求怎么办？」 「打一顿就好了……」 有时候需求变更是没考虑周全，这时如果有比较充裕的需求发酵时间，可能可以减少被打的次数，因为没准自己就把自己给打了，自己打自己下手可以轻点。 有时候是不得不变更，比如有更好的满足需求的方案了。感觉无论哪种情况，第一时间「自首」特别重要。跑过去，相视一笑，嘻……嘻嘻嘻，嘿……嘿嘿嘿，「兄弟喝什么奶茶？我请」，等愉快的喝完奶茶后，「这个功能如果我们这么做，你觉得怎么样？」，在奶茶带给人的愉悦感还没消失的时候，一般就不太会被打了，即使被打，也会轻一些。
2017-12-07 - vincent 👍（5） 💬（1）
这不光是硬汉，更是大牛
2017-12-07 - abillow 👍（4） 💬（1）
拥抱变化，做到不易，即需要开放心态，又要能力过硬
2017-12-07 - 丸子 👍（3） 💬（1）
最近接手了个半路撂挑子的项目，前任不明确的需求在我提给研发的时候收到了负面反馈。 他的意思是我做好了你为什么要改？ 我的想法是你做的是错的我这不是新需求只是 提 bug。 不欢而散。 最近越来越觉得，有个认真负责的产品把需求都想清楚，可以避免很多无用功，接过别人几个烂摊子之后就很反感人人都是产品经理这个说法，其实产品的门槛不低，不是人人都能做的来的。
2018-04-14 - Henglu 👍（2） 💬（1）
虽然是产品实习，但是已开始看到二爷说的所有产品变更的场景。
2018-01-02 - 时间之树 👍（2） 💬（1）
对于投入产出比的权衡，是一个产品经理很重要的能力，同时也是不断学习的目标。对于二爷提出的通过流程来对抗变更，深有同感啊，看似降低了成本，实则严重降低了效率。
2017-12-25 - grayson 👍（2） 💬（1）
原则就是如果开发接手后有变更的想法，一定尽快跟工程师沟通，不要自己去猜测成本，而是让开发去做判断，然后再综合沉没成本和额外增加的成本去做评估。 这里有个前提很重要， 找到对的人。 知道谁是对的人这个也是职场需要锻炼出来的。
2017-12-18 - Xg huang 👍（1） 💬（1）
经历过二爷说的变更基准线的制度，确实会出现这样的问题，做法就是暂停现有的开发，需求方新提需求，再一起重新开发。这样开发流程很长，然而，没关系！领导认可
2017-12-15 - Lynn 👍（1） 💬（1）
关于最后一点，让团队消化需求变更。其实也是产品的沟通能力之一，还有就是公司工作流程问题。需求变更出现在各个层级，领导要求变，ui设计又要变，开发过程中又会变又或许是需求方的业务需求变，那么对于这些场景来说，该用什么样的语言跟对方沟通？
2017-12-12 - 刘月娟 👍（0） 💬（1）
en ,想了一下，如果重新回到当时的场景的话我一定不会吝啬，果断一天三顿小烧烤走起啊~~
2020-03-16 - 郭俊杰 👍（0） 💬（1）
为啥我一个技术看的津津有味，莫非我适合当产品？
2019-06-11