需求变更：“头号噩梦”
需求变更⼀直都是⼀个热⻔话题 ，特别是在奉⾏唯快不破的互联⽹公司 ，需求变更可以说是程序员的头号噩 梦 ，也是 “996” 的直接元凶。
阿⾥有句⾮常有名的⼝号 ，叫作拥抱变化。 既然需求变更⽆法被消灭 ，那么我们就要通过学习 ，掌握更好地 应对需求变更的⽅法。我们先来看看常⻅的需求变更流程。
⾸先要发起变更申请 ，由变更委员会来综合评估 ，评估的内容包括变更范围、⻛险、对现有计划的影响程度 等 ，以此来判断是否接受变更。 变更委员会⼀般是由产品leader、技术leader、测试leader及项⽬经理组
成 ，如果接受变更 ，那么就需要判断项⽬计划是否需要进⾏相应的调整 ，最后公告处理结果。
其实 ，流程本⾝很简单 ，关键在于能否被有效地执⾏ 。在这⼀讲 ，我会给你介绍⼏种亲测有⽤的⽅式 ，你可 以把它们作为⾃⼰的 “ 防⾝锦囊”。
锦囊1：达成最⼩共识 ，变更是有代价的
我刚到A团队的时候 ，交互妹⼦就可怜兮兮地拉着我说： “2个⽉过去了 ，我们的第⼀个版本还在打磨，
80%的交互稿都已经改得⼤不⼀样了 ，越是临近上线越是不断地改。如果去跟策划们争辩 ，对⽅就甩过来⼀ 句 ‘⽼⼤要加的’ ，你说怎么办呢？”这个 “⽼⼤”也就是A业务的负责⼈。他是产品经理出⾝ ，⼜是完美 主义加说⼀不⼆的性格。 于是 ，产品策划在团队中就有着绝对的话语权。
在耐⼼地观察了⼀番之后 ，我终于等到了时机。在版本结束的复盘会之前 ，我跟负责⼈建议说： “你看 ，我 们项⽬组是全新的团队 ，成⽴两个多⽉了 ，这么⻓时间运⾏下来 ，还是有不少问题的。我们需要⼀次深度复 盘 ，这次复盘⾮常重要 ，你⼀定要来参加！”
复盘会的当天 ，⼤家匿名写纸条 ，分别列出各个环节做得好与不好的地⽅ ，贴到⽩板上。看着满墙花花绿绿 的便签 ，写满了各个⻆⾊对需求变更的各种吐槽 ，这位负责⼈沉默了好久。
接着 ，我把事先准备好的表格拿出来 ，表格中记录着历次变更给团队带来的各项成本增加及引发的返⼯（如 下表）。
在复盘会接近尾声的时候 ，业务负责⼈当场发话： “从今天开始 ，团队⾥的需求变更要严格控制 ，从我⾃⼰ 做起！”在这之后 ，产品策划的随意变更⾏为显然收敛了很多。我也趁势在下⼀次的全员会上 ，跟所有团队 成员约法三章 ，把复盘会上的共识 ，细化成了具体流程：
1. 所有需求及所有变更必须建单 ，⽆单需求开发有权不接；
2. 需求变更必须经过变更委员会评估成本 ，变更成本较⼤的 ，要提交项⽬经理更新时间计划 ，并告知全 员；
3. 对于确认通过的变更 ，产品⼈员要发送邮件 ，让全项⽬组⼈员都知道。
你看 ，这么⼀来 ，⼤家对于需求变更这件事 ，就从上到下达成了⼀个基本共识 ，需求变更的压⼒也瞬间得到 了缓解。所以 ，要想改变现状 ，⾸先就是找到合适的时机，树⽴对变更的最⼩共识。 之所以说最⼩共识 ，是 指这个共识不需要⼀步到位 ，如果在你的环境中确实⽐较困难 ，可以只是前进很⼩的⼀步 ，⽐如你可以从所 有变更都需要记录 ，并公告周知开始。
达成这个最⼩共识 ，是要让团队开始慢慢认识到 ，需求变更是有代价的。 不过 ，毕竟产品仍然在探索期 ，变 更总是在所难免的。
怎么办呢？策划们开始想各种办法 ，好让技术能够顺利地接受变更。 实验下来最有⽤的⼀招 ，莫过于请程序 员们吃炸鸡了。 当时坊间流传着⼀个段⼦： “没有⼀桶炸鸡解决不了的变更 ，如果不⾏ ，那就两桶！”在整 体项⽬时间有要求的情况下 ，请程序员吃炸鸡 ，也确实成了项⽬快速推进的有效选择。作为项⽬管理 ，你要 谨记 ，我们追求的是达成项⽬⽬标，⽽不是零变更。
上⾯讲的这些 ，其实是变更发⽣之后的应对⽅法。那么 ，回到变更的源头 ，我们可以做些什么呢？
⾸先 ，就是把关需求的质量 ，避免需求问题流到下游。我在第6讲中介绍的Bug Bash ，就是⼀个好⽅法 ，建 议你在⼀些⼤版本的需求设计稿完成时 ，发动团队的⼒量去做⼀轮全⾯的需求检查 ，让各个⻆⾊早期深度地 参与到项⽬中 ，这对防治需求变更⾮常有效。
锦囊2：源头治理 ，⼀次把事情做对
有同学给我留⾔说 ，上线时间都是定死的 ，即便认真做了评审 ，发现了⽅案的很多问题 ，⼀改再改 ，最后压 缩的还是开发时间。其实 ，要想真正把关需求的质量 ，还是得从源头开始治理。
接下来 ，我来跟你分享⼀个⼏年前 ，我在某事业群启动中台建设项⽬的真实案例。这个事业群当时已经有三 四年的历史了 ，伴随着多条业务线的⾼速发展 ，公共平台的架构频频遭遇掣肘。这个事业群的⽼⼤⼏经思
索 ，下定决⼼花⼤⼒⽓快速进⾏整治。情急之下 ，他找到我 ，让我来负责这个超级复杂的项⽬。
在四个⽉内 ，我们重整了这个平台积累了四年的整个业务和技术架构。 当时时间⾮常紧张 ，，四五条业务线 的产品和设计⼈员都会参与其中。作为新的中台架构 ，如果在后续执⾏中发⽣变更 ，往往会产⽣灾难性的影 响。 怎么办呢？
我急中⽣智： “⼩⿊屋集中开发呀！”不同的是 ，这次被关进⼩⿊屋的 ，不再是苦哈哈的程序员 ，⽽是产品 和设计⼈员。他们以前哪经历过这个啊？纷纷念叨着： “What？项⽬还没怎么着 ，先把产品和设计的
deadline定了？ ！”于是 ，我找来那位⽼⼤站台 ，召集全员 ，开了次隆重的启动会。会议的第⼆天 ，⼗⼏位 产品和设计⼈员就搬进来了。
为了减少后期的变更 ，尽可能⼀次把事情做对 ，我们在⼩⿊屋搞起了 “上墙⽂化” ，产品和设计的Deadline 排期图、产品模块设计图、 ⻚⾯逻辑跳转图……还有各种设计草图 ，全都被搬上了墙。
没过⼏天 ，这⾥居然成为了程序员午饭后驻⾜观赏的胜地。⻅到如此盛况 ，我们开始给他们准备各⾊⼩标
签 ，让他们在游览的同时随时发表各种评论。⼤家的参与热情空前⾼涨 ，很多需求和设计的漏洞就在这⾥被 提前发现、及时讨论并修改掉了 ，有效地保障了早期需求和设计的质量。
其实 ，这个项⽬中每条业务线都有⾃⼰的策划 ，如果采⽤传统⽅式 ，这些需求各⾃成稿 ，再加上不同业务线 的策划之间、策划和设计之间、设计和开发之间的沟通成本 ，不知道什么时候才能真正确认 ，也不知道会埋 下多少变更的 “坑”。
不得不说 ，这个锦囊是个⼤招 ，使⽤起来有⼀定难度。但从变更的源头开始治理，从源头开始公开透明，⼀次把事情最对，实际上是最有效率的⽅式。⼩⿊屋+ Deadline的实践效果奇佳 ，在⼀些上线时间有严格要求 的复杂项⽬上 ，你绝对可以考虑下！
锦囊3：快试错 ，不可抗⼒巧应对
学会了前⾯两个锦囊妙计 ，来⾃产品经理的变更就不在话下了。不过 ，现实情况是 ，很多变更来⾃⼤⽼板或 ⼤客⼾ ，这些不可抗⼒ ，我们⼜该如何应对呢？
我的建议是 ，不要直接顶回去，要去剖析、把握和满⾜⽼板或客⼾的真正诉求。你可能会说 ，说起来容易， 那如果⽼板或客⼾还是⼀定要改怎么办呢？
我的⼀个团队在被⼤⽼板的各种任性变更摧残了半年以后 ，终于痛定思痛： “我们⼀直想着法⼉地对抗变 更 ，⼤家都⾝⼼俱疲。 反过来想想 ，其实⽼板也是⼈ ，⽼板也很痛苦 ，我们要给⽼板试错的机会 ，不是
吗？”
后来 ，我们不再⼀味地抗拒 ，不过也并没有放弃努⼒ 。相反 ，我们尽可能想办法降低试错成本。 为了隔离⽼ 板的需求对整个团队进度的⼲扰 ，我们在常规团队之外，组建了⼀个⽼板需求响应⼩分队，由团队轮流值
班，协同提⾼响应速度，让⽼板可以试得快，试得爽！同时，对于那些我们并不太认同的⽼板需求，就快速尝试，先⼩范围灰度发布，再⽤对⽐数据说话。 当这⼀系列机制运转顺畅之后 ，我们慢慢发现 ，⽼板在提需 求时 ，不会每次都⽕急⽕燎了。
很多同学把这类来⾃⽼板的变更视为不可抗⼒ ，实际上 ，这背后还是有⼀定的改进空间的。你可以从建⽴快 速有效的响应机制开始 ，同时多去总结和剖析这些需求背后的原因 ，毕竟⽼板要的是效果 ，那你就得⽤数据 说话 ，更好地应对这些需求变更。
总结
这⼀讲 ，我给你分享了3条锦囊妙计 ，建议你从达成最⼩共识开始⼊⼿ ，让团队意识到变更是有代价的。然 后 ，再往前⼀步 ，从源头开始深⼊ ，集中保障需求质量 ，争取第⼀次就把事情做对。 另外 ，关于来⾃⽼板或 客⼾的需求变更 ，你要快试错 ，巧妙应对。
如果你把需求变更当作洪⽔猛兽 ，各种严防死守 ，那么最后 ，你很有可能⾝⼼俱疲。但如果你换⼀个视⻆ ， 从失败中汲取教训 ，变堵为疏 ，那么需求变更就不再是你的敌⼈了。你会发现 ，那其实是⼀个产品不断⾛向 完美的底层动⼒ ，从⽽找到更多的锦囊 ，帮助这个产品⾛向更⼤的成功！
