产品经理最崩溃的时刻是什么？原型没画完，需求变了。
产品经理更崩溃的时刻是什么？原型画完了，需求变了。。。
所以阿酒总结了自己多年踩雷经验，分享一下如何优雅应对需求变更：
一、预防篇：
1、需求开始前：全面同步信息
接到业务需求后，一定要约需求方当面沟通，了解项目目标和定位，把所有流程、期望效果都全面聊清楚；并让运营同学写成BRD，在项目系统或邮件正式提出需求，周知直接需求方、需求方leader和自己的leader，防止人员间信息不对称和预期差异
2、方案过程：紧密合作+保持沟通
尽量参与到业务方的商务合作、财税法和风控沟通的流程中，收集各方信息，主动优化业务逻辑；确认可行性后再开始产品方案和PRD，避免早早开始闷头画原型、出交互
3、方案确认：充分讨论+书面确认
完成产品方案后约上业务方（包括业务对接人和业务leader），正式而充分地评审产品方案，让业务确认方案是否满足需求，正式确认无误后再进行研发评审
方案确认需要业务对接人书面确认，并周知各个相关方和相关leader，避免层层汇报出现信息断层
（如果发现对接的运营同学给出模棱两可的回答，多半是TA做不了主，这时就要拉上TA的leader进行确认）
4、排期反馈：及时同步
研发评审后及时向业务方反馈排期时间，研发过程中遇到问题，自己不能完全确认的，及时让业务同学进行确认
二、不可避免的需求变更
判断需求变更是否是核心需求、关键环节，是否可以放到下个版本迭代，尽可能先实现核心需求，跑通业务流程
如果可以，给出迭代时间预期
如果不可以，给出需求变更的成本预期（方案修改时间、再次评审时间、研发时间、延期上线），并让业务方邮件或系统上正式提出需求变更，写明需求变更点、变更原因
