很多项目经理每天最耗时间的一件事，就是开会。
周一项目例会，周二需求会，周三问题协调会，周四客户沟通会，到了周五还要再开一次周总结。
一周下来，会议开了不少，真正推进的事情却未必有多少。
所以项目会议真正的问题，很多时候不是开得太多，而是会议没有变成具体行动。
真正有效的项目会议，我更建议直接抓住一套很简单的逻辑：
会前3问、会中4定、会后2追。
会前先把问题找出来，会中把事情定下来，会后把结果追到底。
这样会议才是在推进项目，而不是大家定期坐在一起交换信息。
一、会前先问清楚3件事
很多低效会议，从会议邀请发出去的那一刻，其实就已经注定了。
标题写着：“XX项目周例会。”下面拉了十几个人。
至于为什么开、重点讨论什么、大家提前准备什么，没有人知道。
到了现场以后，项目经理只能从头开始问：
“研发这边先说一下进度吧。”
研发再打开自己的表，讲完以后测试接着讲。
最后一个小时过去，真正需要大家一起决策的问题可能只讨论了十分钟。
所以项目会议第一步，不是先定会议室，而是先问三个问题。
第一问，这个会到底要解决什么？
“同步一下项目情况”通常不是一个好的会议目标。
因为项目里可以同步的事情太多了。
- 需求进展可以同步，
- 开发进展可以同步，
- 测试问题可以同步，
- 客户意见也可以同步。
如果这些全部放在一个会上，最后很容易变成流水账。
真正有效的会议目标最好具体一点。
比如：
- 本周3项延期任务怎么处理？
- 月底上线还有没有风险？
- 客户新增需求到底接不接？
- 测试阶段连续出现的问题，需要不需要调整研发资源？
- 供应商交付晚了5天，后面的安装计划怎么改？
当会议目标明确以后，参会人也会知道自己为什么来。
这也是为什么我比较建议项目平时就把任务和进度放进统一系统里，而不是等开会的时候再临时收集。
比如在简道云项目管理系统里，一个项目先往下拆成阶段和具体任务，每项任务维护负责人、计划开始时间、计划完成时间和当前状态。
这样项目经理准备会议时，不需要先在群里发一句：
“大家下午之前报一下进度。”
直接先看项目。
哪些任务已经延期，哪些临近截止，哪些一直没有启动，哪些关键节点正在被压缩，基本都能先筛出来。
会议应该围绕异常开，而不是围绕所有事情开。
如果20项任务里17项都正常，就没有必要让17个负责人轮流讲一遍“目前正常”。
真正值得开会的，是剩下那3项不正常的。
第二问，会前哪些信息必须准备好？
很多会议特别浪费时间，是因为本来应该提前准备的数据，全部搬到了会上查。
领导问：“这个任务原计划什么时候结束？”
项目经理翻Excel。
研发问：“测试是不是已经开始了？”
测试再去找记录。
客户提到一个需求变更，所有人又开始回忆当时到底怎么说的。
这种会议当然会长。
所以会前至少要把跟本次问题相关的几个信息准备清楚：
- 原计划是什么，
- 现在实际到哪一步，
- 差了多少，
- 影响哪个节点，
- 目前是谁负责。
如果是项目进度会，我一般会先看项目管理系统里的任务状态和计划时间。
比如发现一个接口开发任务原计划20日完成，现在已经19日，状态还是进行中。
单看“进行中”没有问题，但继续往下看，后面22日就要进入联调，真正留给开发和自测的时间已经非常少。
这时候这个任务即使还没有正式延期，也应该进会议议题。
所以项目经理会前真正需要做的，不是把所有数据整理成一份漂亮PPT。
而是提前判断：
哪些事情现在不处理，几天以后最可能变成问题。
第三问，哪些人真的需要来？
还有一种会议很常见。
一个项目二十几个人，开会直接全拉进来。
研发、测试、产品、采购、实施、业务、财务全部在线。
最后真正讨论的是一个接口问题。
财务坐了40分钟，一句话没说。
这种做法表面看信息透明，实际对团队效率伤害很大。
真正需要参加会议的人，通常就三类。
- 一类是问题负责人。
- 一类是需要做决策的人。
- 还有一类是会议结果会直接影响到的人。
其他人如果只是需要知道结论，会议结束以后同步结果就行。
项目经理要慢慢从所有人都来听变成真正需要的人来解决。
二、会中第一件事，先定问题
会开起来以后，最怕大家一上来就开始表达观点。
- 业务说客户要求必须月底上线。
- 研发说需求一直变，月底不现实。
- 测试说目前质量风险很大。
每个人说的都没错，但说了十分钟以后，问题到底是什么还是没讲清楚。
所以会议开始以后，第一件事应该先定问题。
不要说：“开发进度有点慢。”
而是说：
“接口联调原计划8月18日完成，现在还有3项接口没有通过，已经影响原计划20日开始的系统测试。”
这两句话看起来差不多，管理意义完全不同。
前一句是感觉，后一句是事实。
项目会议里很多争论，其实都来自大家讨论的根本不是同一个问题。
研发讲的是接口已经开发完成。
测试讲的是接口还没有通过验证。
项目经理如果不把事实重新拉到同一条线上，双方很容易争半天：
“我们已经做完了。”
“你们根本没做完。”
这时候我更倾向于直接打开项目管理系统里的对应任务。
看原计划什么时候完成，现在处于什么状态，负责人是谁，后续依赖什么任务。
数据放出来以后，讨论会简单很多。
不是追究谁说得对，而是先确认：
项目现在到底发生了什么。
只有问题定义准确，后面才有资格谈解决方案。
三、第二件事，一定定到具体负责人
项目会议里最危险的一句话是：
“这个事情研发跟一下。”
听起来已经安排了，实际上等于没安排。
研发有五个人，到底谁跟？
测试说：“这个问题我们跟研发一起确认。”
- 最后是谁先发起？
- 谁推动？
- 谁负责拿结果？
如果这些不明确，会议结束以后最容易出现的就是：
大家都知道有这件事，但没人认为自己是第一责任人。
所以任何会议行动项，都应该落到具体的人。
比如：
- 接口异常由研发A负责排查。
- 客户数据规则由业务B负责确认。
- 测试环境由实施C负责准备。
不是部门负责，而是具体负责人负责。
在项目管理系统里，这类会议结论最好不要只留在会议纪要里，直接转成任务。
把任务挂到对应项目下面，明确负责人。
这样散会以后，大家看到的不是一段：
“会议要求研发尽快处理接口问题。”
而是一项明确任务：
接口异常修复——负责人张三。
项目经理后续再看项目，也不需要翻聊天记录找昨天到底安排给谁了。
任务是谁的，一眼就能看到。
会议纪要负责记录，项目任务才负责执行。
这两件事最好别混。
四、第三件事，所有事情都要定时间
有了负责人还不够。
如果会议结论写的是：“张三尽快解决。”
这件事大概率还会继续拖。
因为尽快在每个人心里的定义都不一样。
项目经理觉得今天下班前，负责人理解成这周之内，等到了周五，双方都觉得自己没问题。
所以会议行动项一定要有明确截止时间。
比如：
- 接口异常20日下午6点前修复。
- 测试21日上午完成二次验证。
- 客户规则最晚21日中午确认。
时间定清楚以后，事情才真正进入项目计划。
我一般会把会议产生的新任务直接放回简道云项目管理系统里，把负责人、计划完成时间和任务状态一起确定。
这样项目经理会后真正需要看的就不是：
“我昨天是不是忘了催张三？”
而是系统里有哪些任务已经临近截止，有哪些已经超过计划时间。
尤其项目一多以后，这个差别很明显。
如果一个项目经理同时管三四个项目，靠脑子记会议行动项基本不现实。
今天A项目开完留下5件事，明天B项目再留下4件事，后天客户会又多3件，一周下来十几二十项行动任务。
只要没有统一入口，很快就会散落在会议纪要、微信、Excel和项目经理自己的待办里。
所以会议真正数字化，不是把会议纪要搬到线上，而是把会议形成的行动项直接接回项目执行。
五、第四件事，定优先级和影响
还有一种会议，行动项倒是定了不少。
十几个问题，每一个都有负责人，每一个都有截止时间。
看起来特别规范。
但项目经理回去以后还是很忙，因为不知道先追哪个。
项目里的问题从来不是同样重要。
一个页面按钮位置不对，和核心接口联调失败，显然不是一个级别。
一个普通文档晚一天，和客户验收节点晚一天，也不是一回事。
所以会上除了定“谁来做、什么时候做”，还要继续定一件事：
这个问题到底会影响什么。
至少看几个方面。
- 会不会影响关键里程碑？
- 会不会影响后续任务启动？
- 会不会影响最终交付时间？
- 是不是需要其他部门资源？
- 要不要升级给领导决策？
例如测试发现10个问题。
其中8个是页面展示问题，2个会直接导致核心流程跑不通。
项目经理真正应该优先盯的显然是后面两个。
在项目管理系统里平时看任务时，也可以结合计划完成时间、状态、项目阶段和关键节点一起判断。
不要看到红色就全部追。
而是先看：
哪个红色最可能影响交付。
这也是项目会议和普通工作沟通最大的区别。
会议不是为了把所有问题都聊完，而是要帮团队把有限的注意力放到最重要的问题上。
六、会后第一追，只追行动项
很多项目经理会议开得其实不错，问题定了，负责人也定了。
真正失败在会后。
开完会第二天继续忙别的事情，过了三天突然想起来：
“上次那个接口问题怎么样了？”
负责人说：
“还没来得及处理。”
项目经理一下着急了。
这种情况本质上还是会议和执行断开了。
所以会后第一件事，就是追行动项。
但追不是每天私聊负责人问一句：“做了吗？”
如果每项任务都要靠项目经理手工催，会议管理最后又会变成项目经理个人记忆力管理。
更好的方式是让负责人自己更新任务。
比如昨天会上确定：张三20日完成接口修复。
这项任务已经进入简道云项目管理系统以后，张三处理过程中更新状态。
项目经理再从项目层统一看：
- 哪些已经完成，
- 哪些正在进行，
- 哪些已经超过截止时间。
这样项目经理会后的角色就变了。
以前是一个一个去收进度，现在是看异常。
正常推进的事情不要反复问，真正卡住的事情再介入。
项目经理才能从大量低价值催办里抽出来。
七、会后第二追，别只看已完成
最后一个动作，是很多项目最容易忽略的。
负责人说：“这个事情已经处理好了。”
项目经理直接把任务关闭。
其实很多事情的完成，只是负责人自己认为完成。
比如：
- 研发说Bug已经修复，还要看测试有没有验证通过。
- 供应商说货已经发出，还要看现场是不是真的收到。
- 客户说需求已经确认，还要看确认结果有没有真正进入后续开发。
所以会后第二追，追的是结果。
不是问：“做了没有？”
而是问：
“这件事产生了我们需要的结果没有？”
在系统里也一样，任务状态不要只停留在负责人填了已完成。
关键事项最好能继续有结果确认。
例如接口修复以后，测试验证通过，这个问题才真正关闭。
设备到货以后，完成签收或者验收，采购交付才算结束。
如果问题后面还有下一步任务，也应该继续接到后续计划里。
这样整个过程才能真正跑成：
发现问题 → 明确责任 → 制定行动 → 执行处理 → 验证结果 → 关闭。
项目会议真正需要闭的，就是这一圈。
八、真正有效的会议，其实就9个动作
做项目时间久了会发现，会议效率低，通常并不是大家不会沟通。
而是会议前、中、后三段没有接起来。
- 会前没找准问题，会上自然什么都聊。
- 会上没形成行动，会后自然没人执行。
- 会后不持续追踪，下次开会又重新从头讲。
所以一套真正能长期用的项目会议方法，其实并不复杂。
会前先问3件事：
- 这个会解决什么问题？
- 哪些信息要提前准备？
- 哪些人真的需要参加？
会中定4件事：
- 问题到底是什么？
- 谁负责？
- 什么时候完成？
- 优先级和影响是什么？
会后再追2件事：
- 行动项有没有按计划推进？
- 最后结果有没有真正闭环？
如果平时再把项目、任务、负责人、计划时间和状态统一维护在项目管理系统里，会议这件事本身也会轻很多。
会前不用重新收数据，直接找异常。
会上不用另外记一套行动项，直接把结论落成任务。
会后不用靠项目经理逐个催，直接看哪些任务已经延期、哪些关键事项还没有关闭。
做到最后，项目会议就不再是一场信息汇报，而会变成一套很清楚的项目推进机制：
会前用数据找问题，会中把问题变成行动，会后把行动追到结果。
这样的会，才值得开。
热门跟贴