ThoughtWorks武汉某Offshore Account服务的海外客户是一家全球Top 5的大企业,因为前期的高质量交付赢得客户的对团队的充分信任,客户将团队的敏捷技术实践视为标杆,供其他Vendor效仿学习。同时,随着业务合作机会的增多,团队即将面临Ramp-up,由于团队新人占比大,加上后期Ramp-up会持续加入更多的新人,需要继续保持团队的良好敏捷技术实践。机遇与挑战并存使得Account对团队成员提出了更高的要求,这便促成牵起了思沃内训团队和该Account的因缘。


思沃内训团队的定位

我小时候经常听到一句这样广告:学挖掘机找山东蓝翔 。可能在ThoughtWorks内部,有一句潜台词叫:搞培训找思沃内训。在开始之前,我想先聊一聊这句潜台词背后的意义。

我跟一些同事聊起思沃学院(曾用名,已更名为思沃内训)的时候,一些人对内训团队的认知是这这样子的:”我们团队成员的架构能力不足,没法落地微服务,你们来给我上一个DDD的课吧…” 诚然,这种模式在培训市场是普遍存在的,企业斥巨资请来所谓的大牌培训师,上个几天的课程,收集了反馈,培训师拿钱走人,然后呢,很可能就没有然后了。

团队之所以需要一个培训,无非是因为面临无法有效解决问题,或着识别出了一些潜在的风险(为花钱而花钱的不在讨论范围)。而问题主要涵盖了流程和人两方面,流程的问题最终也能归结到人身上,人的问题又很容易被定义为能力的问题,所以这么一来团队便寄希望借助外部力量来提升团队成员的能力。这种想法没什么毛病,毛病在于培训往往是无法有效解决,除非培训能够回答以下两个问题:

  1. 如何让团队成员的认知发生实质性的变化?
  2. 如何让团队成员能够将知识有效地转化成技能?

实践证明,单纯的培训很难回答这两个问题,所以存在培训无用论 的说法。而思沃内训团队一直致力于解决培训无用论 的问题。跟其他外部培训相比,内训团队得天独厚的优势在于根植于ThoughtWorks,深刻了解我们的文化,我们要做的是超越培训,真正帮助团队和组织有效地解决能力建设的问题。搞能力建设找思沃内训 是内训团队努力打造的品牌。


关于能力建设的思考

思沃内训团队经过长时间的打磨沉淀,积累了多门精品课,在培训授课环节称得上得心应手。但实践下来,我们也面临如同外部培训的相同困惑:培训之后无法确保团队发生实质性的提升和变化。 为求拨云见日,我们不停地尝试做一些不一样的事情。

提到团队能力建设,最理想的情况是团队内部自发组织,一来因为内部有更好的土壤去孕育生长,二来更符合自组织的敏捷团队特征。在ThoughtWorks内部也有很多自发的学习小组,一直在做这这样的事情。然而,随着公司业务的扩张,新老同事更替加速,能力建设难免会遭遇天花板,内训团队便担任起团队外部教练的重要角色。

作为教练,教练本身不会直接着手解决团队面临的问题,教练的主要职责是帮助团队自己解决问题,最终还是要依靠团队自身发力,可谓取之团队、用之团队。知易行难,做好这一点呢?带着这些思考,我们在武汉某海外Account做了一次尝试。


构建能力建设的闭环

要做到超越培训,我们必须在培训时、培训前和培训后三个阶段做一些不一样的事情,只有把培训的前、中、后三个阶段合为一体来对待,做到训前瞄准、训中调整、训后复审,才有可能将培训转化成一个有效的能力建设活动。

贯穿训前瞄准、训中调整、训后复审 的一条核心原则:跟团队保持紧密连接。在这一原则的指导下,通过四个关键步骤来帮助实现瞄准、调整、复审 的核心目标,这四个关键步骤形成了一个闭环,我把它叫做能力建设4D环:

在培训前,深入团队,分析团队现状,正确定义问题,针对问题给出解决方案,基于解决方案设计课程。在培训交付过程中,引导团队成员通过深刻的思考和讨论来颠覆或加强他们固有的认知。最后,通过部署计划(训战计划)帮助团队通过实践将知识转换成技能,从而解决所面临的问题。需要重点指出的是,设计课程贯穿训前和训中两个阶段。

定义问题 - 深入团队

在接到一个培训诉求的时候,我们通常会通过一些问卷或访谈之类的方式来调研确认培训需求,但如果只是这么做而草率推出一个培训,存在一定风险。因为问卷和访谈之类了解到的很可能不是真实的全貌。

为了规避类似风险,我出差到团队现场。跟TLF2F详细沟通,我对团队日常状态、技术栈选型以及人员情况做了一个全面的了解,对团队做了初步的分析:

基于现状分析,跟TL达成初步方案是上四抓手(TDD, Refactoring, Clean Code, Simple Design)。对于四抓手,不要胡子眉毛一把抓,要弄清楚团队当前哪些是做的不错的,哪些是做的不够好的,以及哪些是团队还没有做的。我开始Review代码库,参加团队的Code Review,发现代码库测试覆盖率高达90%,代码分层、模块化都做的很好(似乎已经做的很好了)。

通过进一步了解,得知团队刚刚对代码库做个较大规模的重构,另外因为目前代码量不大业务还不足够复杂,目前状况良好。而团队成员一致表达想尝试TDD,但苦于不知道TDD的正确打开姿势如何,只有个别人在尝试,未大面积推广。

