会议前准备工作一览表
工作中会议越来越多，如何高效完成会议记录？
工作中会议越来越多，如何高效完成会议记录？
以我原型评审会议举例
前言：
关键在于要搞定两大阵营：需求阵营、技术阵营。
栽过不少跟头，悟出少许实战小窍门儿，希望能帮您少走弯路。
一、会前
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端产品人
项目例会开多久比较合适？项目的哪些人适合参加？
我以员工的身份参加过不少项目例会，也以项目经理的身份主持过不少的项目例会，而现在更多的是旁听或者监督别人的项目例会。
身份不同，角色不同，看问题的角度就不同，参与力度也不同，当然关注点势必也不同。
现在我们主要以员工的角色以及项目经理的角色去探讨一下项目例会开多久比较合适，项目中的哪些人参与比较合适。
探讨这个问题前，我们首先要明确一件事情，那就是开项目例会的目的是什么？对于员工而言，参加项目例会有三个目的:
汇报自己当前的工作情况与工作进度。
将自己当前工作当中碰到的问题提出来以便寻求帮助与解决。了解项目的整体进展以方便下一步自己的工作安排。对于项目经理而言，也有三个目的:
了解项目整体进展情况。
了解员工以及项目所存在的问题与风险。
沟通、协调、处理、解决、规避相关事宜。由此可见，员工和项目经理的目的几乎相同，这也说明了整个团队成员在参与项目例会这件事上关注点是一致的，只不过员工关注的是个体，而项目经理关注的是整体。将每一个个体糅合起来，就是一个整体，这也和管理理念相吻合。
既然目的已经明确，那么项目例会开多久，那就比较简单了。虽说简单，但还要考虑一个实际的问题，那就是场地问题。
现在有种现象，每天早上在投入工作前，总有一些人站着聚在一起，开一个站会，或者干脆拉一个网络会议，然后大家叽叽喳喳一番，而且还不占用任何场地资源。
当然，这和项目例会还是有本质上的区别，项目例会追求的是整体，而且还要形成正规的会议纪要，方便监督与跟踪。因此，项目例会必须要有正规且方便的场地。
说完场地，那么到底项目例会开多久比较合适呢？
个人经验与建议是不要超过45分钟，也就是不超过学生上一节课的时间。
只要会议目的明确，准备充分，这个时间足够了。而一旦超过这个时间，几乎可以说明项目例会已经跑题了，已经偏离了主题。
项目例会是一个提出问题，汇总问题，协调问题，分配问题的会议，千万不能把它当成是研究问题与解决问题的会议。
否则的话就会消耗大量的时间，而消耗掉大量时间，往往获利的只是某一个或者某几个人而已，对于绝大多数参会人员来说，最终时间都白白浪费掉了。
项目当中的哪些人适合参与项目例会呢？现在很多项目，少则数人，多则上百人。这势必会涉及到会议场地，人数少还行，就不在讨论，人数多的话很难办，因此必须要控制项目例会的参会人数。
那么哪些人必须参加项目例会，哪些人又是可选择参与项目例会，哪些人又是没必要参与项目例会呢？
我们可以遵循以下原则:
直接干系人必须参与
间接干系人可选择参与不相干的人没必要参与那么这些人如何界定呢？
项目经理根据项目具体情况，可先确定部分参会人选。
项目例会前一天或前半天，项目经理通过各种途径，比如邮件，比如内部通信系统，或者当面沟通，结合项目情况和各自具体情况，再确定部分参会人选。
什么是具体情况呢？
我们上面提到过的项目例会的目的，这就是具体情况。
同时，我上面也提到过项目例会是一个提出问题，汇总问题，协调问题，分配问题的会议，
有些问题，通过前面时间的沟通、确认、以及判断，筛选出必须上例会的，排除掉没必要上例会的，关于这些，项目经理都可以灵活把握。
我们的项目例会这样开我们有个项目，规模比较大，接近百人，而且牵扯到异地，同时客户也要参与。
我们例会时间一般放在周五下午四点，方式是视频会议，参会人选包括:项目经理，各小组负责人，会议纪要人员，客户代表，会议主持人，会议召集人，其他相干人员。
会议内容，会议主题，会议接入时间，会议地点，参会人选等具体事项在周五上午就会发邮件给各参会人，可抄送密送其他人选，比如各相关领导。
客户代表由客户方自己指定。
会议纪要人员每次都由项目经理指定，选择和本次例会关联度不大的项目成员担当。
会议主持人由各小组负责人轮流担当，当期例会主持人选择由当期例会关联度较小的小组负责人担当。
会议召集人员由项目经理自己担当。
其他相干人员，根据上面提到的原则进行选择。
会议召集人监督整个会议，避免会议当中出现不符合主题的情况。
会后，会议纪要都要按时发给相关人员。
总之，项目经理有权利进行灵活的调整，甚至取消。