你引导过一个窘迫的会议吗？

最新推荐文章于 2023-03-28 22:37:11 发布

是七姑娘啊

最新推荐文章于 2023-03-28 22:37:11 发布

阅读量383

点赞数 2

文章标签： java 项目管理敏捷开发人工智能软件开发

本文链接：https://blog.csdn.net/weixin_50483789/article/details/108459912

版权

图：史江鸿天下味

2016年刚加入ThoughtWorks的第一天，正巧赶上项目的回顾会议。会议一开始，项目经理就指着我说，“新加入的小伙伴来给咱们做Facilitator吧！”

“Facilitator，什么？”我仿佛听到了一个超纲词汇。

Tech lead看到我一脸茫然，便补充到，“就是让你来drive一下本次的会议。”

Hmmm……我似乎还不太适应这种中英文结合的沟通方式，于是又再次确认了一遍，“是让我主持会议吗？”。随后，这次retro就在毫无准备的情况下展开了。

在之后的三年多，我引导和参与过大大小小无数个会议，轻松的、局促的、唇枪舌战的…… 但始终未曾仔细思考过如何才能更好地引导一个会议。直到2018年12月的一天，我参与了工作生涯中最为难堪的一次会议。

那时，我们刚刚开始一个大型中台系统微服务改造项目，经过一个多月奋战，微服务拆分已经初见成效。此时刚好处于客户侧年终KPI评估阶段，与我们对接的客户方的项目经理希望我们能在12月底之前完成第一次showcase，其目标有两个：

展示TW团队这几个月的工作成果，评估是否偏离预期
帮助客户达成年终KPI

与业务型项目不同的是，微服务拆分基本不涉及业务需求的变更，对用户来说则是无感知的，因此本次showcase并未邀请业务人员和用户参与，只邀请了相关stakerholder，这些stakerholder之间的关系，我用一张图来解释。

双方PM简短讨论之后，愉快地确定了会议的时间和人员。由于该阶段所有成果只能通过调用服务端接口、数据库以及容器日志来展示，所以我有幸成为了本次showcase的最佳人选。为了避免第一次showcase就出现差错，我花了一个礼拜的时间，一边反复验证系统，一边通过拆分场景和截图，准备了丰富的演示材料，以备不时之需。一切就绪之后，我提前给客户方PM做了一次演示，以保证这些内容就是我们共同期望展示给三级领导的成果。因为梳理出了丰富的业务场景、并且做好了现场演示和材料演示两手准备，客户方PM非常满意。

然而，会议过程却远不如预期来的顺利。

会议开始之后，TW团队、客户方PM、测试经理、BA及三级领导都已经准时到会，只有客户方架构师临时有事需要晚一点到会。PM简单介绍了参会人员之后，showcase正式开始（期间，TW架构师接到了平台组的电话，离开了会场）。

我用不到一分钟的时间讲了本次showcase的几个场景，然后就逐一开始演示。不料，在发送第一个请求的时候，测试环境就如设想的一样，准时宕机。好在，我提前准备好了包含截图的材料。在讲解的过程中，我观察到三级领导紧锁眉头，便知道，她对这些过于技术的东西不感兴趣。所以我调整了话术，在演示之前尽可能说明演示的业务场景、我的操作所模拟的用户行为、以及返回结果中所呈现的系统对于用户行为的响应，以便领导能够从业务的角度出发，对showcase产生一点儿兴趣。

然而结果并不奏效。我只说了三句话，就被三级领导打断，“你们这个会是要干什么？这个‘小姑娘’努力地想让我听懂，可我就是听不懂，我不知道这是要干嘛！”

项目经理急忙解释了一下showcase的含义。三级领导勉强地忍了忍，让我继续。我刚开始讲了2句话，客户方架构师进入了会场，还没有来得及坐到座位上，就开始说，“不看这些！我问你，API设计有些Swagger吗？单元测试呢？写了多少，拉出来跑跑我看看！”

我急忙解释到，”我是QA角色，没有准备本地环境，单元测试跑不了！您要看的话，会议之后我们可以找Tech lead一起看一下。“

“怎么跑不了，idea右键一点就启动了！”客户方架构师强调道。

……

项目经理见情况不妙，便终止了我的演示，打电话给TW架构师，让他火速回到会场。随后，便让我退出了会场。

概是我准备最久、但是过程最糟糕的一次会议。为什么会发生这样的状况呢？如果再来一次，要怎样才能改善这种状况呢？

我分别与公司比较资深的同事王晓峰和张凯峰进行了探讨。我们意识到，会议失败的原因有三个：

