概述

需求变更一直都是一个热门话题，特别是在互联网公司，需求变更可以说是大家的头号噩梦。
既然需求变更无法被消灭，那么我们就要通过学习，掌握更好地应对需求变更的方法。

需求变更流程

需求变更流程

首先要发起变更申请，由变更委员会来综合评估，评估的内容包括变更范围、风险、对现有计划的影响程度等，以此来判断是否接受变更。变更委员会一般是由产品 leader、技术leader、测试 leader 及项目经理组成，如果接受变更，那么就需要判断项目计划是否需要进行相应的调整，最后公告处理结果。
其实，流程本身很简单，关键在于能否被有效地执行。

锦囊 1：达成最小共识，变更是有代价的

需求变更是有代价的。找到合适的时机，树立对变更的最小共识。

之所以说最小共识，是指这个共识不需要一步到位，如果在你的环境中确实比较困难，可以只是前进很小的一步，比如你可以从所有变更都需要记录，并公告周知开始。

• 1. 所有需求及所有变更必须建单，无单需求开发有权不接；
• 2.需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员；
• 3. 对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道。

我们追求的是达成项目目标，而不是零变更。

上面讲的这些，其实是变更发生之后的应对方法。那么，回到变更的源头，我们可以做些什么呢？

• 首先，就是把关需求的质量，避免需求问题流到下游。建议在一些大版本的需求设计稿完成时，发动团队的力量去做一轮全面的需求检查，让各个角色早期深度地参与到项目中，这对防治需求变更非常有效。

锦囊 2：源头治理，一次把事情做对

上线时间都是定死的，即便认真做了评审，发现了方案的很多问题，一改再改，最后压缩的还是开发时间。
其实，要想真正把关需求的质量，还是得从源头开始治理。
不得不说，这个锦囊是个大招，使用起来有一定难度。但从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式。小黑屋 + Deadline 的实践效果奇佳，在一些上线时间有严格要求的复杂项目上，你绝对可以考虑下！

锦囊 3：快试错，不可抗力巧应对

学会了前面两个锦囊妙计，来自产品经理的变更就不在话下了。不过，现实情况是，很多变更来自大老板或大客户，这些不可抗力，我们又该如何应对呢？
我的建议是， 不要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求。你可能会说，说起来容易，那如果老板或客户还是一定要改怎么办呢？
尽可能想办法降低试错成本。为了隔离老板的需求对整个团队进度的干扰， 我们在常规团队之外，组建了一个老板需求响应小分队，由团队轮流值班，协同提高响应速度，让老板可以试得快，试得爽！同时，对于那些我们并不太认同的老板需求，就快速尝试，先小范围灰度发布，再用对比数据说话。当这一系列机制运转顺畅之后，我们慢慢发现，老板在提需求时，不会每次都火急火燎了。
很多同学把这类来自老板的变更视为不可抗力，实际上，这背后还是有一定的改进空间的。
可以从建立快速有效的响应机制开始，同时多去总结和剖析这些需求背后的原因，毕竟老板要的是效果，那你就得用数据说话，更好地应对这些需求变更。

总结

这一讲分享了 3 条锦囊妙计：

• 建议从达成最小共识开始入手，让团队意识到变更是有代价的。
• 然后，再往前一步，从源头开始深入，集中保障需求质量，争取第一次就把事情做对。
• 另外，关于来自老板或客户的需求变更，要快试错，巧妙应对。
  如果你把需求变更当作洪水猛兽，那么最后会身心俱疲。但如果我们换一个视角，从失败中汲取教训，变堵为疏，那么需求变更就不再是你的敌人了。而且我们会发现，那其实是一个产品不断走向完美的底层动力，从而找到更多的锦囊，帮助这个产品走向更大的成功！