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