需求变更在奉行唯快不破的互联网公司，可算程序员头号噩梦，“996”直接元凶。
阿里口号拥抱变化。既然需求变更无法被消灭，就要通过学习，掌握更好应对需求变更方法。
1 常见的需求变更流程
先要发起变更申请，由变更委员综合评估，评估内容包括：
- 变更范围
- 风险
- 对现有计划的影响程度等
以判断是否接受变更。变更委员会一般由产品leader、技术leader、测试leader及项目经理组成。若接受变更，就需要判断项目计划是否需要进行相应调整，最后公告处理结果。
这流程简单，书上都这么写，但现实除了我，团队没人愿意这么干！
坦诚直面问题的确是第一步。嘴说都容易，关键在于能否有效执行。
本文就介绍几种实战有用的方式。
2 达成最小共识：变更是有代价
当年刚到A团队，交互妹子就可怜兮兮拉我：“2个月过去了，第一个版本还在打磨，80%交互稿都改得大不一样，越临近上线越不断改。如果你去跟策划争辩，对方就甩过来一句‘老大要加’，你说咋办？”
这“老大”就是A业务负责人。他是PM出身+完美主义+说一不二性格，于是，产品策划在团队有绝对话语权。
观察一番后，等到时机。在版本结束的复盘会前，我跟负责人说：“你看，我们项目组是全新团队，成立两多月，这么长时间运行还是有不少问题。我们需要一次深度复盘，你一定要来参加！”
复盘会当天，大家匿名写纸条，分别列出各环节做得好、不好地方，贴到白板。看满墙花花绿绿便签，写满各角色对需求变更各种吐槽，这负责人沉默好久。
接着，我把事先准备表格拿出，表格记录历次变更给团队带来的各项成本增加及引发的返工：
复盘会尾声时，业务负责人发话：“从今天开始，团队里需求变更要严格控制，从我自己做起！”之后，产品策划的随意变更行为收敛很多。而我也趁势在下一次的全员会上，跟所有团队成员约法三章，把复盘会上的共识，细化成具体流程：
- 所有需求及所有变更必须建单，无单需求，开发有权不接
- 需求变更须经变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员
- 对确认通过的变更，产品人员要发送邮件，让全项目组人员都知道
这样，大家对需求变更这事，就从上到下达成共识，需求变更的压力也瞬间得到缓解。所以，要想改变现状，先 找到合适时机，树立对变更的最小共识。这共识无需一步到位，若你的环境下确实比较困难，可以只是前进很小一步，如从所有变更都需要记录，并公告周知开始。
达成最小共识，是让团队开始认识到， 需求变更有代价。但毕竟产品仍在探索期，变更是难免。
咋办
策划开始想办法，好让技术能顺利接受变更。实验下来最有用一招，莫过于请程序员们吃炸鸡。“没有一桶炸鸡解决不了的变更，如果不行，那就两桶！
整体项目时间有要求的情况下，请程序员吃炸鸡，确实成项目快速推进有效选择。作为项目管理，谨记， 我们追求的是达成项目目标，而不是零变更。
这些变更发生后的应对方法。
变更的源头能做啥？
把关需求质量，避免需求问题流到下游，第6讲介绍Bug Bash，就是好方法。建议在一些大版本，需求设计稿完成时，发动团队力量做一轮全面的需求检查，调动各角色的早期深度参与，对需求变更防治很有效。
3 源头治理，一次把事情做对
刚才的方案1好棒！原来需求变更流程，是这样步步共识建立的。
不过，我们团队的需求质量实在着急，上线时间又定死的，我担心只有这些，事后应对还不够，到头一改再改，还是压榨开发时间，能否源头杜绝隐患？
要想真正把关需求质量，还是得从源头治理。
案例
几年前，某事业群启动中台建设项目。这事业群已有三四年历史，伴随多条业务线高速发展，公共平台架构频频遭遇掣肘。事业群老大几经思索，决心花大力气快速进行中台整治。让我来负责这超级复杂项目。
四个月内，我们重整平台积累四年的整个业务和技术架构。时间紧张，四五条业务线的产品、设计都会参与。作为新的中台架构，若在后续执行中发生变更，往往产生灾难性影响。咋办？
“小黑屋集中开发呀！”不同的是，这次被关进小黑屋的，不再是程序员，而是产品、设计。他们以前哪经历过这个，念叨着：“What？项目还没怎么着，先把产品和设计的deadline定了？！”
于是，我找来那位老大站台，召集全员，开隆重启动会。会议第二天，十几位产品、设计就搬进来了。
为减少后期的变更，尽可能一次把事情做对，我们在小黑屋搞起上墙文化，产品、设计的Deadline排期图、产品模块设计图、页面逻辑跳转图……还有各种设计草图，全都搬上墙。
没过几天，这里居然成为程序员午饭后驻足观赏的胜地。我们开始给游客们准备各色小标签，让他们在游览同时随时发表各种评论。大家参与热情空前高涨，很多需求和设计的漏洞就在这里被提前发现、及时讨论并修改，有效保障早期需求和设计的质量。
其实，这项目中每个业务线都有自己的策划，若采用传统方式，这些需求各自成稿，再加不同业务线策划之间、策划与设计之间、设计与开发之间、反复沟通成本，不知拖到猴年马月才能真正确认，又不知给后期埋多少坑。
这个锦囊是大招，使用起来有难度。但 从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式。小黑屋 + Deadline效果奇佳，在一些上线时间有严格要求的复杂项目，你绝对能考虑。
4 快试错，不可抗力巧应对
学会前俩锦囊妙计，来自PM的变更就不在话下。但现实很多变更来自大老板或大客户，这些不可抗力如何应对？
不要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求。说起来容易，若老板或客户还是一定要改咋办？
我的一个团队在被大老板各种任性变更摧残半年后，痛定思痛：“我们一直想着法儿地对抗变更，身心俱疲。反过来想，老板也是人，老板也痛苦，我们要给老板试错机会，不是吗？”
后来，我们不再一味抗拒，不过也并未放弃努力。相反，我们尽可能想办法降低试错成本，为隔离老板的需求对整个团队进度干扰，在常规团队之外：
- 组建 老板需求响应小分队，由团队轮流值班，协同提高响应速度，让老板能试得快，试得爽！
- 同时，对那些不太认同的老板的需求， 就快速尝试，小范围灰度发布，用对比数据说话
这一系列机制运转顺畅后，慢慢发现，老板提需求时不会每次都火急火燎。很多人把老板变更视为不可抗力，实际上，这背后还是有改进空间。你可从建立快速有效的响应机制开始，同时多总结剖析这些需求背后原因，毕竟老板要效果，那你得数据说话，更好应对这些需求变更。
5 总结
建议你从达成一个最小共识开始入手，让团队意识到变更是有代价的。然后再往前一步，从源头开始深入，集中保障需求质量，争取第一次就把事情做对。另外，关于来自老板或客户的需求变更，你要快试错，巧妙应对。
对本节需求变更方法论的箴言总结：“以疏治堵，源头治理，顺势而为，闭环优化，数据说话。”
如果你把需求变更当作洪水猛兽，各种严防死守，那么最后你很有可能身心俱疲。但如果你换一个视角，从失败中汲取教训，变堵为疏，那么需求变更就不再是你的敌人。你会看到一个产品不断追求完美的底层动力，从而找到更多的锦囊，帮助这个产品走向更大的成功！
