在我们的项目过程中，需求的变更一直是个比较热门的话题，特别是在互联网的创业公司奉行着唯快不破的文化下，需求的变更永远是程序员的头号噩耗。996不死的元凶。
既然变化是不可避免的，那我们就需要去学会拥抱变化，掌握更好地应对需求变更的方法。
需求原有的计划是这样的：首先要发起变更申请，由相关人员来综合评估，评估的内容包括变更范围、风险、对现有计划的影响程度等，以此来判断是否接受变更。相关人员一般是由产品 leader、技术 leader、测试 leader 及项目经理组成，如果接受变更，那么就需要判断项目计划是否需要进行相应的调整，最后公告处理结果。
达成最小共识:变更是有代价的！这个方法其实不利于内部团结的，哈哈，估计要被业务和产品打死！比如我们在事情发生的过程中，list了几个点1.所有的需求以及所有的变更必须建单，无单需求开发有权不接；2.变更需要经过相关人员的成本评估，变更成本较大的，当然要给到PM，也要告知到全员；3.确认通过的变更，要公布出来，让大家都能知道。找到合适的机会，树立对变更最小的共识，大概的意思就是:可以小小的前进一步，不需要一步到位。同时要让团队意识到需求变更是有代价的。话说过来，毕竟如果产品也是在探索期，变更也是在所难免的。理解万岁！我们追求的是达成项目目标，而不是零变更。
从源头做起，一次把事情做对！要想把关需求的质量，还是得从源头开始治理。我么可以找个小黑屋集中开发，这次不光是关开发人员，而是将开发和设计都一起拉过来。在小黑屋搞起了上墙文化，产品和设计的 Deadline 排期图、产品模块设计图、页面逻辑跳转图……还有各种设计草图，全都可以被搬上墙。很多需求和设计的漏洞可以在这里被提前发现，及时讨论并修改掉。有效的保证了早期需求和设计的质量。小黑屋 + Deadline 的实践效果奇佳，在一些上线时间有严格要求的复杂项目上，我们绝对可以考虑下！
快试错，不可抗力巧应对！很有一点，是比较不好处理的来自于甲方或者老板的需求，我们该怎么去应对呢？直接怼回来，肯定是不能的，那都是衣食父母啊！哈哈！我们不能直接顶回去，不要去发牢骚，要去剖析、把握和满足老板或客户的真正诉求。我们以前的做法是专门成立一个老板需求响应小队，有团队轮流值班，协同提高响应速度，让老板可以试的爽，试的快，有时我们可能并不是很认同老板的需求，就快速尝试，小范围的灰度，用对比数据说话。我们慢慢发现，老板提需求时不会每次都火急火燎了。
方法论是一方面，我们的认知也是需要有改正，积极面对需求变更，好的建议，及时采纳；不确定的，小范围试错，用数据说话。 技术架构设计时，要尽可能有扩展性、层次性，需求变动要控制在很小的范围内，不能牵一发动全身。但又不能一开始就过度设计，需求的变化也就促成了框架的更加强大。沟通很重要，面对不合理的需求时，要委婉、有理有据，实在不行就以退为进，让数据说话。要给自己留有余地，自己的认识也可能是错的。
以疏治堵，源头治理，顺势而为，闭环优化，数据说话
