这几年项目进度例会的模式，都是按照上篇《18-过进度方式一：项目负责人进行全部功能演示》的方式进行的，其目的也在上篇说明清楚了，都是从项目负责人的能力提升方面考虑的，其会议流程是这样的：
第一步，项目负责人把当前项目情况进行汇报，然后重点问题说一下。
第二步，每个项目成员在自己的座位上，说一下上周做的事情，下周计划做什么，遇到什么问题。
第三步，散会。
但是，不同的阶段关注的重点不一样。
在项目进度例会中，对当前所做的工作进行验收，是很重要的一环，这些也在《16-项目的任务质量如何保证》中，把前因后果也说明清楚了。
本篇主要是探讨让项目负责人把全部功能进行演示和让项目成员依次汇报任务进度和演示，这两种方式不同之处在哪里？
首先，我们要知道，参加会议的人，什么样的心态都有。有的人现在遇到了很多问题，亟需在会议上反馈出来，然后帮助他解决这些问题；有的人觉得我现在忙得很，又天天开会，真烦，能不能少开一点、少说一点，让我赶紧忙完，要不然就得加班了；有的人觉得真好啊，最好开一整天，又可以摸鱼了，等等。在这些心态之下，各人的反应也会不一样。但更深层的一点是，多一事不如少一事，你要让他主动去说，那太难了，你问了才会说，不问就不说，甚至你问了，也可能因为性格等各方面的原因，都不太愿意说太多。加上大部分人都在会上刷手机，不会有心思听那么多的。
在这样的情况之下，让项目负责人把全部任务进度进行汇报并演示可验收的功能，很难覆盖到其他项目成员。他们本身不会觉得和这个会议有什么太大的关系，反正就是听一听，看一看手机，到了时间散会就完事儿。也许有些人可能有问题要反馈，但是他不会主动去提。
所以，项目进度例会的整体流程就要进行调整：
第一步，项目负责人要对项目当前的情况进行汇报，比如延期风险高不高？有什么重点问题？说一下，同步下信息，以及后续要注意哪些方面，等等。
第二步，就是要项目成员依次到前面来，而不是在自己座位上。把自己上周完成了哪些任务说一下，哪些任务进度怎么样也说一下，然后是演示一下自己开发的功能或者一些技术文档，最后就是遇到了哪些问题？需要现在就讨论和解决，然后就是下周计划做什么？把这些信息都记录在会议记录文档上面。一方面可以减少项目负责人需要全面深入细节的工作；另一方面，可以侧面给项目成员一点压力。因为每次项目进度例会都要说一下工作内容，你如果上周完全都不用心，那么工作自然没什么产出，这样你总不能胡编乱造吧。冥冥之中，不需要谁整天盯着你工作，你自己清楚，无形之中，就会有约束力，也减少了项目负责人的管理工作。
第三步，项目负责人把项目成员过进度中反馈的待解决问题，都记录到会议记录文档里面。下次项目进度例会，会看下待解决的问题是否已经解决。
第四步，项目负责人要根据当前项目进度情况，再次强调要重点关注的点，然后评估下是否需要加班。如有需要，进行加班安排。
第五步，散会。
相信按上面这个流程，可以有效解决项目成员在会议上没有深入参与的问题，并且能起到日常工作的一些约束，加强自我管理的意识，达成期望的工作目标。