1. 会议目标不明确。虽然双方项目经理提前约定好了会议目标，我们也为此做了充分的准备，彼此达成一致。然而，如上图所示，参与本次会议的stakeholder大致包含三类，他们的职责不同，关注点自然不一样:

客户方PM/BA/测试经理属于为第一类，他们与TW交付团队同呼吸共命运，其目标也基本一致，希望如期完成任务，并将效果完美地呈现给三级领导，以表示KPI达成；
客户方架构师是第二类，他不关心进度和业务、只关心真正的技术实现有没有按照整体产品架构规划和约束进行；在组织结构上，他不需要向三级领导汇报，因此并不关注三级领导的态度；
三级领导属于第三类，她完全不关心技术，也不太了解业务，她以结果为导向，关心花了这么多钱请到TW团队，是否真的物有所值。

这是本次会议成败的关键，在前期会议准备的过程中，我们只与第一类stakeholder沟通了会议目标，忽略了另外两方重要stakeholder所关心的问题，导致会议过程一直在跑偏。可是如果不跑偏，便会让她们感觉参加了一次无效的会议，效果可想而知。

2. 会议没有明确的Facilitator（引导者）。整个会议没有指定明确的Facilitator，导致没有人全程控场、引导会议过程并解决冲突。会议大致分为三个阶段：

第一阶段，讲解会议目标和介绍参会人员。PM扮演引导者，虽然说明了议题是showcase，但显然三级领导并不了解showcase具体是要做什么；
第二阶段，showcase。我临时戴上了引导者的帽子。但当发生冲突时，由于我同时带着团队成员的帽子，不具备与三级领导对话的平等性，发言显然些许被动；
第三个阶段，架构师之间讨论技术，当然这是在会议过程中临时调整出来的。此阶段级别和背景对等，沟通因此顺畅了许多。但内容并不是三级领导所关注的，我想，她大概是碍于面子，才坚持到了最后。这个过程，也并不是客户方项目经理发起会议的初衷，因为他并不需要向架构师汇报。

3. 重要参会人员迟到和中途退场。客户方架构师因为有事情迟到了，并不了解本次会议的目标。进场之后，迅速提出自己的议题，由于没有引导者来重申议题，因此会议直接跑偏到了计划之外的议题上。TW团队架构师中途离场，导致需要他出面解答问题的时候，整个会议因为等待而暂停。

那么，我们究竟怎样才能避免这种窘迫的会议呢？

为了寻找更好的解决办法，我阅读了一些会议相关的书籍，并在《引导：团队群策群力的实践指南》一书中找到了答案。正巧昨天参加了公司BA社区的session《Facilitation Skill》，受益匪浅。于是我将所学记录下来，期望后续每一场会议都能通过精心准备，高效、高质量的完成。

会议的两种形态

翻阅关于会议的书籍，不难发现会议有很多的存在形式，比如，日常例会、非常正式的大型会议、工作组或跨部门团队沟通会议、临时的小组会议等。在这里，我将其粗略的分为两类：

1. 决策性会议

决策性会议是指团队聚集在一起，为了达成一个或多个目标而引发的讨论。会议最终需要形成一些结论。举几个例子：

Showcase Meeting：通过演示最新工作成果和效果，收集来自用户或客户的反馈，以此来确定是否满足预期，是否需要改进；
Retrospective Meeting：团队回顾最近一段时间的工作，梳理出有哪些做得好的需要继续坚持，哪些做得不够好需要改进，有什么样的改进措施，改进措施由谁来owner；
技术评审会：我们选择了两套技术方案，并作了横向对比。需要通过会议讨论并确定最终的技术选型。

在决策性会议中，鼓励大家澄清想法、激发思想之间的碰撞、最终达成共识，做出总结，比如：明确的行动计划、团队共识的规则、后续的一些措施等等。

2. 非决策性会议

非决策性讨论主要指大家在一起分享想法或信息，例如：

头脑风暴：收集大家产生想法，但并不对想法做判断；
每日站会：团队成员相互分享和对齐工作进度和内容，昨天做了什么，今天计划做什么，需要什么帮助；
社区分享：社区成员分享学习到的新技术、一些工作感悟、或者见闻等等。

在非决策性会议中，鼓励大家提出各自的想法，但不对这些想法做出评价。

相比之下，在非决策性讨论中，记录的是个体的想法；而在决策性讨论中，记录的是集体的想法。

引导会议的锦囊

就像电视节目需要主持人来控场一样，良好的会议，同样需要引导。

引导实践始于对行为科学的研究，最初使用它的人群主要是教育工作者、管理顾问和人力资源管理专业人士。后来，它的价值被运用于各行各业。这里我们说的是引导技术在高效会议方面的应用场景。

引导（Facilitation）：是指通过一系列活动或方法，帮助一群人形成共同目标并实现目标。

