1. 前言
我们统一每周周二开项目进度会议，每个项目的情况都不一样，有些问题就是需要讨论很久，所以时间是无法评估的。
我们不可能要求什么时间内一定要开完项目进度会议，只能说项目负责人需要知道项目进度会议的流程，并且逐渐按照流程执行。
一般情况下，每周开一次项目进度会议，任务通常不会太多，通常一次会议所需时间应该不会太长，但是我们把项目会议流程梳理之后就会发现，时间是大大超出我们预期的，如下所示：
- 项目进度情况（20 分钟）
- 问题反馈讨论（20 分钟）
- 任务验收
- 功能演示（20 分钟）
- 代码抽查（20 分钟）
- 文档查看（10 分钟）
- Bug 修复情况（10 分钟）
- 后续工作安排
- 任务安排（20 分钟）
- 加班情况（10 分钟）
项目人较多时，就需要 2 个小时左右；项目人较少时，也需要 1 个小时左右。我觉得项目会议时间在 1 - 2 个小时之内是可以接受的，但是开到 3 个小时以上就有点问题了。
要解决问题，最终还是要回到问题本身。项目进度会议时间过长，你的诉求到底是什么？最要解决的本质问题是什么？难道真的是项目时间过长吗？
那我直接规定每次开会不能超过某个时长就好了，没必要在这里纠结那么多。
所以说，本质的问题不在项目会议时间过长，而在于这个项目进度会议的时间是否产生了价值，是否有必要。
那我们要清楚，到底是哪些问题，容易导致项目进度会议时间拉长呢？
我想了一下，可能是这三种情况。
2. 没有在会前准备解决方案
有些问题没有在会前自己捋一遍，然后根据自己研究的结果，给出多个解决方案，并整理到文档中，然后发到项目讨论群里，而是自己闷头在研究，简单在脑里想了下，觉得想明白了，等到项目进度会议上再深入沟通。
在项目进度会议上，没有什么文档，大家就一起参与讨论了，只是口头沟通，然后七嘴八舌的，说什么都有，这样行不行，那样行不行？
讨论没有任何依据，只是凭感觉，反正你一句我一句，再加上一些闲话，最终浪费了很多时间。
正确的做法应该是，在会前要把自己研究或者想到的解决方案，整理到文档中，要列举至少两三个方案，并把每个方案的优说明缺点清楚，最后在总结一栏，把自己推荐的方案标明清楚，并说明你选择该方案的原因。
当然你可能会说，有些难题是在会上反馈出来的，哪有时间去准备解决方案文档，很多都是靠沟通交流得出的。
如果是这种情况，那么可以简单沟通一下，然后回去整理好解决方案文档，发到项目讨论群里，然后叫上相关人员在座位上过一下，然后把最终结论补上文档即可。
3. 无关话题太多以及范围过大
有时在项目进度例会上，很多时候沟通是没有依据的，也就是没有围绕项目当前的情况进行，总是一连串旁枝末节的话题，一个接一个没完没了。
你说这些话题有必要讨论吗？
当然有的，但是要看当前项目的情况和时机。比如有些规划是大半年以后的，有些甚至是几年后都不一定要做的，这些话题进行深入沟通可以增长个人的知识面，但是在当前没有什么意义，完全可以在私底下去了解。
如果觉得很有用处，可以在了解之后，叫上几个人在座位上探讨一番，而不是在项目进度会议上。
比如讨论 App 的功能，说着说着，又说到 Flutter 最近好像不太平，Flutter 组又裁员了，然后还在 GitHub 上面搞了一个社区的分支，单独维护，然后说不计划合并到 Google 的主分支上了，然后又讨论 Flutter 是不是要完蛋了？那我们后续开发 App 要换不要技术方案？那老项目要怎么维护？Android、iOS、鸿蒙、微信小程序这些跨平台要怎么解决等等。
完全没完没了，这些讨论当然有意义，但是，在项目进度例会上进行讨论，真的太不划算了。
正确的做法应该是，紧跟当前项目核心问题进行讨论。比如上面的例子，App 的某个功能，在使用或实现上是否出现了问题，以及怎么解决这些问题？不要把话题扩散太广，避免违背了这个会议的初衷。
这个会议的目的是要解决项目当前的问题，不是新闻热点讨论会议。
4. 会议主持人没有做好把控
上面的问题，虽然源头都是会议前没有准备问题的解决方案文档、无关话题太多以及范围过大，但是，真正可以解决掉这个问题的，当然还是要回归到项目负责人对会议开展的把控上。
一看到有任何苗头，就可以立马打断，把话题拉回项目自身，而不是放任不管，浪费白白太多时间。
项目进度例会，我们担心有些人不说，但又怕有些人说太多，所以还是要灵活把控这个尺度，鼓励少说的多说，控制说多的少说，但目的是一致的，为了能及时暴露项目当前存在的问题，以及讨论出解决这些问题的方案。
至于无关紧要之事，可以会后私下里沟通。
5. 总结
项目进度会议时间过长的问题，最终还是要回归到这个问题的诉求上，也就是说，如果我们能够做到会议前准备好要讨论的问题的解决方案文档、减少无关话题、项目负责人做好会议进行的把控工作，那么应该是可以解决这个问题的。