本文共 3496 字，大约阅读时间需要 11 分钟。

开会是有价值的

开会是有价值的，软件项目中有不少会议，其实是有价值所在，比如：

• 评审会议：通过会议，可以让产品设计或者架构设计在确定之前，收集大家的意见，以及发现问题
• 每日站立会议：可以及时了解项目的进度，了解当前的困难的瓶颈，及时调整计划，解决问题。另外在会议上，每个人都要当众讲一下做过的事情和计划要做的事情，这也是一种无形的监督和约束。
• 项目立项会议：可以创建一种仪式感，让每个人都知道项目的关键信息
  • 项目目标：这项目是要干什么的，达到一个什么目标；
  • 项目里程碑：项目的开始结束时间，项目的阶段划分，以及各个阶段的时间点；
  • 角色分工：项目成员的分工和角色是什么，每个人知道自己的任务是什么，知道遇到问题该找谁；
  • 流程规范：项目开发的主要流程是什么，基于瀑布还是敏捷。
• 项目总结会议：团队成员可以一起总结一下项目的得失，把经验总结下来，帮助团队在下一次做的更好。

开会是有成本的

开会的成本，就像房间里的大象，显而易见而很多人却有意无意无视它的存在。

我们做个简单的数学计算，假设一个程序员月薪一万元，如果他每天四分之一的时间在开会，那就相当于公司每月花了 2500 元在会议上。

这还只是一个人的成本，如果开会的人多，那么仔细算算，整体的会议成本其实很夸张的。所以我想说的第二个问题就是：开会其实是有成本的，而且还不低。

那什么样的会议是有效率的？

会议是不是有效率，取决于它创造的价值是不是高于其成本。

• 像每日站立会这样的会议更有效率，其时间短、人数少，所以成本低，创造的价值高于其成本。
• 而人数多，又偏离会议主题的讨论会则没有价值，这是因为人数多时间长，导致会议成本高，而其创造的价值远远不及成本。

那为什么还有那么多低效率的会议？

• 因为有的会议，就不是为了创造价值。你是砍柴的，他是放羊的，你和他聊了一天，他的羊吃饱了，你的柴呢？
• 还有很多会议，是因为组织者和参与者，都没有意识到开会其实是有成本的，所以浪费了成本还不自知。不过这种情况还好，还是可以想办法改进的。

接下来，我们来看看如何提高开会效率，破除避免白天开会，晚上还要加班写代码的节奏。

如何提高开会效率？

其实提高开会效率、提升开会价值的方法，就跟软件项目金三角的理论一样，只要从两个角度去想办法：减少开会的成本，增加开会创造的价值！

在具体探讨这两类方法之前，我们先要认识到一个前提：那就是要让大家意识到开会是有成本的，如果开会创造的价值不能大于其成本，就是浪费。

就像金三角理论，你得先让老板、项目经理明白三条边不可能都占，才好去沟通讨论。要提高开会效率，也需要大家先有这个意识，才能在具体措施上达成一致。

那么，有哪些方法可以减少开会的成本呢？

砍掉一些没价值的会议

在日常工作中，还有很多会议其实并没有什么价值的。如果一个会议符合这些标准，你就要慎重考虑参加了：

• 没有目标的会议。大家都在随意发散，完全没有主题；
• 不能形成决策，没有会后行动。如果一场会议看完后都没有什么结果，那跟没开都没啥差别；
• 你属于可有可无的角色。如果一个会议，跟你其实没什么关系，你无法提供有效的反馈，对你也没什么价值，只不过是被人拉过去开会的，那不如把这个时间用来做一点对项目更有价值的事。

所以，你可以在每次要接受一个会议邀请之前，先问自己两个问题再做决定：这个会议我真的有必要参加吗？以及，有其他方式可以替代吗？

能用技术解决的就不用去开会了

减少参与会议的人

会议的成本和两个因素相关：一个是人数，一个是时间。如果减少人数，就能减少成本。

减少人数好处还在于，人一少，每个人都会更投入，也更有效率，所以往往时间反而会少产出会高。而且，如果会议上要形成一些决议，人越多越难做决策，人越少越容易达成一致。要想有决议的话，先开几个小会，达成一致后再开大会，大会更多只是宣布一个结果。

像谷歌和 Facebook，他们对于会议的态度就是能不开就不开，无关的人不参与。Amazon的规则也很简单：一场会议的人数，最多订两份批萨，如果超出这个规模，说明这个会议的人数太多了。

缩短开会时间

减少开会成本的另一个方法就是缩短开会时间。缩短开会时间有很多成熟可靠的方案可以选择。

比如说站立会议，通过站立的方式逼着大家快点结束。

