产品经理工作杂谈丨如何优雅应对需求变更

产品经理最崩溃的时刻是什么?原型没画完,需求变了。

产品经理更崩溃的时刻是什么?原型画完了,需求变了。。。

所以阿酒总结了自己多年踩雷经验,分享一下如何优雅应对需求变更:


一、预防篇:

1、需求开始前:全面同步信息

接到业务需求后,一定要约需求方当面沟通,了解项目目标和定位,把所有流程、期望效果都全面聊清楚;并让运营同学写成BRD,在项目系统或邮件正式提出需求,周知直接需求方、需求方leader和自己的leader,防止人员间信息不对称和预期差异


2、方案过程:紧密合作+保持沟通

尽量参与到业务方的商务合作、财税法和风控沟通的流程中,收集各方信息,主动优化业务逻辑;确认可行性后再开始产品方案和PRD,避免早早开始闷头画原型、出交互


3、方案确认:充分讨论+书面确认

完成产品方案后约上业务方(包括业务对接人和业务leader),正式而充分地评审产品方案,让业务确认方案是否满足需求,正式确认无误后再进行研发评审

方案确认需要业务对接人书面确认,并周知各个相关方和相关leader,避免层层汇报出现信息断层

(如果发现对接的运营同学给出模棱两可的回答,多半是TA做不了主,这时就要拉上TA的leader进行确认)


4、排期反馈:及时同步

研发评审后及时向业务方反馈排期时间,研发过程中遇到问题,自己不能完全确认的,及时让业务同学进行确认


二、不可避免的需求变更

判断需求变更是否是核心需求、关键环节,是否可以放到下个版本迭代,尽可能先实现核心需求,跑通业务流程

如果可以,给出迭代时间预期

如果不可以,给出需求变更的成本预期(方案修改时间、再次评审时间、研发时间、延期上线),并让业务方邮件或系统上正式提出需求变更,写明需求变更点、变更原因

推荐阅读更多精彩内容