见过一种项目组，天天加班，永远忙不完。
但你仔细看他们在忙什么，会发现一个奇怪的现象：
20个人坐在一起开视频会议，有一个人投屏，屏幕上是一份PPT。其他19个人盯着屏幕，七嘴八舌地说：这页标题改一下，这个颜色换掉，这里的逻辑顺序不对……
然后那个负责改的人，一边听一边改，改完大家再看，再提意见，再改。
一份PPT，改了两个小时，散会。
第二天，继续开会，继续这样改。
这不是在工作，这是在用20个人的时间，产出一个人能做的事情。
01·这叫串行陷阱
项目管理里有一个基本概念，叫并行和串行。
并行是大家同时做不同的事，效率是叠加的。串行是大家排队做同一件事，效率是单人的。
正常的20人项目组，合理分工之后，理论上可以同时推进20条工作线。
但上面那种开会方式，把20个人的时间全部串行化了——所有人的产出，卡在那一个改PPT的人身上。不管会议室里坐了多少人，整个项目组的产出速度，等于一个人。
这是效率最低的工作方式，没有之一。
更可怕的是，这种方式很容易让人觉得"我们在认真工作"。毕竟大家都在开会，都在参与，看起来很忙。但忙和有产出，是两回事。
02·除了改PPT，还有哪些常见的串行陷阱
改PPT只是最典型的一种，项目组里类似的低效做法还有很多。
全员参与的需求评审会
需求评审，把所有人拉进来，从第一页讲到最后一页，每个人坐在那里听，跟自己相关的部分可能只有20%，另外80%的时间全在陪听。
正确的做法：按模块分组评审，每个人只参与和自己相关的部分，其他人同步去做别的事，最后汇总有争议的问题集中讨论。
集体讨论细节问题
一个技术实现的细节问题，本来两个人就能拍板，却拉了七八个人开会讨论，大部分人对这个问题根本没有背景，就这样陪着耗了一个小时。
正确的做法：问题先定位清楚，明确哪几个人的意见是真正有决策权的，只叫这几个人，其他人不用参与。
逐行审阅文档
团队一起开会，有人投屏，逐段读文档，读一段讨论一段。几十页的文档，读完要两三个小时。
正确的做法：提前发文档，各自阅读，各自在文档里批注意见，会议只讨论有分歧的地方。会议时间从两小时压缩到三十分钟，还能讨论得更有质量。
一件事反复开会确认
一个决策，今天开会讨论了，明天又开会再确认一遍，后天还要再过一遍。不是决策变了，是大家不确定上次有没有达成共识。
根本原因是会议没有书面记录，没有人明确宣布"这件事决定了，结论是XX"。导致每次散会，大家各自带着不一样的理解离开，下次又要重来。
等人等到齐再开始
会议定了10点，10点有人没来，等。10点10分还有人没来，继续等。等到10点20分，人差不多了，开始讲，然后再花10分钟把背景重新介绍一遍给晚来的人听。
这种习惯，每次会议浪费15-20分钟，一周5次会，一个月下来是将近10小时。
03·回到PPT这件事，正确的做法是什么
说回开头那个改PPT的场景。
正确的做法不复杂，分三步。
第一步，拆分任务，各自认领。
PPT有20页，根据内容模块分配给不同的人，每人负责自己那几页。明确责任人，明确交付时间，散会，各自去改。
每个人只改自己负责的部分，不用等别人，不用看别人改，并行推进。
第二步，有争议的地方，快速记录，不在会上解决。
各自改的过程中，如果某个地方拿不准，或者发现和别人负责的内容有冲突，先记录下来，不要当场开会讨论。
等大家都改完了，把争议点汇总，开一个短会，只讨论有争议的部分，快速拍板，散会。
这个会可能只需要15分钟。
第三步，汇总整合，形成终稿。
指定一个人负责把各自的版本整合成一份，统一格式和风格，完成。
这个流程走下来，20个人的时间全部被解放出来，真正并行工作。最后一个短会只解决有争议的问题，效率远比大家坐在一起盯着改高得多。
04·为什么明知低效，还是这样做
这个问题值得想一想。
一个原因是习惯。大家都这么干了很多年，没有人提出来说这样不对，慢慢就变成了默认的工作方式。
另一个原因是安全感。大家一起看着改，每个人都觉得自己参与了，出了问题责任是集体的，不是某一个人的。各自分工去改，万一某个人改出了问题，责任就清楚了，很多人不愿意承担这种清晰的责任。
还有一个原因是领导在场。领导参加了会议，大家就觉得这件事很重要，要认真对待，于是把所有人都拉进来，显得这件事被充分重视了。
但这些原因，解决不了效率问题。长期加班的项目组，很多不是因为工作量真的很大，而是因为工作方式有问题，把时间用错了地方。
写在最后
项目经理有一个很重要的职责，是设计团队的工作方式，而不只是推进项目进度。
如果你的团队正在用串行的方式做本来可以并行的工作，那不管加多少班，瓶颈都在那里。
改变工作方式，比催大家加班有用得多。
PMThink · 资深项目经理 · AI实践者 公众号：PMThink | 网站：PMThink.cn
