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. 总结
项目进度会议时间过长的问题,最终还是要回归到这个问题的诉求上,也就是说,如果我们能够做到会议前准备好要讨论的问题的解决方案文档、减少无关话题、项目负责人做好会议进行的把控工作,那么应该是可以解决这个问题的。