I code it

Code and Life

如何设计一次培训

培训元模式

最近在帮客户设计一个微服务进阶版培训的材料,整理的过程中我意识到这类事情我已经做过好多次了。比如在ThoughtWorks的P2能力建设项目,3周3页面工作坊等等,我觉得应该将设计课程/设计培训中的模式、原则和实践都提取一下,形成一个元模式(即关于培训的培训)。

一个培训中的活动,按照时间顺序可以分为三个步骤:

  1. 设计培训内容
  2. 培训前期准备
  3. 培训中的一些实践

设计培训内容

根据经验,只有那些正好处于瓶颈阶段,需要别人给予一些具体指导的人,培训是最有效的。比如我最近在学习iOS开发,那么用Swift开发一个Todo List应用就特别合适,而另一个基于Objective-C的自动化测试则对我来说一点用也没有(即使这个可能更高级,讲师更牛)。

在任何一个培训可能的设计之前,首先需要回答几个问题:

  1. 培训目的是什么?
  2. 参与者对主题的了解程度如何?
  3. 参与者的组成比例(比如junior占比,senior占比等)
  4. 结果如何检验?

一个例子

例子是人类的好朋友,这里我们来看一个例子:

客户要为负责开发的同事做一次培训,培训的目的是要帮助他们建立微服务架构下的常见实践的知识框架。从结果的长期效果来看,这次培训要能指导实际的开发工作。参与者对微服务的一些概念有初步了解,也做过小的练习,但是诸如如何划分服务边界,如何拆分微服务等,都不了解,也比较迫切的想要了解。

根据这个上下文,客户希望在培训中可以传递这样一些内容:

  • 如何拆分微服务
  • 常见的微服务设计原则
  • 拆分微服务的时机
  • 如何做微服务的测试

为了确保信息传递的准确性,我问了一遍上边都提到的列表,并且得到了答案:

  • 听众是开发经验相对丰富的开发(3-5年)
  • 学习拆分为了将大的应用拆分,以方便维护
  • 自动化测试能力和意识都较为薄弱
  • 听众自己的期望是可以有一些切实可以指导实际开发的收获

在有了这些输入的情况下,我做出了这样一些调整:

  • 不专门讲拆分微服务
  • 主要精力讲DDD(Domain Driven Design)
  • 设计迭代式的,逐步变得复杂的场景来练习DDD
  • 讲解和练习自动化测试(Consumer Driven Contract)
  • Session+Workshop+讨论的形式

看了这个计划之后,客户开始觉得挺困惑,说这个怎么跟我们梳理的课程诉求不一致?对于这个疑惑,我的建议是这样的:

  • 之前的例子不能落地(找不到足够复杂的,又适合在培训中拆分的场景)
  • 微服务的核心不是基础设施,而是设计原则,或者说如何在开发中找出边界
  • 有了DDD的指导,划分本身并非难事儿
  • 自动化测试(集成测试和契约测试)的能力和认识必须建立

然后我把整理好的课件,实例分解,课程安排给客户讲了一遍之后,他觉得很满意。客户自己也是懂技术的,在分析了现状之后,后来又专门要求给部门内做一些DDD培训(而不是微服务本身)。

培训方式

同样,方式上也需要一些问题的解答才能有效进行:

  1. 培训总时长
  2. 更偏重练习还是偏重讲解(工作坊还是Session,以及各自的占比)
  3. 参与者如何投入(比如是工作时间,还是晚上等)

根据经验来看,不论是TWU还是对客户的培训,工作坊和Session结合的方式效果最好。 Workshop至少需要包含这样几部分:

  • 明确要做的练习(多长时间,达到什么目的等)
  • Showcase(参与感,如果有多轮的话,要保证每个人都有Show的机会,而不是每次同一个人)
  • 讨论环节(点评,这个时机可以做一些小结,将要传递的信息润物细无声的传递出去)

workshop

