发布时间:2022-01-09
推荐序:敏捷/精益/DevOps代表了数字化时代IT技术经理最重要的知识体系。如果探究其背后的“第一性原理”,那么可以追溯到系统思维以及科学实验的方法。熟练掌握可以有效建立IT管理者职业护城河,并助力跃迁为数字化时代的管理者。
掌握其理论体系后,技术经理还需要内化这些知识(感知场景,适应性地应用),并逐渐形成肌肉记忆。本文作者就是在会议的场景下内化相关敏捷和精益原则。其具体实践部分当然也很值得参考,但更重要的是其背后的原则和思想方法。
我们会继续推出更多有关技术管理者如何“内化”和实践 敏捷/精益/DevOps的文章。欢迎技术管理者投稿。
-- 许峰
作者:黄锦辉
01 前言
会而不议,议而不决,决而不行。你所在的企业是否也存在类似的情况呢?白天工作时间被各种会议所占满,到了晚上还得参加各种内外部的培训,然而效果却大打折扣。因此,最近我一直在琢磨,有没有一种更好的方式,可以让团队成员建立起一种主动学习的机制。因此,基于近几年学习的精益/敏捷/DevOps思想,我在团队内部尝试以头脑风暴形式的会议方式,反馈相当不错。后来发现这种会议的方式与精益咖啡(Lean Coffee)非常类似。今天, 将我们的会议实践分享给各位借鉴,也希望精益/敏捷/DevOps爱好者可以将这些思想应用于具体工作和生活中,提升工作效率。
02 模式与反模式
我们为什么要重新设计基于精益/敏捷思想的会议模式呢?最直接的原因就是会议成为了走过场,彼此都投入大量时间精力,却没有丝毫效果。此外,自从学习并通过了精益/敏捷/DevOps相关认证后,我就一直在审视自己是否有做到知行合一。通过观察和思考,可以逐步发现,我们虽然学习了新的思想和新的理念,但却依然践行着反模式,传统会议也不例外。那么,我们一起来看看精益/敏捷/DevOps思想和传统会议模式有哪些显著不同:
1.专注于成效(Outcome),而不是结果(Output):传统会议往往在于开了多次会议,做过多少次培训,交过多少次作业等等,这些都只是结果(Output);而精益/敏捷/DevOps是专注于价值成效(Outcome)——会议解决多少问题和产生什么价值。我甚至提出定期的内部培训应该是自愿参与的,当哪个培训的自愿参加人数低于一定数量,说明大家不感兴趣或是认为没有价值,这类主题的培训应当取消或是调整。
2.精益拉动原则:传统会议/培训往往是一人说众人听的方式,听众成员是被动接收会议内容(推动);但精益则提倡按需拉动的原则——会议成员主动提出问题,并主动接收大家的反馈。
3.单件流(One Piece Flow):传统会议经常出现同时讨论多个话题,甚至是跑题的情况;借鉴精益单件流实践,我们每次只谈论一个话题,直到完全解决该问题才接入下一个。
4.尊重个体:传统会议只有少数部分人发言,对于不同的意见经常会被打断甚至是质疑;精益/敏捷/DevOps则尊重个体,建立一个心理安全的环境,让团队成员可以大胆发表个人看法,不打断、不质疑、不批评,视不同意见为学习的机会。
5.现场走动(Gemba Walk):传统会议议程都是由特定人员制定的,这些议程不一定是实际工作过程真正存在的问题;精益现场走动实践强调了要在实际工作场景中观察、寻找问题和解决问题,相信基层人员才是最了解和擅长一线工作的。虽然IT软件工作无法像生产制造一样到车间现场观察,但基层人员可以切实体会和感受到一线工作实际情况,从而在会议中更能提出实际问题和话语权。
03 精益/敏捷会议实践
3.1 会前准备
3.1.1 准备材料
本次会议需要准备的材料有:白板、白板笔和便签纸。
3.1.2 绘制看板
在白板上绘制一个看板,包含Backlog、ToDo、Doing、Done和Issue共5个分类,如下图所示:
3.1.3 组织成员
本次会议中包含2个角色:会议引导者和团队成员:
会议引导者(下文也称作教练):主导整个会议,确保会议顺利举行和达到目标,1人;
成员:问题提出者,同时也是知识贡献者;考虑到会议的时效,我建议成员的人数控制在4-6人为佳。成员人数过少无法充分发挥成员的智慧,人数过多单一话题的讨论时间会很长(考虑到每个人都有发言的机会)。
3.2 会议进行时
步骤1:静默思考
让团队成员思考最近在工作过程中遇到的3个问题或困惑(问题可多可少,可根据会议的时长自行调整),限时3分钟。并将问题写在便签纸上。切记一张便签纸只记录一个问题,只写关键词或短句也可以。问题举例如下:
1)知识共享型会议(此类型会议的问题更多的是回答What,答案相对简单和标准化,问题的数量可以多一些,比如每人3个问题)
我们的目标客户是谁?
POC测试汇报应该怎么做?
投标方案编写思路是什么?
2)问题解决型会议(此类型会议更多的是解决具体问题,包括分析原因和下一步的行动计划,难以有标准答案,且问题耗时较长,每场会议的问题总数不要超过3个)
今年Q1业绩完成率为什么不达标?
基于XX项目的情况,我们如何提高成单概率?
这个项目我们为什么会丢单?
3)例行类型会议(周/月例行会议,过程相对标准,简单问题会议现场处理,复杂问题可列入专题讨论)
本周完成工作:一、二、三
本周工作遇到问题:A、B、C
下周工作计划:壹、贰、叄
将所有的便签纸贴到白板的Backlog列中,假设5个成员总共就有15张便利贴。如下图所示:
在会议实践中,存在有人提不出问题或不敢提问题怎么办?首先,作为教练需要创建一个心理安全的环境,鼓励大家用于发表观点,视不同观点为学习的机会;其次,教练以身作则,先提出自身经常遇到的问题,承认每个人都有知识盲区;最后,教练可以从提供一份场景问题清单,让成员投票选出关注的问题。
步骤2:优先级排序
进入第一个回合,每个成员从Backlog列表中各挑选一个最为重要的问题(在精益咖啡中讨论的话题优先级是由大家共同投票决定的,在此我们采用的是每人选取自己的优先级问题,目的是为了解决每个人的问题),将对应便签纸移动到ToDo列中,假设5个成员就移动5张便利贴,如下图所示:
步骤3:问题阐述
教练从ToDo列中拿一张问题便利贴,将其移动到Doing列(如下图所示),并请问题的提出者(成员A)对问题的背景和上下文进行描述,限时1分钟。期间教练确认所有成员均完全理解问题。
步骤4:轮流发言
基于成员A的问题,会议成员轮流发言和阐述对该问题的解决思路或方案,每人限时2分钟。注意发言期间不许打断、不许质疑,更不许批评。
会议发言是很容易让会议跑偏的重点步骤,也是教练需要重点把控的关键环节。有几个思路可以参考:一是发言之前可以给成员短暂的思考时间,先稍微整理发言的思路;二是每人发言限定一定的时间,但在一开始使用这种会议成员很难做到在限定时间内发言,加上每个人的表达能力不同,建议在一开始不要太刻意因为超时而直接打断发言;三是成员发言后,教练简单提炼和复述成员的发言,既有助于大家更清晰的理解,也能让成员感受到我们是真正尊重个人意见的。
步骤5:总结确认
轮流回答完问题,教练针对成员的发言进行简单总结,此时有可能出现3种情况。
情况一:大家对该问题的解决思路基本一致,问题提出人(成员A)也确认了的确解决了他这个问题,将对应的便利贴移动到Done列中(如下图所示),该问题关闭;需要特别注意的是,唯有问题提出者本人认可确切解决了他的这个问题,方可关闭。
情况二:大家对该问题的解决思路相差较大,可留出一定的时间(比如:5分钟)进行探讨,若经探讨后达成一致,则移动到Done列中,问题关闭;
情况三:大家对问题的解决思路无法达到一致或问题过于复杂短时间内没有答案,则移动到“Issue”列(如下图所示),会后做专题探讨。
步骤6:重复步骤
每完成一个问题,重复步骤3、4、5即可。若第一回合成功解决4个问题,遗留1个问题,看板效果如下图所示
每完成一个回合,重复步骤2、3、4、5即可。3个回合结束后,若完成了12个问题,遗留3个待解决,看板效果图如下。
到此,会议的主体内容就完成,对于遗留的3个问题可以成立专项专人来跟进解决。
3.3 会后复盘
会议完成后,可以进行15分钟简短的会议复盘,讨论会议中做得好和需要改进的地方,比如:
认可做得好的:
会议成员大胆地提出了自己亲身遇到的问题,共计15个;
综合大家的知识、经验和知识,解决具体的问题,共计12个;
会议过程,大家都做到了不批评、不打断和不质疑,并视不同的意见为学习机会;
承认做得不好的,并提出改进方法:
1) 成员B是刚入职的,对于其他成员提出的问题,他很难发表个人观点?
改进建议:新入职成员(如成员B)可以进行列席旁听或仅提问题不参与到问题回答环境,重点是要告知成员B这种状态是正常的,需要一定的时间来适应,不要有压力。
2) 会议中有4个问题我们解决方案部门是无法解决的,是需要其他部门(如产品部门、实施部门)共同协作的?
改进建议:我们可以定期邀请其他部门代表一起参与我们的会议,解决跨部门的问题;
3) 这种会议方式是否有局限性,能否可以用于给销售团队(特别是新销售)的培训?
首先,答案是肯定的,任何标准化的步骤和工作都只能适用于特定的场景,但是原则和指导思想是通用的。这里没有One Size Fits All的方法,正如书籍《BVSSH》提到的一个公式“原则+上下文=实践”,同样的原则和指导思想在不同的上下文(不同会议类型、不同企业和不同团队)的实践和方法是不同的;
其次,不同的会议同样需要遵循原则和指导思想——专注于价值成效,精益拉动原则,单件流、尊重个体、视不同意见为学习计划、不质疑不批评不打断。
最后,源自于日本剑道学习方法“守(Shu)、破(Ha)、离(Ri)”适用于工作生活的各个方面,任何技能的学习都要经过这三个阶段。标准化的会议步骤就是在"守"的阶段,我们熟练之后稍加调整即可应用于更广泛的场景,进入"破"的阶段。对于新人的培训,我们可以采用新人提问题,导师(会议引导者)解答的方式;对于问题解决型,可以通过投票选出当前急需解决的3个问题,且每人发言的时间不局限于2分钟;对于创意类头脑风暴会议,可以不限制每个人提出的问题数量,直到完全穷尽。
04 总结
背景/问题:团队内部每周都会举行一次专题的培训会议,是以一人说众人听的形式,大家投入大量的时间,却事倍功半。在学习了精益/敏捷/DevOps课程后,我开始思考如何基于聚焦于问题解决(专注于价值)、用户主动学习(精益拉动原则)和全员参与(尊重个体)等原则重新设计会议,因此才有了今天分享的这个会议实践。
适用场景:为了保证效果,建议是本地化小型团队(4-6人,多人团队可以考虑分小组进行)。适用于团队分享、解决团队问题和专项工作等多种会议。
成效:首先,解决了当前实际面临的问题(根据个人实践,2小时的会议解决共计12个问题);其次,会议成员可以大胆的说出个人的意见,充分发挥个人智慧(会议提供了一个心理安全的环境,不打断、不质疑和不批评);最后,提升成员会议参与度(会议解决的是大家共同面临的问题,而不是别人的问题)。
附录:什么是精益咖啡(Lean Coffee)
精益咖啡(Lean Coffee)于2009年在西雅图诞生。Jim Benson和Jeremy Lightsmith想要建立一个小组来讨论知识工作中的精益技术,但不想建立一个有指导委员会、演讲者之类的繁琐组织。
精益咖啡是一个结构化的,但没有议程的会议。与会者聚在一起,制定议程,然后开始讨论。由于会议议程是民主产生的,所以对话是有针对性的和富有成效的。精益咖啡的形式非常简单,具体分为3个步骤:
定义个人看板(Set up a Personal Kanban):将看板分为“待讨论”、“正在讨论”和“完成讨论”三个列。
2. 写下讨论的主题(What to Discuss):每个人将想讨论的话题写在便签纸上。
3. 投票和讨论(Vote and Talk):每个人拥有2票,投出最感兴趣的话题进行讨论
精益咖啡应该是一次连贯和富有成效的会议。关于精益咖啡(Lean Coffee)的更多内容可查阅网站 http://leancoffee.org/。
关于作者
黄锦辉(Stephen),EXIN DOM Club主创人员,领读小组核心成员,热衷于数字化管理实践的学习和应用,先后通过了DevOps Master、Scrum Master、Lean IT Leadership和ITIL 4等认证。