基于这些调研我开始对问题域划重点,最终定义了两个问题:

  1. Second Tier入职时间短,相关敏捷技术实践掌握不佳,影响后期交付质量。
  2. 技术实践在后期Ramp-up保持最佳姿势一致性有难度,存在辜负客户期望、降低客户信任度的风险。

设计课程 - 量身定制

跟团队达成一致,我们推荐课程使用OO Bootcamp作为载体,并分8次课程进行,平均每周三次,每次晚上2~3小时。

从问题来看,此次能力建设活动属于风险预防性质的。可能你会想,既然没有太大的痛点,犹如锦上添花,拼凑一些标准化的课件就完事了。如果图省事这么做便错失一个良机 – 团队已经在尝试的过程中产生困惑,渴望得到解答,并通过实践掌握最佳姿势

所以我得利用好良机,配合时间安排的间隔特殊性,我在前期设计重点考虑了两点:

  1. 定制化课件。针对团队的真实情况做适当的定制化,并做好在交付的过程随时调整的准备。
  2. 螺旋化过程。在课程中能够不断激发思考,试图让大家经历困惑、解惑、疑惑、再解惑、再疑惑的螺旋过程。

交付培训 - 精雕细研

本环节的核心目标是:通过持续调整的课程辅以螺旋化过程来达到精雕细研。

在培训一开始的时候我再次收集了所有人当前面临的问题以及他们对此次培训的期望,第一场热身结束后,基于大家提出的问题随即在第二场做出了调整 – 给TDD划重点。

要做到螺旋式的精雕细研,最重要的一点是:放慢步伐,不以完成授课内容为目标,而是以大家讨论解惑为宗旨。因为参与这次培训的成员特殊性(TL & Second Tier),我将讨论的关注点控制在:价值层面(Why) over 操作层面(How),通过实际操练How引发讨论,并在HowWhy之间螺旋交替冲击,最终回归到Why上,讨论主要围绕团队日常工作中的困惑展开。

非常有意思是,当大家对价值层面理解达成一致后,在操作层面的最佳实践往往都是无果而终(By Experience),我们对最佳实践虽然未曾敢有明确的定义,但经过这样思维碰撞,团队往往能找到一些方向,比如TDD,做Story的时候,第一步是从业务视角去做Tasking,将Tasking可视化作为一个DoD[1],严格根据Task来编写测试用例,做到测试先行,并Pair来刻意练习。

在交付的过程中,我做的另外一件重要的事情是收集团队信息,了解他们当前面临的问题,根据问题的相关程度,对课程内容做临时调整,尝试对问题抛出一些方案建议,引发团队进一步的思考。比如如何在后端分层架构下做TDD。

部署计划 - 技能转换

我认为一个好的培训应该由体验反思抽象行动四个部分组成,相辅相成,并且能够形成一个闭环。在培训过程中,一上来需求驱动、编码实践就是一种体验,在体验的过程中引发思考和讨论,最理想的情况下是学员自己能够从思考和讨论中抽象总结出结论,然后将结论付诸行动得以验证。

在文章一开始我就提到,能力建设最终要靠团队自身发力,主动权必须还给团队,否则一旦教练离场,打回原形的风险很大。通过精雕细研的过程颠覆了认知只完成了一小半的工作,另外一大半的工作是让大家将这些新的认知在实践中去验证。要打好下半场比赛,就需要搬出训战计划法宝了。

训战计划类似于一个计划,它具备三个重要特征:

  1. 符合SMART[2]原则,并且不能太容易
  2. 学员自己拟定并认可签字
  3. 跟项目诉求息息相关

教练需要协助团队成员去制定有效的训战计划,核实是否符合以上三个特征。制定了有效的训战计划,就一定能够兑现吗?最理想情况下,团队成员的能够足够自我管理,并落实好计划。必要的时候,需要借助一些轻量的管理机制和有效的激励机制,比如,组建分队,队长责任制,并公开承诺,另外对计划完成后进行奖励等。

作为教练,后期需要重点做的两件事情:

  1. 训战计划执行期间,响应团队的诉求,帮助团队解决执行过程面临的阻碍。
  2. 定期回访,跟踪训战计划的落实情况,了解团队的困难,并记录团队的变化。

总结

训前瞄准、训中调整、训后复审 是一种基于Account的新模式,借助能力建设4D环可以帮助我们更好的打造一场高效的能力建设活动,做到取之于团队,用之于团队

在ThoughtWorks内部,存在一支这样的队伍,他们的理念是:培训是为了颠覆认知,将知识转化为技能,从而解决实际问题,而不只是Know Unknown

在ThoughtWorks内部,存在很多类似的本次活动的团队,积极参与、积极思考、积极实践、积极分享,在追求卓越的道路上永不止步。


注释

  1. DoD, Definition of Done
  2. SMART
    • Specific
    • Measurable
    • Attainable
    • Relevant
    • Time-bound


期待与你交流,我的联系方式:邮箱 | 微信

Posted by 袁慎建@ThoughtWorks • January 5th, 2019

版权声明:自由转载•非商用•非衍生•保持署名 | Creative Commons BY-NC-ND 4.0

原文链接:https://sjyuan.cc/account-based-training/
支持原创
⤧  Previous post 聊聊面向对象设计中的Is-A