导读：业务PRD评审注意事项避坑
评审前
一定要提前跟业务约会议日程，不要突然去找业务，我们对接的一般都是部门负责人，他们一般都很多会议要开
会议时间最少定1个小时。你原计划找他聊10分钟确认一个小问题，结果聊了2个小时，对需求、聊历史逻辑、聊方案、头脑风暴等等
任何与业务的沟通结论，一定要在群里发会议纪要留底
无论上级或业务再怎么催，千万不要没有业务评审，就直接技术评审，后果自负
会前可以先把PRD发给业务：他90%不会看，但你不发就是你的问题
评审中
要有自己的节奏，如果被业务带偏，马上拉回来，可多次
不要一来就讲原型规则细节，先讲背景、目的、流程等做好铺垫
一般跟业务主要是对你对此需求的解读、业务流程、原型等信息
极个别扣细节的业务方，建议把页面每个字段的取值规则、写入时间、数据源等信息一并跟他过一遍，尤其针对那些不信任你的业务，过的越细越好
不要说过多技术词汇，尽量换成业务术语通俗易懂的告诉他
不要在正式环境演示页面，哪怕只是查看不操作任何数据，去测试环境
坦然接受业务的批评，少反驳少顶嘴
哪怕是业务说错了，也没必要争个输赢，只要开始争论你就已经输了
不要轻易下结论，多发问多倾听
不要抢话，除非偏离主题很久
会上沟通过程中，尽量不要占用过多研发资源。比如业务突然想Q某技术，你可以先阻拦，说你会后找技术确认
评审后
会后一定要发会议纪要到群里
会议纪要主要包含：会议结论、待办事项
所有的待办一定要@对应人并确定DDL（截止时间）
如果评审不通过，最好当天尽快修改待确认项，与业务再约时间再次业务评审
如果评审通过，后期任何新的需求变更，都要及时更新到PRD并通知相关方
所有过程中沟通的问题，建议都汇总到一个问题库中且共享给项目组成员，方便后期追溯
标签 产品经理
