从事项⽬管理⼯作之后 ，你会发现⾃⼰⼀下⼦多了很多⼤⼤⼩⼩的会。项⽬全局涉及到的整个过程 ，你都要 去了解。很多⼈说 ，项⽬经理有80%的时间都⽤在了沟通上 ，不是在开会 ，就是在开会的路上 ，其实所⾔不 虚。
会就是聚会、 ⻅⾯ 、集会 ，议就是讨论、 商议 ，会议作为⼀种群体沟通⽅式 ，决定了正式信息在项⽬组内的 传递路径。 实际上 ，我们的会议 ，就像现代⼈的营养⼀样 ，过剩了。我们知道 ，营养过剩就会吸收不进去 ， 那么会议过剩了 ，会怎样呢？
如果我们把项⽬组看成⼀个有机体 ，这个有机体承载不了那么多的信息 ，后果就是会⽽不议。会上说了⼀ 堆 ，却没有决议 ，没有动作 ，那么这个有机体是没有办法正常运作的。 怎么办呢？
答案就是 “断舍离” ，只开最有必要的会，会⽽有议，议⽽有决，决⽽有⾏。 会议不在多 ，⽽在于精 ，每个 会议都要真正开出效果来。
项⽬中的重要会议
其实 ， “ 断舍离”是⼀种思维习惯 ，也就是说 ，你要有意识地选择，最适合项⽬现阶段状况的会议。
项⽬过程中有⼤⼤⼩⼩的会 ，我把这些会议汇总在了下⾯的这张图⽚中 ，你可以看⼀下。 实际上 ，这些会分 别服务于不同的⽬的。 之前我讲过复盘会、评审会 ，我们今天重点来看启动会、每⽇站会和项⽬周会。
实际上 ，只要掌握了这些类型的会议要点 ，其它类型的会议也就不在话下了。
启动会
启动会好⽐是誓师⼤会 ，⽤来快速地聚拢兵⼒ ，集中⼒量⼲⼤事！
我曾经经历过⼀个项⽬ ，因为战略调整和重组 ，这个团队的规模 ，迅速地从⼗多个⼈扩张到了⼀百多⼈。 这 个临时拼凑的百⼈军团 ，⼤多是⾃上⽽下从各个部⻔紧急征集来的。看起来⼈很多 ，但因为⻆⾊⾝份混乱 ， ⼯作习惯不同 ，团队内部存在着各种冲突和困惑。在这样的情况下 ，⼀场启动会就是⾮常有必要的。那么 ， 怎么做启动会呢？
启动会的⽬的是清晰⽬标，明确授权。 要做到这⼀点 ，你需要分三步⾛ ，分别是why、what和how。
其中 ，第⼀步why是最难讲好的。但实际上 ，只有充分理解了项⽬背景、⽬的和意义，才能更好地唤起团队的参与热情。
那个项⽬的启动会 ，我们特意邀请到⼤⽼板亲⾃上阵跟⼤家讲述项⽬背景。他从公司战略赛道的选择性聚
焦 ，讲到⾃⼰对这个事业的追求 ，话语中所传达出的重视、 关注和热爱 ，是让这个why真正打动⼈的核⼼要 素。
接着是what ，描绘蓝图，设定清晰的愿景 ，包括项⽬的三年⽬标、 五年规划 ，越清晰越好 ，为的是让团队 看到未来的样⼦。
你可以使⽤直接讲解的⽅式 ，也可以采⽤更加互动的做法。 ⽐如 ，我们曾经组织⼤家基于项⽬的背景信息⼀ 起共创 ，分组画画 ，共同畅想未来的愿景。这种画⾯感 ，会形成⼀种深刻的体感记忆 ，让⼤家在开始做事之 前 ，就先有了沉浸式体验 ，效果⾮常好。
最后⼀步是how ，也就是明确团队之间的责任分⼯以及合作公约。
对于⼀些新组建的团队来说 ，也可以加⼊⼀些破冰的环节 ，让⼤家打破边界 ，尽快建⽴新的协作模式。你还 可以留⼀些时间给重要的⻆⾊代表发⾔ ，⼤家的热情相互感染 ，会让⼠⽓空前⾼涨。这时 ，启动会的效果就 达成了。
关于启动会的内容 ，你可以从以下⼗个⽅⾯着⼿准备：
1. 项⽬背景
2. 项⽬⽬标
3. 项⽬范围
4. ⾥程碑计划
5. 主要⻛险
6. 组织架构
7. 责任分⼯
8. 流程机制
9. 沟通⽅式
10. ⽀持⼯具
其中 ，沟通⽅式指的是 ，会议的时间安排、频率及参与⼈员；⽀持⼯具⼀般是指项⽬组统⼀使⽤的任务管 理、⽂档管理、代码管理的⼯具。
需要注意的是 ，只有在新项⽬或新阶段准备启动，涉及到⽅向、⽬标、⼈员、职责的调整的时候，才需要开启动会来进⾏公开的澄清和授权。
每⽇站会
随着敏捷的普及 ，每⽇站会的概念也是深⼊⼈⼼。 然⽽ ，很多站会被当作是例⾏公事的汇报会 ，枯燥⽆味， 还有⼀些站会开得冗⻓且低效。
其实，开好站会的关键，是要还政于⺠。站会满⾜的是团队的⾃组织需要，⽽不是leader的监控需求。
那些把站会开得很持久的团队 ，往往已经形成了⾃我管理的氛围 ，团队每天会通过站会了解整体状态 ，并对 暴露出的⻛险和问题做出集体决策。
作为项⽬管理⼈员 ，你要引导团队不断建⽴和完善⾃⼰的规则 ，并在运⾏顺畅之后 ，把站会还给⼤家 ，让⼤ 家⾃⼰决定站会要怎么开。
早期我带过⼀个团队 ，经过反复尝试 ，⼤家决定把站会的时间放在午饭前的11:30开始。这样⼀来 ，团队成 员可以有相对完整、不被打扰的整个上午的⼯作时间。 另外 ，吃饭的动⼒也会让⼤家集体加速 ，从⽽保障站 会的⾼效。如果有⼀些争议性的话题没有解决 ，午饭时也可以继续讨论。
其实，真正⾃我管理的站会，除了团队成员⾃⼰决定站会时间之外，连主持⼈都是成员轮流来当的。 为了让 每个主持⼈都能把站会开好 ，有效把握会议节奏 ，经过⻓期的实践 ，我逐渐摸索出来⼀套 “ 三张牌”式站会 法。
站会开始时 ，主持⼈将红、 ⻩ 、绿三张牌分别发给所有的与会⼈员。在整个站会的过程中 ，任何⼈都可以随 时举牌来⾏使⾃⼰的权利。
. 举 “红牌” ：表⽰叫停谈话 ，避免过度的讨论和⽆结果的时间浪费 ，提⾼站会效率； 举 “⻩牌” ：表⽰打断讨论 ，进⾏提问 ，向发⾔者了解协同及依赖的信息；
举 “绿牌” ：这是⼀个token牌 ，代表每个⼈的发⾔权。每次只有1个⼈发⾔ ，按顺序来 ，将此牌归还给 主持⼈表⽰同步完毕。
当所有的 “绿牌”都已归到主持⼈⼿中 ，⽽且没有更多疑问的时候 ，站会就可以结束了。
这样简单的游戏规则 ，既可以帮助主持⼈有效地把握节奏 ，同时还把会议控制的权⼒和责任交给了与会的每 ⼀个⼈ ，任何⼈都可以对过度的讨论随时喊停 ，从⽽让站会在 “有⽤ ” 的同时⼜能保持 “⾼效”。
项⽬周会
通常情况下 ，对于10⼈以内的⼩团队来说 ，如果已经有了每⽇站会 ，就不太需要再另外设置周会了。
但是 ，当项⽬组的规模继续扩⼤ ，分成了若⼲的⼯作⼩组之后 ，你就需要利⽤项⽬周会 ，周期性地对项⽬的 各个⻆⾊ 、各条线的进展和⻛险做全⾯的检查了。
项⽬周会的⽬的，是解决整体计划层⾯、跨团队协同配合的问题 ，包括产品、运营、 市场、研发等环节。 由 于项⽬周会是⾯向各个⻆⾊负责⼈ ，甚⾄⾯向全员的全局性会议 ，所以 ，项⽬周会就天然地成为了⼀个最能 直接把控整体脉搏的地⽅。
项⽬周会的内容 ，除了常规的各⻆⾊进度和⻛险同步之外 ，你还需要根据项⽬组每个时期的整体阶段性重
点，来设置相应的环节，让⼤家清晰地感受到项⽬组明确的导向，也就是什么是当前最重要的。
⽐如 ，业务初创期 ，我们每周会⼀起关注业务数据的实时变化 ，针对有问题的部分 ，各个⻆⾊及时联动调整 策略；对于⼀些技术保障类的业务 ，则会每周重点关注客⼾反馈的⼯单数据和服务保障SLA的变化；对于
ToB类业务 ，会重点关注付费率、续费和丢单情况的最新变化 ，从⽽及时找到问题 ，快速联动解决。
为了⽅便你更好地操作 ，我跟你分享⼀些项⽬中常⻅会议的流程模版 ，包括需求评审会、技术⽅案评审会、 排期会、 站会、周会等 。
保障会议品质的关键
实际上 ，会议的品质 ，很⼤程度上可以看出⼀个项⽬团队的互动品质。把会开好 ，看上去很简单 ，但其实并 不容易。我的经验是 ，不要盯着会议的数量，⽽是要追求会议的品质 ，这⾥有三个基本要素。
1.明确会议边界
每个会议都有特定的主题和⽬的，并有明确的参会⼈员范围，这个就叫会议的边界。
你可以写下⽬前参加的每⼀个会 ，问问⾃⼰： “为什么要开这个会？会议的边界是什么？哪些议题适合在会 上讨论？”对于那些与主题不相⼲的议题 ，你要坚决舍弃。
我⻅过过很多会议 ，要么是流⽔账式的汇报状态 ，⼀⼤半⼈在那⼉玩⼿机、看电脑 ，要么就是进⼊了技术细 节讨论状态 ，过分纠结于细节 ，争执不下 ，早就偏离了会议主题。这些都是会议边界定义不清的问题。
想要彻底改善，项⽬经理要做好两个确保：
. 确保各部分的进展信息在会前统⼀提交 ，会议当场只说重要问题、⻛险及需要⽀持的地⽅； . 确保会议当场严格围绕主题开展 ，对偏离主题的讨论 ，及时叫停！
另外 ，参会的⼈ ，也应该是有边界的 ，并不是越多越好。相关问题的主要决策⼈，对这个问题有责任的相关⼈员、负责执⾏决议的⼈员是必须参与的。发送会议邀请时 ，你要明确哪些是必须参与的⼈员 ，并抄送那些 可以选择参加的⼈员。
2.建⽴会议规则
我们曾经做过⼀个 “会议⼩恶魔” 的游戏 ，就是让每个⼈想尽办法地破坏会议 ，借此去体会开好⼀个会 ，需 要哪些要素。结果我们发现 ，像迟到、拖堂、 开⼩会、看⼿机等⾏为 ，问题虽然不⼤ ，但是频繁发⽣的话 ， 就会⼤⼤地影响会议品质。
特别是对于⼀些周期性的常规会议 ，约定好会议规则是⾮常有必要的。 主持⼈要引导⼤家建⽴会议规则 ，对 于迟到、请假、拖堂、跑题等⾏为建⽴公约 ，并成为规则的守护者。
我⾝边有些做得好的项⽬周会 ，光是会议规则就已经迭代过五六个版本 ，从迟到红包、拖堂红包开始 ，到轮 流担任 “规则守护⼤使” 的⻆⾊ ，最后发展成由主持⼈判定违反会议规则者 ，即⾃动成为下次会议的主持
⼈……不得不说 ，这⼀招真的很管⽤ 。规则上的推陈出新 ，在活跃了氛围的同时 ，还共同构建出了⾼效的会 议品质 ，最终是对每个⼈的时间负责。
3.做好会后跟进
要想真正做到决⽽有⾏ ，最终靠的是有效的会后跟进 ，真正把决策落到实处。
会议主持⼈要及时汇总讨论的结果 ，并形成会议结论。对于⽆法当场确认的问题 ，⼀定也要进⾏记录 ，并明 确跟进⼈和完成时间。会后所有跟进事项，直接进任务系统，确保跟进到底。 同时 ，要在会议纪要的邮件中 明⽂呈现 ，下次会议统⼀回顾。
总结
今天 ，我给你介绍了项⽬中要开好的重要会议 ，以及保障会议品质的三个要素。
有同学给我留⾔说 ， ⾃⼰的团队是按照敏捷的框架来开会 ，每个会都开了 ，可最后团队都觉得流于形式 ，组 织者也觉得索然⽆味。
其实 ，这并不是敏捷⽅法的问题 ，流⽔不腐 ，⼾枢不蠹。没有什么东西是⼀成不变的 ，会议设计和流程 ，也 需要根据项⽬各阶段的情况做相应的调整。 既然项⽬的状态和团队的状态⼀直在变化 ，那就要根据这种变化 去动态调整 ，想清楚我们到底要开哪些会？不开哪些会？怎么把会开好？
只要你坚持只开最有必要的会，开真正⾼效且产⽣决议的会 ，⼤家不但不会排斥 ，还会积极参与 ，会后还会 有 “这么短时间就达成⼀致” 的满⾜感！所以你看 ，会议不是⽬的 ，借助会议去做好群体沟通 ，让⼤家看到 有效的进展 ，才是最重要的。
