admin管理员组文章数量:1567000
图:史江鸿 天下味
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、测试经理、客户方架构师 |
引导者发出会议邀请,并通知stakerholder可全程参与,也可以只参与自己相关的议题。
会议中,所有Stakerholder都选择全程参与。在showcase的过程中,客户方架构师要求演示单元测试。引导者及时控场、重申议题。或者在议题开始之前,由参会人员现场决定,调整议题顺序。
如此,这将会是一次高效的会议。
参考:
《引导:团队群策群力的实践指南》 英格理德·本斯
《高效会议管理全案》 轩英博
《Facilitate meetings with ease》ThoughtWorks BA社区session 讲师:井寒
你点的每个赞,我都认真当成了喜欢
版权声明:本文标题:你引导过一个窘迫的会议吗? 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://www.elefans.com/dongtai/1725767143a1041260.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论