项目(六)需求变更的应对策略

文章来自 https://time.geekbang.org/column/article/156858 修改

及时拥抱变化, 我们追求的是达成项目目标，而不是零变更
以疏治堵，源头治理，顺势而为，闭环优化，数据说话

需求变化时的基本流程

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

保证基本流程的三个方法

达成最小共识：变更是有代价的

要让团队所有人开始慢慢认识到，需求变更是有代价的, 但是互联网环境下, 变更是在所难免的

一般情况下, 真正干活的角色是知道代价的, 而管理层级可能并不知道. 因此经常发生 项目发起者等其他角色随便变更需求而后觉得执行角色工作没有按时完成.
找到合适的时机，树立对变更的最小共识。之所以说最小共识，是指这个共识不需要一步到位，如果你的环境下确实比较困难，可以只是前进很小的一步，比如你可以从所有变更都需要记录，并公告周知开始
规范化每次需求变更的流程:

1. 所有需求及所有变更必须建单，无单需求开发有权不接；
2. 需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员；
3. 对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道。
   在确定需求变更后, 要让执行层接受变更, 就需要犒赏他们, 比如请吃饭, 喝下午茶等方式.
   建议在一些大版本上，需求设计稿完成时，发动团队的力量去做一轮全面的需求检查，调动各个角色的早期深度参与，对需求变更的防治很有效。

源头治理，一次把事情做对

从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式

面对超复杂的项目时, 在项目开始前把相关人全部集合在一起, 集思广益, 产出一个大家都认可的方案.

快试错，不可抗力巧应对

学会顺水推舟而不是逆流而上

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