引导者（Facilitator）：是指能够帮助一群人形成共同目标并帮助他们实现目标的人。引导者需要保持中立，聚焦在会议的过程上。引导者为会议的参加者提供讨论的结构与工具，他们不参与内容的讨论，而是确保每个人的声音都能够被听到；他们不左右讨论的结果，而是支持参加者找到自己的目标并制订行动计划

那么，如何才能更好地引导一个会议呢？要回答这个问题，就需要先理清楚会议的4个步骤：会前准备、会议启动、会议过程中及会议收尾。如下图所示：

会前准备：

引导者需要提前与关键的stakeholder沟通。一方面，再次确认议题和时间安排，避免无效议题或议题时间安排不当；另一方面，检查需要准备的议题材料是否按时完成。
引导者需要事先了解参会者的情况，比如，我们经常遇到这样的场景：

参会成员彼此不熟悉。这样一来，很可能整场会议都会因为大家不好意思讲话而鸦雀无声。安排一个热身环节，增加大家的熟悉度是不错的解决办法。
参会人属于同一个团队，但关系复杂，矛盾重重。那么，建议提前跟其中比较核心的stakeholder进行沟通，对齐会议目标。这样做的好处是，这些stakeholder会时刻想起会前的沟通，从而提醒自己靠近议题；其次，要提前预知可能发生的冲突，做好解决冲突的预案。
领导一言堂，团队成员并不敢或不愿发声。那么，采用匿名写sticker的方式来收集信息能起到不错的效果。
参会成员太多，做不到一一发言。采用小组讨论的形式可以大大提高效率和成员参与度。

会议启动时

在白板上写下会议议题和时间安排，有助于检查会议过程、控制时间；
戴上引导者的帽子，也就意味着被赋予了引导者的权利，这包括：要求一方复述对方的观点、当有必要调整议题顺序的时候可以叫停、让大家先茶歇一会儿等。在会议启动时，介绍自己的角色，既是获得许可，也是在保护引导者，不至于被看成犯上或者越界。
申明会议规则，有助于保持会场秩序，避免频繁打断。

会议过程中

在会议中，决策权应该被每个参会成员所拥有，而不是领导一言堂。引导者需要时刻帮助大家明确会议目标，促进参会人员之间有效互动，感知会议的氛围和节奏，把握什么时候该继续，什么时候需要小结一下，什么时候该解决冲突。

当气氛不够活跃，参会者不能表达想法时，引导者需要调节会议氛围，确保每个成员都能在安全的环境里积极的表达自己的想法；
当讨论过于发散，或者偏离主题时，引导者需要适时打断，将讨论拉回正轨，聚焦在会议目标上；
当不同的stakeholder各持己见，无法达成结论时，引导者需要解决冲突，并通过一些工具和方法，促成结果的有效达成；或者暂停会议，让参与者平复情绪之后再继续。

会议收尾

拥有一个良好的收尾，会议才不至于虎头蛇尾。

收尾一个非决策性会议：在分享信息或头脑风暴环节，引导者需要将收集到的信息总结一遍，确认是否有遗漏或补充。
收尾一个决策性会议：当一个会议做出一个或多个决策时，引导者有必要跟大家再次确认对决策的共识。

当然，邮件、贴在看板上的sticker、拍照等可视化的会议记录是会议收尾中至关重要的组成部分。它是将会议结论固化下来的有效手段，其形式却不用严格限制，根据会议本身的形态和重要级别来选择才是最佳方案。

不过为了成为一名合格的会议引导者，我还总结了以下几个锦囊，如图所示。

文章篇幅有限，不能够将所有经验通篇写出来。强烈推荐大家阅读《引导：团队群策群力的实践指南》一书，再根据自己工作中实际遇到的情况，反复研究和运用书中方法。我坚信，你将不再会引导一个窘迫的会议。

最后，让我们回到showcase故事的最开始。假如我们做了这样的改善，故事会不会是另外一种结果。

双方PM简短讨论之后，愉快地确定了会议的时间和人员。PM指定了该次会议的引导者。

会前，引导者分别与三类stakerholder做了沟通，了解了各自的关注点。引导者与PM、架构师及我做了沟通。我们及时调整了showcase会议的议题：

Agenda	议题	时间	参会对象
1	展示TW团队这几个月的工作成果	14:30 - 15:00	TW团队QA、客户方PM、BA、测试经理
2	展示微服务拆分的整体计划及当前进展	15:00 - 15:15	TW团队PM、客户方PM、BA、测试经理、客户方三级领导
3	展示产品技术实现	15:15 - 15:45	TW团队TP/TL、客户方PM、BA、测试经理、客户方架构师