需求评审会议对整个项目想影响至关重要，但通常会议总会成为各方的“撕逼”大战。产品经理该如何提高需求评审会议的效率，避免被怼呢？文章作者分享了相关经验，希望对你有用。
产品经理在工作的过程中，最怕的就是评审，记得原来做技术的时候，每次产品妹妹抱着笔记本进入会议室，我们就有一种羊入狼群的感觉，每个工程师都跃跃欲试准备好怒怼产品，贯彻以一次评审通过为耻，以气哭产品妹妹为荣的评审精神……后来转型做了产品，发现真是天道轮回，互联网行业永远不缺杠精，自己的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 及时的封板以及引入正规的需求变更流程
虽然说做互联网产品要拥抱变化，但拥抱多了心态或多或少也会扭曲，所以及时的封板让技术人员有一个相对的稳定的版本进行开发，不要成天体现吊胆的担忧需求一直在变，随意的变化也让技术感觉自己的付出变得没有任何价值，任人践踏，所以即便是有变化，通过优先级与正规的需求变更评审委员会的权威性，让技术人员感受到需求变更的仪式感。
最后
评审会上难免会有杠精，有时候人一旦陷入疑人偷斧的狭义思维境地，无论听见什么声音，都会认为是一种噪音，想尽办法也要跟你抬杠到底，一般我们遇到这种问题大家的选择往往都是回避，希望会后私下解决，但是这样做无异于示弱和逃避，让对手一而再再而三的在评审会上怼你，这时候不如学着用太极的思路解决问题。打太极中如果对方正面攻击你，一般不会直接用手去档，那样只能是两败俱伤，应当是让拳头顺着你的手臂向下化解力量，而与此同时另一只手攻击对方暴露的后背。
评审会上也是如此，如果遇到杠精跟你杠需求，千万不要正面对攻，不如试着顺着对方的思路去延伸，在延伸的过程中找到破绽，再用你的业务深度优势直接否定这个论证，让对方以后也不敢再轻易的挑衅。
作为产品经理完成一次圆满的PRD并不会得到掌声，只不过少了一些埋怨和质疑，但这就是我们的日常工作啊，当你在会议室送走开发人员静静合上笔记本的时候，就是下一场评审战役的开始。
微信扫一扫 
