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