共计 2431 个字符，预计需要花费 7 分钟才能阅读完成。

众所周知，在项目管理的过程中，我们需要非常注重沟通，而每日例会作为沟通管理中的一项最佳实践，非常适配互联网项目短频快的特点。成功地在项目中建立例会制度，能带来以下好处：
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，每次参与项目管理都是一次帮助组织进化的机会，而每个为新项目所临时组建的团队中，都可能出现你曾经合作过的同事的身影。让他们成为你效能改进工作过程中散在各处的星星之火，从此，你将不再是一个人在战斗。

共计 2431 个字符，预计需要花费 7 分钟才能阅读完成。

众所周知，在项目管理的过程中，我们需要非常注重沟通，而每日例会作为沟通管理中的一项最佳实践，非常适配互联网项目短频快的特点。成功地在项目中建立例会制度，能带来以下好处：
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，每次参与项目管理都是一次帮助组织进化的机会，而每个为新项目所临时组建的团队中，都可能出现你曾经合作过的同事的身影。让他们成为你效能改进工作过程中散在各处的星星之火，从此，你将不再是一个人在战斗。