ThoughtWorks training
ThoughtWorks培训
在过去的几年里，为了进一步提升ThoughtWorks在业界的影响力，扩张无疑是最为有效的策略。但是，以提供知识流程外包（KPO）作为主要业务的ThoughtWorks，人员的成长变成了业务增长的主要瓶颈。构建“学习型组织”，减少从0(新人)到1(能够提供专业服务)经历的时间变得迫在眉睫。
现状和思考
对于培训，公司投入了大量的人力物力，我们仍然在思考和摸索什么是最有效的培训方式。如何快速培养一名合格的TWer？在当前招聘策略下，这是一个严峻的问题。由什么来指导我们做“正确“的培训，培训什么、怎么培训以及能不能达到我们的预期这些都尚未可知。
培训是需要反馈周期的，假设首次教学目的(收集受众能力metrics，得出初步结论)，导入教学形式(是讲理论，做实践还是改变习惯)并对当前的产出做出量化评估(学员能力分级)。形成教学目的>教学形式>量化评估>修改当前教学目的/下次教学目的的闭环，逐步提高培训的质量和效率。
以学前班的郑大夜校为例，我们已经实践了很多期。不否认地，很多毕业生从中获益颇丰，入了ThoughtWorks的门坎。但是，我们也不得不正视每期结束后褒贬不一的反馈。我们不妨试着剖析反馈背后的问题，从一个个点切入，顺藤摸瓜，反观教学的形式、目的和整个郑大夜校编排的合理性。
首先我们回顾一下本期郑大夜校的阶段安排
阶段一（毕业到年前）：
静态语言阶段
阶段二（年后到入职前）：
动态语言阶段
阶段三（入职后一个月内）：
工程实践阶段
第一阶段主要囊括了Java语言，面向对象编程，设计原则和模式等内容，采取了讲师讲解，学生提问交流和练习的方式；
第二阶段预计采用Javascript语言，应用动态语言的特性重新实现第一阶段的练习。但是事实上，由于培训人员变动等原因，该阶段没有遵循预期计划，而是直接进入了阶段三。
第三阶段，毕业生应用我们平时工作的流程和使用的工具，参与实现一个公司内部的固定资产管理系统，用XR的话来说就是将思想上的东西应用落地。
经过两期的培训，通过毕业生自己的在retro上的反馈以及各位mentor的观察，大体上可以看出毕业生对于第一阶段的培训内容和形式还是很认可的。比较有趣的是培训中就已经有人明确告诉我他自己越来越不会写代码了，这并不是说他能力不行，反而恰恰说明他正在提升，也证实我们培训的目的达到了——对于整个软件行业以及自身能力有清晰的认识。但是必须承认这个例子不是普遍现象，思想上的东西不是一蹴而就的，而且也不能轻松量化以待检验，至少基于当前的教学形式还做不到。
对于第二阶段的培训，学生普通反映引入的工具和框架过多，再加上课程安排松散，每个迭代的目的不甚明确，严重拖延了项目的进度，结果距离完成的目标尚远。而从mentor的角度，理论到实践的落地过程预估得还是过于乐观，不过这个罅隙在和senior dev的结对过程中得到了有效的弥合。
那么问题是我们现在的问题是什么？
在回答这个问题之前，我们先问自己一个问题：
公司想要把毕业生培养成什么人？
如果答案是一群高级技工。那么我觉得郑大夜校可以不存在，直接找一群senior dev和这些新人pair，手把手教授过程和工具，模仿着码代码。因为基于我们的培训结果，这样的效果是最快最直接的。
若答案是对技术有兴趣、有想法和自主学习的geek。我们就要真的从毕业生角度出发，明确他们缺少什么能力以及如何弥补这些短板。
那么我就以答案二为假设，结合本期培训，展开问题的论述：
第一阶段
验证理解是否到位最好的方式是做练习。问题是一些学生没能完成课上的配套练习，课后也未必补上。这点与课程设置缺少检验环节必然相关，但归根结底是学生缺乏主动性。那什么叫做有主动性？同样是布置POS机的作业，有学生在每一次培训后都会持续改进自己的程序，将新的知识点实现一遍。没人强制这么做，但他做了就是主动。
问题一来了，学生缺乏主动性。该如何解决这一问题？
第一，我不认为学生缺少学习的动力，那么可能的原因是没有明确的期望和目标。期望和目标应当来自于未来的雇主。这里有详细的论述，我就不再赘述。
第二，组内职责轮换。基于本期分组教学的模式，我们已经尝试分派一些职责，效果良好。职责轮换可以让学生因感受到压力而成长。
第三，建立惩罚制度。对于mentor而言，我们并没有有力的手段给予学生压力，我们至多会告诫说若表现不好，会影响其过试用期，但是，这样的压力距离太远。所以建议提前建立因技能等评估维度（后面会详细讨论）严重不足而拒绝offer的制度。
以上解决问题的建议是基于现有的教学形式提出的。经过和DW的讨论，这一问题或许反映了原有的教学形式本身就存在漏洞。
我们依旧遵循大学的填鸭式教学模式。要知道没有哪个行业像IT行业这样特殊：没有什么东西不能够（应该）在互联网上学到的。我们何妨换个思路，将以前的课上讲授，课后练习，下次课上检验的方式改变成提前提供课题和所用教学资源，课前学生自己学习，课上解惑的模式。这样可以最大化调动学生自主学习能力，而且学生带着问题上课的效率也远高于直接教学。
第二阶段
问题二：我们第二阶段的初衷其实是将第一阶段的思想方面的东西落地。但是大量的工具和框架，这些干扰因素严重分散了学生的注意力，原本检验学生设计和创造能力的时间被极大地缩短了。
问题三：课程安排松散，迭代的目的不清则更为严重。这反映了郑大夜校本身就是不规范的，集中体现在讲师变动频繁、能力良莠不齐，授课内容临时起意，内部的目标不清不楚等。
针对问题二，我们首先再次明确公司需要的是对技术有兴趣、有想法和自主学习的geek。所以建议不强制学生学习使用工具和框架，尽量选用简单的技术栈，重点检验设计能力。
问题三，这样的现象一直存在，而且涉及的问题有点多，我们慢慢剖析。
第一，讲师变动频繁、能力良莠本身不应该是个问题，这点可以参考TWU的办学模式。关键还是如何标准化。
第二，授课内容不固定，典型反映在临时找的session上，涉及Agile演化、scrum workshop、业务、QA和Dev技能等各个方面。考虑时间限制和学生的接受能力，对于学前班的郑大夜校而言，这样的scope未免过于庞大。或许需要重新定义郑大夜校的scope，例如：将培养卓越的软件能力提到首位，而将P1和P3的侧重弱化，延迟到TWU和On Board Training上。
第三，相较于TWU，郑大夜校缺少了一个P2P feedback的环节，我们也不知道经过培训什么样的人就满足公司的期望。这就引出了量化指标，可想而知，量化指标不是绝对量，它应该是相对于以前能力模型的增长量。举个例子：从70分上升到80分和从10分上升到60分体现得是后者成长空间更大。量化指标需要根据夜校的scope，划分出能力象限，因为我们能考察的不应该越界。
孔子曰：温故而知新，可以为师矣。我们做个recap。
教学目的
- 拓宽毕业生的软件开发的视野，明确自身能力
- 帮助公司尽早筛选可用之才
形式
- 颠覆填鸭式教学，自学为主，解惑为辅
- 分组，轮换职责
- 入职前惩罚制度
- 制定标准的教学流程
- 限定夜校教学范围
- 制定量化指标
量化评估
- 有待确定能力象限。