培养体系 / 工具提效？谁能创造更多价值?
又是一年一度的入职培训期，而如何提高培训效率，一直以来都是困扰着我们部门的一个课题。
Question
每年的培训期，部门总会面临着以下这么几项问题：
- 培养一批新人，需要公司提供至少一名资深研发进行教学
- 由于资深研发在培训期需要脱产，无法将培训期时间延的很长，因此需要尽量压缩培训时间，基本在一个月左右
- 压缩培训时间会导致课程密度过高，密度过高会导致学生可能会无法消化培训的知识点
- 在短期培训时间内有较好表现的学生，往往具备出色的开发能力，这类人一般会在培训期后流向其他更好的平台
以上四个问题，实际上形成了一个变相的恶性循环，如下图所示：
可以看到，在现有的体系下，培训这件事情的产出率较为低下。一旦出现大量人员流失，如果将资深研发的脱产时间计算进去的话，甚至可以说是亏本生意。
如何改变这一现状？从我个人角度出发的话，可以想到以下两种思路。
培训体系
这里就要讲到我司的特色 — 集中培训了。
这种集训的优势主要在于 — 让刚刚入职的新人能够迅速发挥战斗力，本质上来说我并不反对这种做法。因为新人的素质并不一致，利用集中培训的时间，将基础的知识迅速传授给新人是效率相对较高的一种做法。
但是回到之前的问题： 尽量压缩培训时间，基本在一个月左右，这一点就从本质上决定了，我们不可能针对每个知识点去给学生提供充足的消化时间。从公司的角度出发，基本都是希望新人能够在尽量短的时间内为公司创造效益，但是存在这种能力的人，同时也具备很强的职场议价能力。
因此这个悖论就出现了：
- 节约培训成本 => 压缩培训时间
- 压缩培训时间 => 开发能力一般的人基础不扎实
- 开发能力极强的人 => 迅速掌握了知识 => 跳槽
- 新人留存率下降 => 培训成本反而上升
在我看来，这个问题是因为缺乏完善的 Mentor 体系而导致的副作用。
一个月的培训时间实际上很难带给新人真正有用的知识，举个例子：Webpack 讲 3 天、antd 讲 2 天、mobx 讲 2 天，将培训时间压缩的如此之紧凑，实际上对双方都是一种折磨。阅卷的老师认为学生的掌握速度太慢，而学生认为提供的学习时间实在过短，同时也很难真正理解课上涉及的框架。
那么，为什么不换一种思路呢？集中培训发挥其应有的作用，只讲解基础到不能再基础的知识，剩下的 Webpack、ui 框架、状态管理 的相关知识交给各组相关的 Mentor 进行传授，这样一方面杜绝了人员的长期脱产，另一方面变相的延长了培训时间，能够让新人打下更加坚实的基础。
至于能力极强的人，这一类人从来不在我们的考虑范围之内。因为对于这种开发能力达到一定水平的人，我司这种平台能够提供的始终有限，与其关注于这种少数的天才，不如关注那些基数更多的平凡人。
工具提效
另外一种思路是，将前端的能力抽象成一套通用的框架 / 组件 / 工具，从而在不延长培训时间的情况下传授一套高度封装的框架知识，这样也可以达成在短时间内提供尽可能多的知识的能力。由于大部分的操作都已经被框架高度抽象，因此大多数人只需要掌握框架抽象出来的知识就可以了。
这个点涉及到的面非常广，诸如将常用业务抽象成组件、多个组件聚合成为区块、运用编辑器插件进行默认的业务逻辑补全、以及现在我们正在做的：将业务逻辑做成可视化工具，利用直观的拖拽方法指引用户快速生成自己想要的页面，也就是所谓的前端赋能。
顺着这个思路走下去，我们可以发现：需要传授的知识实际上大大减少了。实际上这个时候开始，我们的培训体系注重的就不再是基础能力的培养，而是公司内部中台生态的运用。每个前端工程师实际上被我们异化成了公司框架的操作员，且每个人都具备完全的可替代性，从公司角度来说是非常理想的状态。
但是这样培训出来的人员，由于强依托于公司的内部框架，因此会导致个人能力的急剧下降，这也就是前端程序员们担心的 失业 问题了。
Conclusion
简单总结一下：A 方案培养出的前端会是合格的开发人员，但是会花费公司巨量的成本。B 方案培养出的会是合格的操作员，但是在研发方面的创造性又会有所欠缺。那么究竟应该选用哪种方案呢？
个人观点认为，两种方案并行推进会是一种更好的选择。B 方案可以满足公司短时间培养人员的需求，而 A 方案则能够提供靠谱的开发人员，后者培养出的人员可以继续开发 B 方案所需要的各类工具，从而更好的节约开发成本。
实际上运用工具提效这套思路并不新鲜，阿里在很早以前就做过相应的尝试，并在公司内部取得了一定的进展。
最后为这个命题下一个定论：无论优质培养体系还是前端工具提效，本质上并非为了消灭程序员，恰恰相反，主要的目标在于将程序员从繁杂的业务逻辑中解救出来，使之能够从事更富有创造意义的工作。
这些愿景的最终结果依然需要反映至集团本身，毕竟集团才是发给程序员面包的人：）