培训元模式

最近在帮客户设计一个微服务进阶版培训的材料，整理的过程中我意识到这类事情我已经做过好多次了。比如在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

总结