以我原型评审会议举例
前言：
关键在于要搞定两大阵营：需求阵营、技术阵营。
栽过不少跟头，悟出少许实战小窍门儿，希望能帮您少走弯路。
一、会前
1、产品团队先内部评审
俗话说，家丑不可外扬。
一般情况，是不会拿着你的2B原型，跟团队内部小伙伴过一次的。
因为，谁也不想把不好的一面，露骨的展现给身边人看的一清二楚。
一般人不推荐，等你有足够的自信之后，不妨一试。
但是，如果你拉的下这个脸，可以邀请小伙伴们来个原型部门分享会。
其实，小伙伴们大部分是很乐意参与并帮助你的，除非他们当时比较忙。
我们产品部门之前就试过，效果还蛮好的，可以提前规避不少小问题。
2、两大阵营先单点逐个击破
先找业务方评审，再找技术团队评审，虽然慢了点儿，麻烦些。
但是，可以很大程度能让你在原型评审大会上，不会被两大阵营怼得体无完肤，手足无措。
2.1、单点突破——需求阵营
自己初步画的原型和规则，得先跟业务方单独过一下，确认是否达到初步预期。
业务方，是告知其该产品他们当初提的需求，如今如何满足，页面之间如何跳转、如何操作。
所以，可多次骚扰他们，小腿儿勤快些，再约他们抽时间聊聊人生，直到在用户体验上，他们点头满意为止。
2.2、单点突破——技术阵营
技术阵营选手有：项目经理、UI设计师代表、前端开发代表、后台开发代表、测试工程师代表等
技术，会抠产品的每一个细节，不断的问你为什么有这些页面、流程和规则。
你原型里有的，他能问的，都会问；没有的，也会问，谁让你没想清楚？
我觉得他们真的是一群很了不起的人儿，谢谢你们，笔芯~~
不仅要写代码、设计图片、测试产品，还要来帮你这个渣渣产品擦屁股。
不是漏了这个规则，就是漏了那个流程，或者是这个页面，反正就想怼你啦！
温馨提示：如果你没有跟技术阵营小伙伴，先小范围至少原型评审一次，你会死得很惨。
除非，你对自己的业务流程、原型、规则极其自信。那请忽略我的友情提示。
同样，别害怕被蹂躏，勇敢的面对他们，直到他们在流程、原型、规则上，不怼你为止，此轮小范围评审才算暂时告一段落。
3、做好必要准备工作
3.1、必须邀请关键人参与会议
先用各种途径(当面、邮件、钉钉、语言电话、微信等)与各关键人物，预约并定好可参会的时间。
温馨提示：如果关键人物没空参与或与其他会议发生冲突，咱们可往后延期再约。
但是，必须约到。能拍板的人没空来参与，你的评审会，开了等于白开。
谁经历，谁酸爽~~
3.2、会议通知提前一到两天发
一般以邮件+钉钉群公告形式，正式邀请项目相关所有人来参加会议
最好一个都不能少，当然特殊情况非关键人可提前请假。
3.3、准备好会议所有必备资料
需要分发的资料可以提前打印几份出来，发给有需要的小伙伴。
3.4、提前与运维同事打好招呼，连接调试好大会议室投影仪。
这事儿可大可小，如果关键时候掉链子，投影仪连不上，是很尴尬的一件事哟！
3.5、提前10分钟到达会议室，并再次提醒项目组成员。
温馨提醒大家，会议马上要开始，请移步到会议室参会。
大家都很忙，可能一天要参加N多个会议，特别是关键人物。
你不提醒，不少小伙伴或许早已把你的会议忘得一干二净，很正常。
二、会中
准备工作做足后，那么可以正式评审啦喂！快快拿好小板凳，排排坐。
4、告知会议目标
相信很多产品经理都会发现，明明我开会是聊这个需求的评审。
结果，被大家一通瞎几把乱聊之后，多少人被带到阴沟里面去了呢？
开完会，啥结论也没。好好的一个原型评审会，变成了产品吐槽大杂会。丢~
因此，重点关注会议主题、会议目标，为什么开，怎么开，要达到什么效果？
为了不重蹈覆辙，会议目标必须开会刚开始就向所有人强调。
5、介绍项目背景
等等，别猴急嘛！怎么也先来个前戏，让人家有点心理准备吧？
无论有多少人，已经知道此项目的基本情况，依然建议你统一再次为参会人员介绍下为什么要做这个产品，为谁服务，解决哪些痛点，有什么价值。
6、对评审会议进行管控。
会议主持人做好控场工作，严格遵守会议流程。
先礼后兵，对事不对人。
偏题的话题避免拉长会议时间，浪费大家表情，建议直接打断拉回主题。
7、心态要好，控制好情绪，别激动。
做产品经理，如果你没有一颗大心脏，我现在就想劝退你。
见过舌战群雄吗？没错，你的第一次原型评审大会，将会感受到。
记住，你就是全场最亮的那个zai。
放松，坦然面对，亲。
8、指定专人做会议纪要。
老铁，醒醒！一般也就是你自己记录啦。
当然，如果有个小助理，那就美滋滋咯！
9、认真落实会议决议并严格执行，责任到人。
放空炮谁不会啊？关键是很多需要落地的东西，必须责任到人。
比如说：如果原型评审没通过，作为产品经理的你得会后继续优化原型再评审，直到通过为止，才能往下推进工作；如果通过了，设计需要谁出UI图？多久出？
好多事儿呢，各项工作，都得在会议上逐一落实，各自认领。
9、不讨论技术实现细节，只探讨可行性。
别忘记了，你已经单独跟技术聊过技术规则细节了。
在这种大会上，那么多非技术人员参与，你聊过多技术实现细节问题，结果是啥，知道不？
玩手机的玩手机，睡觉的睡觉。大会哦，大佬？并不是技术原型评审会，切记。
三、会后
10、将整理好的会议记要，发给项目参会人。
会上肯定讨论了很多需要落地的会议决议，为了以防大家忘记，记录下来，并以公司正式邮件发给大家
猪哥将平时工作中使用的会议通知、会议纪要模板分享给你。
公众号后台回复：【会议纪要】领取模板。
如果你还需要什么工作模板，请私撩我咯~
11、与技术团队沟通产品提测、上线时间。
原型评审通过之后，产品也闲不下来的啦！
拉小会与技术阵营小伙伴沟通：UI图什么时候出来？代码什么时候提测？测试什么时候上灰度环境？什么时候产品和业务方验收？等等一堆问题，都需要定个时间节点。
12、给业务方反馈上线时间
很多时候，业务方在你还没跟技术阵营讨论上线时间之前。
大家才刚刚评审完，便拉着你，来那么一句：什么时候上线啊？我很急？
然后你又要很无奈的再次解释一遍：我得先跟技术团队讨论，然后跟你同步。
有木有？所以，讨论完的上线时间，赶紧告诉业务方，给他们吃颗定心丸吧！
13、管控项目进度
项目管理，主要的痛，个人觉得是以下几点，建议重点关注一二。
13.1、需求变更
又一个老大难问题，需求变更导致的风险，是很麻烦严重的。不过，要根据自己的经验与能力判断，此次需求方变更需求的影响范围。
如果影响不大，那能改就改;如果影响较大，那必须上报风险，事前告知需求方并给出合理理由。
如果是影响思维模型中的底层数据架构，那必须报严重风险。
13.2、紧急需求
最怕这类人，不讲理还霸道，整个项目正常的上线流程又不是不知道，但还要提出我现在就要，一周之内就要这种不懂互联网项目正常上线流程的无理要求。
谁的事不急，谁的需求不重要？你现在要，我也给不了，小需求我可以快速评估，尽快上线，尽量做到能今天上线绝不拖延到明天。
但是，大需求该怎么走流程还是得怎么走。
13.3、项目组临时换人
项目开发到一半，技术突然离职或者被其他项目借调，导致项目突然报风险，也是很容易让人措手不及。
如果技术离职，得找人尽快接手咱们的项目。如果技术被借调，咱们产品得去了解具体原因，想解决方案。
最终目的，保证项目正常上线。
总结：
原型评审，是我们产品人，不得不面对并认真做好的一步。任重而道远，各自加油哦！
推荐阅读:
猪哥1分钟(死磕365天，已完成23.84%)
公众号：刻意练习产品思维
作者：会飞的猪
标签：退伍军人，反面教材创业者，懂技术懂运营的B端产品人