第四篇内容分享覆盖以下几个方面：项目例会场景还原、怎么解决例会的问题。全文约1800字，阅读时间约4分钟。

项目例会是保障 汇总团队进展、保证关键信息对齐、确定下一步工作等事情的关键会议，无特殊情况一般每周一次。由于这个会议的频次比较适中，在大多数的项目中，这个会议是反映项目现状的重要途径。因此，如何开好项目例会、控制会议节奏、让这些目标都能切实达到是项目经理的责任之一。

场景还原：

项目X周例会参会者：四个技术小组Leader（ABCD）、产品线负责人、产品经理、项目经理。

例会目的：核对各组进展、确认需要哪些支持、有什么风险，项目上的其他信息（除研发外）需要同步给研发的（市场、采购、财务、人力等等），下一周的工作是否有调整，月度计划、项目里程碑是否能正常进行。

现场：ABCD依次发言，进度汇报方式各不相同。A用Excel展示需求完成情况；B用Word总结组内上周工作情况；C用Excel展示每个任务的完成度，但是看不到任务的输出物是什么；D用Project展示组内任务、需求情况，关联到由哪位研发负责，并提出人力紧张需要补充人员的需求。

以上四种进展汇报相信在大多数项目中都出现过，这些方式有什么问题？当我把这些方式放到一起后，相信大家一眼就能看出它们各自有各自的优点，但都无法完全满足需求。所以这是我们管理项目例会的第一个问题：如何管理好大家的进度汇报。

进度汇报都有哪些维度、因素？1、计划任务是什么；2、由谁来负责？交付物是什么？完成的衡量标准是什么（是代码自测通过？是文档输出评审通过？还是其他可测的指标达标）？3、进展怎么量化：是已完成feature数/feature总数？还是分解成任务之后已完成task数/task总数？还是人为估计剩余需要的工时占比？4、用什么方式呈现？Excel、Word、Project都是不错选择，但需要统一。只有以上四个因素都统一起来，那么整个进度汇报才能体现真实进展，否则各家说各家话，无法统一到一个交流平台上，进度自然也无法统一到一个平台。项目经理要做的就是跟大家沟通对齐进度汇报的统一性和要求，并督促大家改正，如果改正过程有任何问题，项目经理都应当做好支援和解释、讲解等工作。

现场：ABCD顺序发言中间，因为某一需求测出了BUG（BUG持续了一段时间，还没找到原因），大家开始争执不休，有开始互相推诿的趋势。

这种状况在项目上面也很常见，一言不合就开撕。参加过上百次例会的我，大致统计过项目例会中这种争论占用的时间：在没有项目经理协调、聚焦项目例会重点的情况下，这种争执可以占到例会时间的60%，而且一旦没有引导，这个BUG最终会成为三不管地带，大家都不愿为此负责，恶性循环；如果项目经理能快速反映，分配BUG第一责任人，引导焦点到项目例会关注点，则争执时间将至少降低30%，而且问题会有人跟进，就不愁解决。当我们面临这个状况的时候，一定要牢记例会的目的，问题处理的细节讨论、问题归属是需要单独组会讨论的，放任问题的细节讨论一方面参会人员集中度会下降，效率下降，会议质量和权威也受影响。

那么这种问题出现时，有什么好的方法呢？我之前采用过一个方法：第一责任人制度。这个制度说的是，当出现问题时，第一个发现问题的人，自动默认成为问题的跟进人，直到发现问题需要下一人才能解决，那么这个问题就转交下一人跟进。第一责任人分析问题有功，项目评价分+1。如果转交过程有任何问题，项目经理进行协调，如果问题归属还有不清晰，那么找技术Leader进行判断。凡是推诿责任、不配合的人员，项目评价分-1。每月发布个人评价分值，Top3可以享受专属茶歇以及邮件通报全员（通报时只显示前三分值，其余人员只排序，不显示具体分值）。

现场：全员发言完毕，问题记录完毕，需要的支持、资源已经说明，对项目进度的影响有了大致说明，还需要细化评估。

到了这一步，例会基本完成，但是遗留的问题、需要的资源、对进度的影响评估需要项目经理迅速跟进。记住：记录遗留问题时的几个要素：问题详细说明、责任人、解决时限。最后，进度汇总、问题汇总邮件通报全员。需要协调的资源，先向上进行汇报说明情况，然后在公司内寻找可行办法，同时在外部也找找资源。如果有了解决的办法，汇报上级进行权衡选取方案。

到这里，一个例会才算完整结束。所以说项目例会考验项目经理的水平，以上还仅仅是重点列举一些问题，细节还有很多，例如会前要先敲定好哪些人参会，哪些事情自己先要过一遍心里有数，会议纪要整理发布等等。

[if !supportLineBreakNewLine]

[endif]

以上就是我今天的分享，上面的解决办法大家如果有其他建议，可以留言交流哟~