应该避免的做法是:

  • 一个无法完成的任务
  • 过长的时间
  • 没有讨论,没有点评(特别是在中国文化中,Trainer有指出对错的义务

Session则简单一些,交互比较少,需要讲师之前做足功课

  • 有清晰的Agenda(时长,要传递的大致内容)
  • 如果是讲方法论(DDD,BDD等等),最好结合实践
  • 不要讲代码(没有人能看清你的编辑器,也没有人有耐心看超过1行的代码)
  • 一次不要传递太多信息(只讲三点)

两者穿插起来,可以收到很好的效果,既不至于让人觉得没有内容,也不会感觉只说不练。

预演(Dry Run)

在进行实际的实施之前,可以从参与者中找出一些典型的人进行交流,dry run一两次。不过交流也需要平衡一些事实:

  1. 侧重点(做对的事情),比如从设计的层面来讲,DDD,重构等方法的掌握比服务的可用性要重要很多
  2. 参与者想要听的和主题的相关性(比如培训目的是Story拆分,那么测试驱动开发的需求就要果断放弃)

持续建立关注点,引导发散,归纳问题,归类并给出见解和可能的方案。

如何回答问题

有两种教学方式:苏格拉底式和填鸭式。苏格拉底式讲究只问不答,通过讲师不断提问的方式让学员自己思考,琢磨,并期望领悟;填鸭式则恰恰相反,假设学员没有任何能动性,讲师纯粹将自己知道的全部告诉学员。

这其实两者在时间中都不合适。有一个度可以把握的是:

善待问者如撞钟,叩之以小者则小鸣,叩之以大者则大鸣,待其从容,然后尽其声。

即根据提问的深度来反馈,比如JavaScript培训,学生问如何声明一个数组,讲师讲词法作用域,则费劲而没有效果。经过一段时间的练习和积累之后,学生会问出更深入的问题,这时候再逐步提高答案的深度。

实践

Energize

如果培训在白天的话,在午饭后,人们自然会感到困倦,这时候需要一些提神的小游戏帮助人们清醒。适度的紧张(比如简单的7Up游戏)或者肢体动作(做几个广播体操的动作)都会帮助人们振奋精神。

  • 围成一个圈的丢球自我介绍
  • A和B向对方互相介绍自己,然后A反过来向整个Group介绍B,B向整个Group介绍A
  • 7Up
  • 丢空气球

工作坊基本准则

  1. 按时参加
  2. 保持One convensition
  3. 手机静音

分组进行

分组讨论是一个很好的实践,既可以避免只说不练的现象,又可以让参与者有充分的参与感,还可以让培训的时间长度更灵活,更容易控制。

分组可以用报数的方法,通常人们习惯和自己熟悉的人坐在一起。这会促进他们交头接耳的几率,分组时可以通过报数的方式,比如目标是分为3组,就依次报数1、2、3,然后所有报1的人为1组,报2的人为2组,以此类推。

一个我自己常用的伎俩是自由调整时间。比如在一个练习开始前,你告诉参与者他们有10分钟来完成一个Task,然后在5分钟后,你发现大家都基本已经做完了,这时候可以直接说:时间到!(相信我,没有人真正看表的,他们通常会被手头的任务搞得焦头烂额)。反过来,你可以说:再延长5分钟!以督促那些比较慢的小组动作更快一些,而事实上他们还没有用完限定的10分钟。

grouping

Parking lot

培训当然需要参与者和trainer的积极互动,但是有时候参与者提出的问题不太适合在课堂上展开:

  • 与培训主题关联并不太大
  • 比较个例的问题
  • 争议较大,难以在短时间内讨论清楚的

这些问题可以记录下来,在正式课程时间结束后单点讨论,或者作为下一次备课的关键点,加入到课件中。

Retro

和我们倡导的一切活动一样,培训也需要有始有终。我们需要收集参与者的反馈,包括positive的和constructive的,这样经过几轮迭代之后,培训会成熟而具有一定的可复制性。

可以分成三类:做得好的/有待提高的/一些疑问/建议

将问题分组讨论之后,分为三组,然后讨论出一些解决方法。

retro

其他

  • 二维码+金数据表单
  • 白板+白板笔
  • Flipchart

总结

Comments