培训真的没用吗？
在我跟同事聊起培训的时候，他们对培训的认知大概是这样子："我们团队成员的架构能力不足，没法落地微服务，你们来给我们上一个DDD的课吧..." 诚然，这种模式在培训市场是普遍存在的，组织斥巨资邀请大牌培训师，上个几天的课，培训师拿钱走人，然后呢，可能就没有然后了。
团队之所以需要一个培训，无非是因为面临自身无法有效解决的问题，亦或识别出潜在的风险（以花钱为目的另当别论）。问题通常源于流程和人两方面，流程的问题最终也能归结到人身上，人的问题又很容易被定义为能力的问题，如此一来团队便寄希望于借助外部力量来提升团队的能力。这种想法没毛病，毛病在于培训往往无法有效解决能力问题，除非培训能够回答以下两个问题：
如何让学员的认知发生实质性的转变？
如何让学员将知识有效地转化成技能？
实践证明，单纯的培训很难给出答案，从而产生了培训无用论[1] 的观点。然而，培训真的没用吗？如果没用，为什么一些大厂都在大力推行员工培训呢？
能力建设的团队自治观
思沃内训[2]是ThoughWorks中国区负责人员能力建设的团队，我们同样面临着跟外部培训相似的困惑：培训之后无法保证团队发生实质性的提升。 要改变现状，我们必须要比培训做的多一点，站在更高的视角去看团队对培训的诉求，不难发现团队是希望通过有效的能力提升去解决实际问题，这便升级为一个复杂的能力建设问题。
最理想的能力建设活动应该由团队内部自发组织，一来具备更好的On-Boarding土壤，二来更符合自组织的敏捷团队特征。在ThoughtWorks不乏这样的学习小组。然而，随着公司业务的扩张，新老同事快速更替，能力建设遭遇瓶颈，内训团队便承担起特殊的外部教练角色。
教练本身不会直接着手解决团队面临的问题，教练的主要职责是帮助团队自己解决问题，最终还是要依靠团队自身发力，取之于团队、用之于团队。知易行难，做好这一点呢？带着这些思考，我们落地了一场超越培训的训战。
超越培训的训战模式
训战模式的核心思想是培训 + 实战，该模式需要统筹规划培训前、中、后三个阶段，做到训前瞄准、训中调整、训后复审，将单纯的培训变成一个有效的能力建设活动，实现价值闭环。
与传统培训方式不一样的是，我们在训前做得更加充分精确，为训中留有足够的时间和空间，实现课程快速迭代，后期结合至关重要的训后复审，通过实战来内化知识。该模式的核心指导原则是：跟团队保持紧密连接。基于这些创新的想法，辅以4个关键步骤来完成训战：
教练在前期深入团队，分析团队现状，准确定义问题，为团队量身定制解决方案。培训交付期间，通过教练引导技巧深度激发团队成员的思考和讨论来颠覆或加强他们固有的认知。最后，围绕训战计划来促进团队的知识转换。
下文我将通过实践案例对训战模式做一个全面的阐述。这是一个服务于海外知名大企业的业务团队，前期高质量交付赢得客户的信任，促成了更多业务合作机会，团队规模亟需扩充。此时，原本新人占比大的现状伴随着扩充继续加剧。如何提升团队开发人员能力、保证敏捷技术实践的良好落地成为团队即将面临的一大难题。
定义问题 - 深入团队
问卷或访谈的方式呈现出来的很可能是冰山上半部分的景观。为了探索下半部分，我在前期深入团队内部获取团队日常工作状态、技术栈选型以及人员的相关情况，并出了一个初步的分析报告：
基于分析报告，跟TL达成初步方案是上OOBootcamp五抓手（OO、Clean Code、Simple Design、Refactoring、TDD）。有了五抓手这把枪，不能着急开火，我需要弄清楚团队对这些实践的实际的落地情况。通过参加团队的代码评审以及详细的代码库扫查，我果然收到了惊喜 -- 代码库测试覆盖率高达90%，代码分层、模块化都不错（似乎已经做的很好了）。
当前代码库的良好状态离不开团队的对Clean Code的重视，再加上团队刚刚对原本业务代码量不大的代码库做了较大规模的重构。即便状况良好，团队依然非常渴望掌握工程技术实践的最佳姿势，尤其是TDD。
基于这些调研分析，我对问题域重新划重点：
团队成员Second Tier入职时间偏短，相关敏捷技术实践掌握深度不够，担心影响后期交付质量。
技术实践在后期Ramp-up保持最佳姿势一致性有难度，存在辜负客户期望、降低客户信任度、难以保持标杆形象的风险。
设计方案 - 量身定制
不难看出此次能力建设活动属于风险预防性质的。虽然没有太紧迫的痛点，但团队已经暴露出一个关键的信号 -- 团队已经在尝试的过程中产生困惑，渴望得到解答，并通过实践掌握最佳姿势。该信号给了我一个方向：借助大量的实践操练和充分的思维碰撞来加强训战的效果。基于此，我搬出了承载了五抓手的法宝OO Bootcamp[3]，并一切为8，每周3次，每次晚上2~3小时，形成了非常6+1的两周拉锯战模式。
依赖于口口相传的OO Bootcamp在课件标准化上沉淀颇少，这也给了我充分的空间让我去设计训战方案，对于训的设计，我重点兼顾了两点：
定制化调整。针对团队的真实情况做适当的定制化，并做好在交付的过程响应变化的准备。
螺旋化共创。在课程中能够不断激发思考，试图让大家经历困惑、解惑、疑惑、再解惑的螺旋化过程。做到学员共创 Over 讲师讲解。
交付培训 - 认知转变
本环节的核心目标是：通过持续调整，辅以螺旋化共创过程，诱发认知转变。 要引发螺旋式的认知转变，最重要的一点是：放慢步伐，以学员讨论、答疑解惑为核心宗旨。因为参与这次训战的成员特殊性（TL & Second Tier），讨论的焦点主要被我引导向价值层面（Why），通过操作层面（How）的冲突来激发讨论，并在How与Why之间螺旋交替冲击，最终回归到Why上，讨论的重点也大多聚焦在团队日常工作中面临的问题上。
有意思是，当大家对价值层面理解达成一致后，在操作层面的最佳实践往往都是无果而终（By Experience），我们对最佳实践虽然未曾有明确的定义，经过这样频繁的思维碰撞，团队往往能找到一些方向。比如TDD，做Story的时候，第一步是从业务视角去做Tasking，将Tasking可视化作为一个DoD[4]，严格根据Task来编写测试用例，做到测试先行，并通过Pair来刻意练习。
铺设好明线，我在辅线上也做了一些必要的工作 -- 跟团队做深入交流，了解他们当前面临的痛点，设计新的案例，尝试抛出一些引子，引发团队成员共同思考。比如如何在后端MVC架构下做TDD。
部署计划 - 技能转换
我认为一场好的训战应该由体验、反思、抽象、行动四个部分组成，相辅相成，并且能够形成一个闭环。在培训过程中，需求驱动、编码实践就是一种体验，在体验的过程中引发思考和讨论，最理想的情况下是学员自己能够从思考和讨论中抽象总结得出结论，并将结论付诸行动得以验证。
在文章一开始我就提到，能力建设最终要靠团队自身发力，主动权必须交还给团队，否则一旦教练离场，打回原形的风险很大。通过培训颠覆认知只完成了一半的工作，另一半的工作是将这些新的认知在实践中去验证。要打好下半场，就需要搬出核心法宝 -- 训战计划。 训战计划类似于一个计划，它具备三个重要特征：
符合SMART[5]原则，难度适中
跟项目工作内容息息相关
学员自己拟定并认可签字
作为教练，我协助团队成员去制定有效的训战计划。有了训战计划，就一定能够兑现吗？理想情况下，团队成员的能够足够自我管理，并落实好计划。必要的时候，借助一些轻量的管理机制和有效的激励机制，比如，组建分队、队长责任制、公开承诺发布等，另外对计划完成后进行奖励等。 作为特殊的外部教练，我需要持续重点做的事情有：
培养团队内部教练，保证后期的可持续发展。
训战计划执行期间，响应团队的诉求，帮助团队解决执行过程面临的阻碍。
定期回访，跟踪训战计划的落实情况，了解团队的困难，并记录团队的变化。
训战的核心要素
训战的复杂度远超越了培训，既要大处着眼，用全局的视角统筹训和战，也要小处着手，紧抓各个环节，尤其是训战计划的落地跟踪。一场优秀的训战，除了方案设计、课程内容和呈现形式上的创新，还需要借助团队管理和激励的手段。综合来看，决定训战成功与否的几大核心要素有：
一致的期望
专业的培训
承诺的计划
严格的跟踪
一致的期望
在训前方案设计阶段，一项至关重要的举措是跟Stakeholder和团队成员对训战模式的期望达成一致 -- 不仅仅是一场讲完就散的培训课程：
对于学员，要做出源于追求卓越的自我Commitment。
对于Stakeholder，要提供资源来促成训战计划落地，比如识别潜在内部教练，提供训练道场支持等。
专业的培训
教练需要对领域知识具备一定的深度，深刻理解正、反模式的利弊，拥有丰富的实战经验。同时对于教练引导能力也提出了较高的要求，推荐实施以学员为中心的共创式教学。另外，还需要具备对实时反馈的响应力，能够快速调整优化设计。
承诺的计划
学员基于培训的内容，结合实际项目中遇到的问题，亲自挂帅拟定恰当可行的训战计划，并立下"军令状"，最终做出公开承诺、告示"天下"，若能借助管理激励机制形成彼此轻量的竞争态势会取得不一样的效果。
严格的跟踪
训战的效果取决于训战计划是否合理以及能否有效执行落地，后期严格的跟踪尤为关键。首先，可以在团队内部培养教练，来帮助成员解决执行过程中遇到的问题，同时敦促计划的推进。其次，在流程管理和奖惩机制上，Stakeholder的关注、必要的激励以及恰当的惩罚技巧都会影响跟踪效果。至于如何操作，团队因地制宜即可，推荐正向激励。
写在最后
训前瞄准、训中调整、训后复审这种基于业务团队的训战模式，通过4个看似很平凡的关键步骤，围绕着训战计划来促进行动学习，帮助团队将知识转换成技能，有效地实现价值闭环。
培训到底有没有用，我们给不出一个标准的答案，我们能做的是探索更高效的能力建设模式，尝试比培训多做一点点。
