众所周知，在项目管理的过程中，我们需要非常注重沟通，而每日例会作为沟通管理中的一项最佳实践，非常适配互联网项目短频快的特点。成功地在项目中建立例会制度，能带来以下好处：

1）让研发人员相互之间了解各自的任务完成情况，以便于上下游及时衔接，发现进度异常和集成的风险。

2）让技术难题和业务疑点及时暴露，并根据问题的普适程度，选择在会上或会后得到支持与解答。

3）让产品经理了解研发过程，一方面及时掌握动态，另一方面能对结果和风险抱有更深切的同理心，以便后续能更紧密地合作。

4）帮助团队建立秩序感和纪律性，提升组织的成熟度。

作为一名在 弱矩阵型组织 中拥有微权力的 PM ，要在一个尚没有形成惯例、且仅为完成当前项目而临时组建的团队中建立例会制度，笔者建议以如下方式迈出第一步：

一、事前摸底

可以先通过访谈对话的方式，收集项目组成员在 如何透明研发进度和风险 方面的认知情况，甚至可以了解一下其所属部门的工作风格，以便采取合适的应对措施。

如果有成员曾经参与过项目每日例会的相关实践，务必抓住这个机会，尽量说服 TA 作为你安插在项目组中的卧底，在必要的时候主动站出来配合你，这样的话，其他人也更容易行动起来。

可能也有成员曾在例会中经历过糟糕的体验，比如：时间冗长、议题蔓延、信息过载、与之无关等，这时，你一方面要庆幸提前发现了暗礁，在自己组织的例会中要尽量避开（当然，如果你有丰富的项目管理经验，阅会无数，那你能举出更多的失败案例，但无须事事防范，否则过犹不及，让自己处处掣肘），另一方面，也要更加谨慎地实施你的想法，避免对方受到二次伤害，进而对 PM 和改进工作丧失信心。

二、承诺约定

PM 需要具备一定的主动性，在项目启动之初（比如： kickoff meeting 上）提出例会的建议，可以介绍一下例会对项目及成员所带来的好处，与大家（包括 PO ）约定每天在固定时间和地点同步一下各自的状态，挑选大家都合适的时间，并获得每个人的口头同意。

作为交换， PM 须针对大家关切的问题作出一些承诺，比如：确保会议的质量，时间不会超过 15 分钟，会后有文字材料输出用于追溯。

不仅是例会制度，绝大部分的改进工作都会要求参与者走出舒适区，做出一定的让步甚至承受阵痛，故所谓“投之以桃，报之以李”：你愿意配合我的工作，我也不会让你失望。针对之前调研所掌握的信息，给项目团队吃下定心丸。

三、不见不散

可以要求让每个人创建一个日程提醒。但无论设几个闹钟，刚开始几次例会，还是会有不少人迟到甚至忘记出席，需要经过反复提醒才会慢慢养成习惯。

守时是职业操守之一，但如果遇到成熟度较低的组织，则需要不断灌输和教育。这时候， PM 一方面需要及时补位，在会前就做好提醒工作，另一方面也可以于会后在项目日志中做好记录，在必要的时候反馈给当事人所属部门的负责人，一起帮助 TA 改进。身处于某些组织文化中的读者，可能会对这种直接了当的反馈方式抱有畏惧心理，但考虑到“如果团队尚未达到理想的成熟度，未来高阶的改进工作将难以开展”这一点，就不应该回避沿途的任何困难。

另外，例会地点尽量固定，以便于大家习惯的养成，否则每次换地方都要再通知，成本很高。

四、每日三问

首次例会一般需要花更多的时间，最主要的一点是 PM 需要向大家讲解和示范如何参与例会。当然，在承诺约定环节可以做一些铺垫，但光是口头解释缺乏身临其境的场景感，大家未必都能 get 得到。所以，也不必赘述，只要现场主动参与和切身感受一下，包教包会，屡试不爽。

为了争取最佳的投入产出比，我们有必要把例会的环节设置得尽可能的精简，但又不失效果。笔者建议会上所有人站成一圈，每个人（除 PM 和 PO 之外）轮流向团队回答三个问题：1）我昨天做了什么（即：工作进度）；2）我今天打算做什么（即：工作计划）；3）我遇到了什么困难（即：暴露风险）。

前两个问题，上下游与之依赖的组员会特别关注，比如：前端依赖于后端的接口实现，否则他自己的功能验证工作会迟迟完不成。而第三个问题， PM 和 PO 会比较关注，他们有义务为项目扫除障碍，比如： PM 需要协调项目团队以外的技术顾问来做支持， PO 需要解答产品功能细节的疑惑，不一而足。通过上述三个问题，信息在项目组内部变得完全透明，成员对工作更有目标感， PO 对成功交付更有信心，妈妈再也不用担心我的项目了！

如果组织得当，按每人三句话的速度，一次例会妥妥地被控制在 15 分钟以内。当然，由于例会的时长非常短，为了确保会议的效率和效果，仍然要求 PM 控制好会议的节奏，同时也需要项目组成员全身心投入。

五、反馈改进

每人分享完自己的三个问题且没有其他公共议题了的话（非公共议题应放在会后单独进行），项目团队的首次例会就进入尾声了。此时，大家的精神状态已经放松下来了，由于是第一次例会， PM 可以在宣布散会前询问一下大家的与会感受，以便后续做改进。

也许首次例会并不如你预想的那样完美，比如：有的成员不太善于表达、有的成员会忍不住和其他人开小会、有的成员羞于公开上报自己的风险，等等。但至少你已经迈出了第一步，项目组成员的心中已然被你播下一颗种子，后续免不了还要不停地浇水施肥，帮助他们积累 如何高效参与例会 的经验，在现有最小可用例会的基础上持续迭代。

小结

导入项目例会 比较适合作为对组织实施效能改进工作早期阶段的一次试探，以投石问路的方式了解组织对轻量级变革的接受情况。如果较难接受，则说明组织的成熟度不高， PM 要做好贴身辅导打持久战的心理准备，反之则能顺利推广并赋能到组织的各个角落。

在有赞建立项目管理体系之初，笔者曾倡议试行项目例会，有幸被广泛接纳，辅之以实物看板，简直如虎添翼。曾经有一段日子，某间狭小的会议室，在一个小时内轮番成为四五个项目的每日例会之场所，与会人员络绎不绝，一派繁忙而有序的景象。

作为 PM ，每次参与项目管理都是一次帮助组织进化的机会，而每个为新项目所临时组建的团队中，都可能出现你曾经合作过的同事的身影。让他们成为你效能改进工作过程中散在各处的星星之火，从此，你将不再是一个人在战斗。

创作场景

效能改进之项目例会导入实践