另外，麦肯锡开会上有些做法也值得借鉴：

• 每个成员有一张黄牌，用于喊停其他人会议中发散讨论无意义的话题；
• 有人控制节奏，大家快速发言；
• PPT 不超过 3 张，鼓励大家预先准备，多讨论。

会议有人主持，当话题开始发散的时候，果断制止，放到“停车场问题”环节，也就是会议的最后专门讨论。

提升会议所创造的价值

如果能有效提升会议产出，也一样可以达到很好的效果。

比如说，每个会议要有明确的目的和主题，所有的讨论都要围绕会议目的展开。当你发现会议上一些问题的讨论偏离了会议的主题，例如一个需求评审会，结果架构师在讨论技术细节，这就完全偏离了主题。

你就应该站出来提醒一句：“现在既然是讨论需求，不如先不讨论技术上的问题，等到需求确定了，我们后面再慢慢讨论技术问题。”或者说：“不如这个问题我们另外组织一个会议讨论。”

还有开会后，要有明确的结论，有后续的待办事项，落实到人，对待办事项有跟踪。

有时候一些没什么价值的会议，又必须要参加，我一般会参会前，用一个本子把一个技术难题、或者一篇博客主题，写下来。（中间摸鱼）

总结

会而不备、会而不议、议而不决、决而不行、行而无果本身就失去了开会的意义。

会前准备是相当重要的，组织会议或者抛出问题的人，应该对整个会议的内容有深刻而清醒的认识，并且将思路整理成文（Word、PPT等），给参与会议的人一个明确的引导，让会议一开始就能很快进入状态，不需要过多的预热

另外，没有目标的会议不参加，没有会议资料的不参加，没有决策人参加的会议、不知道为啥邀请自己的最好不参加

其他：整个项目开始前到项目完全结束，一般都要开那些会议呀？目的是什么？

项目启动会议

通常在项目启动后，会有一个正式项目启动会议，俗称 Kick off meeting，通过这个项目，你可以了解几个关键信息：

• 项目目标：这项目是要干什么的，达到一个什么目标；
• 项目里程碑：项目的开始结束时间，项目的阶段划分，以及各个阶段的时间点；
• 角色分工：项目成员的分工和角色是什么，每个人知道自己的任务是什么，知道遇到问题该找谁；
• 流程规范：项目开发的主要流程是什么，基于瀑布还是敏捷。

瀑布模型各个阶段的评审会议

瀑布模型因为阶段划分清楚，每个阶段都有明确的产出，所以通常每个阶段都有评审会议，典型的像需求评审会议和架构设计评审会议。这种会议主要目的是用来收集意见。

瀑布模型各阶段的说明会议

在评审会议结束后，需求设计、架构设计最终确定后，通常还会组织会议对需求设计和架构设计做说明，所以会有：需求设计说明会和架构设计说明会。

进度报告会议

无论是采用瀑布模型还是敏捷开发，通常都少不了进度报告会议。只是瀑布模型通常是以周为单位的周例会，而敏捷开发是以天为单位的每日站会。可以通过会议，了解项目的进展，了解当前的困难和瓶颈，及时调整计划，解决问题。另外在会议上，每个人都要当众讲一下做过的事情和计划要做的事情，也是一种无形的监督和约束。

项目计划会

在敏捷开发中，每个 Sprint 开始前都会有一个 Sprint 计划会（Sprint Planning），决定当前 Sprint 要做哪些内容。在瀑布模型中，每个版本开始之前也会有项目计划会。有所不同的是，瀑布模型通常是项目经理和开发经理、测试经理等少数几个人决定的，而敏捷开发中则是全体成员一起针对 Backlog 的内容进行选取和打分。

产品演示验收会

在瀑布模型中，项目在测试通过后，会对客户有一个产品演示验收的会议，向客户展示工作成功。敏捷开发中也有 Sprint 评审会（Sprint Review），在每个 Sprint 结束后，像客户演示当前 Sprint 成果。

项目总结会议

在项目结束，通常项目经理需要组织一个总结会议，希望大家能在会议上总结一下项目的得失，把经验总结下来，帮助下一次做的更好。在敏捷开发中，更是每个 Sprint 都会有一个Sprint 回顾会议（Sprint Retrospective）。

一对一会议

虽然项目中有每日站会或者周例会这种让项目成员可以反馈问题的方式，但是对于很多人来说，并不愿意在很多人面前说太多，但是如果是一对一的私人对话，则更愿意反馈一些更实质性的内容，从而项目经理或者管理者能了解到更真实更准确的信息。

转载地址：https://blog.csdn.net/zhizhengguan/article/details/84840781 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！