需求评审 *** 会议对整个项目想影响至关重要，但凡是 *** 会议总会成为各方的“撕逼”大战。产物司理该如何提高需求评审 *** 会议的效率，制止被怼呢？文章作者分享了相关履历，但愿对你有用。

产物司理在事情的进程中，最怕的就是评审，记得本来做技能的时候，每次产物妹妹抱着条记本进入 *** 会议室，我们就有一种羊入狼群的感受，每个工程师都跃跃欲试筹备好怒怼产物，贯彻以一次评审通过为耻，以气哭产物妹妹为荣的评审精力……厥后转型做了产物，发明真是天道循环，互联网行业永远不缺杠精，本身的PRD设计的靠近于高保真，需求带着十二万分的诚意，依然被怼的遍体鳞伤。

跟着斗争的不绝深入，我也痛定思痛逐步总结除了一些如何产物PRD评审的保留指南，实验与技能团队融洽的开PRD评审会。

01 突出你的业务主场

业务常识是产物司理的强项，而技能是弱项，哪怕你是一个技能地位转岗的产物司理，也不要用本身已往的技能配景来挑战当下的开拓团队，这样做无异于自掘宅兆，试想设计一款套餐产物的报价成果时，假如你非要用SKU和价值属性的 *** 描写你需求，那最后或许率会演酿成各人对SKU颗粒度探讨的技能细节问题上。

既然做了产物司理，就要突出本身业务常识的强项，究竟业务是你的主场，而技能永远是你的客场，所以在PRD评审会上必然要操作好你的主场优势，评审进程中只管多用业务语言来描写你的产物，假如技能人员对某些要害词有疑问，再耐性解答。

02 用代价来描写你的诉求

业内有句话叫“产物动动嘴，开拓跑断腿”，在开拓人员眼中，产物的确就是本身每天加班，找不到女伴侣的祸首罪魁，每次评审会开拓同学只会存眷这个评审之后本身的事情量是否会增加，而不会体贴产物的更新能给他们带来什么代价。

所以在PRD评审时，必然要给开拓人员讲清楚这个成果的代价，假如定时开拓出来，对公司和产物辅佐，究竟产物做得好，能带来更多受益，开拓人员才有人为拿，哪怕加加班赶赶工自然也就没话可说。

03 让业务人员参加你的评审

B端产物最巨大的就是业务逻辑，而技能人员最欠缺的就是对业务逻辑与业务代价的领略，所以在评审的时候，更好加上业务需求方的人，更好是直接认真人，并与其成立攻守联盟，操功课务优势和代价目标盖住技能人员一波又一波的问题，虽然前提是评审前你确认你做的对象简直是业务方想要的，否则只能是让本身多了一个敌手。

04 给出实体间的干系

产物司理需要对你的需求举办一些技能化的改造，针对细化的业务逻辑，将实体拆出来，固然说需要一点技能配景，但也不消真正像技能人员一样去设计模子，只需要界说出实体之间的n对m的逻辑干系，有了这个实体干系图，技能人员就会很轻松的设计出公道的数据库模子，对你的谢谢之心也会大增。

05 用户故事的 *** 来表达需求

我们本来在迭代的时候，都是会将PRD拆分成若干的用户故事，用脚色+场景+操纵+权限+目标（代价）的 *** 来描写要开拓的成果，UI和测试看完需求之后也概略能知道本身改怎么设计交互和测试用例，对你的好感度上升50%，评审会上可保持中立；同时开拓人员按照你的描写也能预估一下技能难度和事情量，在心底冷静的给你点赞。

06 给出完整的字典信息

每个PRD上都要给出可选项的字典值域以及是否必选、是否可多选等元信息，首先这个东东是只有产物知道的，你此刻不给后头也照旧要给的，届时给就会落一句“早干吗去了，非等我找你要才给”之类的抱怨话，并且频繁动员静问你，也会埋下两边日后难以相同的苦果之种，哪怕是再简朴的可选项也要给出值域，譬喻性别选项框，假如值域你空着不写，不解除有些开拓没事谋事的问你，人妖用户填什么？

07 PRD要思量技能的体验感

最后就是输出PRD，将PRD当成一个产物，而技能人员就是你的用户，如何晋升你用户的体验感呢？我的做法是将PRD的排版按“页面说明”、“业务逻辑”，“数据字典”分隔，充实思量技能人员的阅读习惯，淘汰他们肉眼去扫重要信息的时间。

并且，差异脚色的开拓人员，对信息获取也是差异的，就这样一个小小的改造曾经让我在产物复盘会上收到过两个正字的好评，全是“prd写的很清楚，思路清晰”，同技能人员的干系也晋升不少，说白你假如在开拓PRD的时候设身处地的为技能，UI，测试同学着想，他们也不会难为你。

08 实时的封板以及引入正规的需求改观流程