需求变更一直都是一个热门话题，特别是在奉行唯快不破的互联网公司，需求变更可以说是程序员的头号噩梦，也是“996”的直接元凶
常见的需求变更流程
首先要发起变更申请，由变更委员会来综合评估，评估的内容包括变更范围、风险、对现有计划的影响程度等，以此来判断是否接受变更。变更委员会一般是由产品 leader、技术 leader、测试 leader 及项目经理组成，如果接受变更，那么就需要判断项目计划是否需要进行相应的调整，最后公告处理结果
其实，流程本身很简单，关键在于能否被有效地执行。下面介绍应对需求变更的“防身锦囊”
达成最小共识，变更是有代价的需求变更的具体流程
1、所有需求及所有变更必须建单，无单需求开发有权不接；
2、需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员；
3、对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道。
对于需求变更这件事，就从上到下达成了一个基本共识，需求变更的压力也瞬间得到了缓解。所以，要想改变现状，首先就是找到合适的时机，树立对变更的最小共识。之所以说最小共识，是指这个共识不需要一步到位，如果在你的环境中确实比较困难，可以只是前进很小的一步，比如你可以从所有变更都需要记录，并公告周知开始
达成这个最小共识，是要让团队开始慢慢认识到，需求变更是有代价的。不过，毕竟产品仍然在探索期，变更总是在所难免的
作为项目管理，你要谨记，我们追求的是达成项目目标，而不是零变更
源头治理，一次把事情做对其实，项目中每条业务线都有自己的策划，如果采用传统方式，这些需求各自成稿，再加上不同业务线的策划之间、策划和设计之间、设计和开发之间的沟通成本，不知道什么时候才能真正确认，也不知道会埋下多少变更的“坑”
但从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式。小黑屋 + Deadline 的实践效果奇佳，在一些上线时间有严格要求的复杂项目上，你绝对可以考虑下！
快试错，不可抗力巧应对在现实情况中，很多变更来自大老板或大客户，这些不可抗力，我们又该如何应对呢？
建议是：不要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求
不再一味地抗拒，不过也并没有放弃努力。相反，我们尽可能想办法降低试错成本。为了隔离老板的需求对整个团队进度的干扰，我们在常规团队之外，组建了一个老板需求响应小分队，由团队轮流值班，协同提高响应速度，让老板可以试得快，试得爽！同时，对于那些我们并不太认同的老板需求，就快速尝试，先小范围灰度发布，再用对比数据说话。当这一系列机制运转顺畅之后，我们慢慢发现，老板在提需求时，不会每次都火急火燎了
如果把需求变更当作洪水猛兽，各种严防死守，那么最后，你很有可能身心俱疲。但如果你换一个视角，从失败中汲取教训，变堵为疏，那么需求变更就不再是你的敌人了。你会发现，那其实是一个产品不断走向完美的底层动力，从而找到更多的锦囊，帮助这个产品走向更大的成功！
