第一次原型评审，产品经理的你该怎么开？

推荐我的好友猪哥的文章。三年日一日，自律狂魔，已坚持与2万+粉丝每天群里讨论产品话题860多天。

前言：

关键在于要搞定两大阵营：需求阵营、技术阵营。

栽过不少跟头，悟出少许实战小窍门儿，希望能帮您少走弯路。

一、会前

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、项目组临时换人

项目开发到一半，技术突然离职或者被其他项目借调，导致项目突然报风险，也是很容易让人措手不及。

如果技术离职，得找人尽快接手咱们的项目。如果技术被借调，咱们产品得去了解具体原因，想解决方案。

最终目的，保证项目正常上线。

总结：

原型评审，是我们产品人，不得不面对并认真做好的一步。任重而道远，各自加油哦！