团队在高速扩张中的能力构建与质量保证

快速的人员扩张对我们来说是个幸福的烦恼，是一把双刃剑：一方面要的人多了可以带来更多的收入，但是另一方面，如何招人，如何培养人，如何避免新人出质量问题？如果质量问题频繁发生，很可能丢失我们和客户已经建立起来的信任。

ThoughtWorks 合作的一个海外运输行业客户，希望在 2019 新财年，从原来的一个不到 20 人的小研发团队在未来 3 个月内扩张到 60 多人，希望更快速的交付更多新功能，希望构建完善的人才梯队，避免因为快速扩张而引发质量问题、线上事故。

图：某团队人员扩张曲线

总结来说，这个案例会系统化的介绍整个过程中的问题、挑战和所收获的经验和教训，包括如下三点：

• 如何缩短新人的成熟时间、加快交付速率的同时保证质量、避免线上事故？
• 如何构建良性团队氛围，减少知识的稀释，形成合适的人才梯队？
• 如何从手把手的知识传递，变为自组织自学习团队?

最终构一个安全有效的团队快速扩张体系。

Js中文网 – 前端进阶资源教程 www.javascriptC.com,typescript 中文手册
专注分享前端知识，你想要的，在这里都能找到

经过 3 个多月的努力，我们最终做到了客户的要求，通过分析统计可以看到，2018 年 1 月到 6 月严重的线上事故有 4 起，在新人员快速增长的下半年，7 月到 12 月有 5 起，2019 年上半年 1 月到 6 月 1 起，7 月之后到现在还没有发生，结果是好的，但是过程是曲折的。

图：线上事故统计分析

在这样的背景和挑战下，团队是怎么做到的呢? 总结来说主要包括下面四个方面:

图：案例核心要点

• 快速人员成长
• 线上事故回顾 – 报忧文化
• 人才梯队构建
• 社区 & 自学习团队

快速人员成长

在讨论快速人员成长之前，让我们回顾一下常规的新人成长方式，一般情况下我们会为新人指派一名有经验的“师傅”，作为他 / 她的 Onboarding 伙伴，他们一起 Pair 结对编程，在日常工作中交换知识，学习并成长。新人的 Onboarding 速度，理解知识的速度，取决于师傅的技能，如果师傅擅长带新人，则 Onboarding 掌握项目技能的时间大大缩短。

这非常类似于美国南北战争中枪支的制造过程。它依赖于工匠，有时制成的枪看起来不错，但精准度却很差，很难击中目标，或者该枪看起来一般但精准度度很高，容易击中目标，但是也有可能外观和精准度都很差。因此，枪支的精准度和制造时间取决于工匠的手艺，这种情况与 Onboarding 过程中的“师傅”非常相似。众所周知，在那场美国南北战争中，北方赢得了内战，原因之一是他们开发了一种新的枪支生产方法，用标准化的零件来组装枪支。

图：美国南北战争的枪支

在团队开始人员成长的过程中，我们也在思考并实践，是否可以从原来老带新，依靠师傅手艺的方式，转变成流程化的快速成长过程？加速新人成熟过程，并保证带出来的人一定是项目可用的呢？

快速人员成长，团队主要做了下面四个活动，以构建一个有规可循的新人快速成长流程:

• CraftSkill Map，梳理完整的技术能力图谱，可视化人员需要掌握的能力。
• 制定 Onboarding 流程，各个阶段的 Homework 家庭作业和检查点。
• 一致期望，新成员状态看板，红黄绿三状态跟踪人员状态，尽早发现风险并采取措。
• Case by Case 针对性培训，量身定制、认知转变、技能转换。

CraftSkill Map，项目能力图谱。当一个新成员在加入项目的时候常常会问这个项目是干什么的？需要解决什么问题？使用了那些技术栈？我该怎么开始？所以非常有必要给新人一个可视化的能力图谱，让新人在一开始就对项目有一个全局的认识，做到我知道我还有很多不知道的内容。根据我们的实践，我们把能力图谱中知识点进行了分类: 红色是主要大类，如: Back-End，Front-End，Business 等。浅绿色是大类下的小类，这些内容是 Class room training, 是可以通过准备学习资料、比如: wiki page、homework，让新人先自学，然后再根据问题来解答，以此进行学习。比如语言特性: Linq, Async/Await, Nulable Type 等。这好比制造枪管的过程，可以方便快速的流程话，人工干预少，验收方便，枪管直不直，机器自动化一量就好，Class room training 里的 Homework unit test 通过了就是通过了，没通过就是没通过。还有一类标记为粉红色的内容是 Pair and day to day training，是需要有人协助在工作过程中进行知识导入和结对编程的，靠自学和问题解答效率不高，比如 SOLID 原则，Design Pattern 等。这好比制造枪的撞针，需要初步组装，师傅干预，帮助校验和矫正。可以把能力图谱打印出来贴在团队的工作区域可以让每位成员都可以看到。实践证明团队里 Class room training 比例越高，能节约的人工成本越高。

图：能力图谱 第一版

CraftSkill Map 根据团队不断的运转和实践也在不断的演进和迭代，下面这一版更加细化的梳理了项目需要的各项能力，更加直观可视化的展示了项目需要的能力。

图：能力图谱 第二版

除了能力图谱，为团队梳理一个完整的 Onboarding 流程，也非常重要，给新人一个清晰的 Onboarding 旅程。让他 / 她进入项目的第一时刻就明白接下来的每个步骤都要做什么。如下图最左边是新人加入项目的那天，最右边是新人完成 Onboarding，成为 ProjectReady 的成员。他可以胜任项目的工作，根据任务评估，在中等时间花费下（不会太长时间，也不会太短），完成项目里中等难度的任务。比如一个中等难度的任务，团队的评估是 3 个 StoryPoints，大概花费 3 天时间，新人 ProjectReady，可以独立工作，领取这个任务，在 3 天内完成。

新人 Onboarding 的第一天会先和项目负责人，会谈半个小时，新人了解项目大体情况和背景，项目了解新人的期望和诉求，如果项目有安全需求比如 PCI，PII 等要求，需要第一时间告知新人，开始学习并遵守。

第二站新人和项目的技术负责人进行半小时的会谈，新人了解项目的技术栈和 Highlevel 架构设计，项目了解新人的技术背景，进行技术基础和匹配度评估，并初步设定 Onboarding 的大致时间，一般是 2 周到 4 周，并指定新人的 buddy(伙伴)。

Team 组建的大小一般是 1 pizza team 或者 2 pizza team 大小，人数不多一般是 7 到 8 人，在午饭的时候定 1 到 2 份 pizza 大家就能吃饱了。新人加入 Team 后，会在 Team 中找一位有经验的人作为新人的 buddy(伙伴)，会在整个 Onboarding 过程中，在日常工作中提供需要的支持和帮助。

新人首先学习项目的业务和技术，一段时间后会把 Team 里的这 6 到 7 个人召集起来，开一个 45 分钟的 Training showcase，新人介绍自己所学习的内容，Team 成员帮助查缺补漏，整个环节是一个非常有效的回顾过程，帮助新人理解掌握知识。

之后根据项目情况，侧重学习 Front-End、Back-End 或者 QA 的领域知识和技能，学习一段时间后，一样也会做一次 Training showcase。最后新人来到 DevOps 部分的学习，学习 Path to production，明白自己的代码提交后，是怎么完成到 Production 的，如果出问题了怎么 Debug，怎么修复上线。最后新人在 buddy 的支持下，领取任务，逐步开始独立工作。

当新人成熟后，进行一段时间的开发交付工作后，对自己 Onboarding 阶段侧重的技术栈熟悉并精通后 (比如: Front-End、Back-End 或者 QA)，一般 3 个月或者 6 个月以后，就可以开始考虑让有潜力和有兴趣的团队成员开始轮换到新的技术领域，比如 Back-End 换到 Front-End 等，以便打造全功能团队。

图：入职流程

有了 Onboarding 的流程，还需要流程的里程碑和执行时间。让流程执行的更有序和有效。根据我们的实践，我们为 0-3 年工作经验稍微少的新同事，制定了 4 周左右的 Onboaring 周期。每一周都有明确的里程碑。超过 3 年比较资深的同事，制定了 2 周左右的 Onboarding 周期，同样每一周也都有明确的里程碑。不论是否资深，他们最终要达到的 ProjectReady 是一样的，都可以领取任务，保质保量，独立完成工作。

图：入职里程碑

新人开始 Onboarding 后首先会拿到一个所有资料的索引页，所有资料都可以通过这个页面找到，并链接到详细内容页，比如下图详细的业务介绍。在最开始的时候我们采用 wiki 文档，让新人通过阅读 wiki 文档了解业务，我们思考能不能再快一点，再高效一点。后来采用了视频的方式，每个业务录制背景介绍和系统演示视频，每个大业务有 3 到 4 段视频，每个视频 50 分钟左右，大家可以通过视频更快速的了解业务。还能不能再快一点呢？后来我们又录制了 podcast，纯音频的业务介绍，大家可以在上班或者下班回家的路上带上耳机就可以学习业务知识了。下图是 Onboarding 里业务部分的 Class room training 资料。

图：业务学习资料

除了上面说的，视频的资料。我们也准备了 Homework 家庭作业，Homework 是 Class room training 里最重要的部分，如下图，最右边是为学习 C#准备的，是一组 Unit test，新人通过完成这些 Unit test 来学习 C#。有时候新人进入项目，我们可能会给他 / 她一本书，让他 / 她看书来学习。我们发现这种方法效率比较低，有没有更快的方法呢？后来发现 Unit test 是一个非常好的途径，把知识点全部转化成 Unit test，我们总共做了 40 多个 Unit test 覆盖的常规的语言特性，比如：字符串的处理、浮点数的处理、文件的处理等。新人只要有一些编程经验和常规面向对象的认知，即便之前没接触过 C#，比如之前是擅长 Java 技术，通过完成 Unit test，他 / 她也可以非常快的从当前的语言转换到项目所需要的语言。根据我们的发现，这比让他 / 他看书学习的效率要高很多，最快的用了 4 个小时就熟悉了 C#语言。除了学习语言的 Unit test，我们还有前端的学习资料：React Todo List 作业，使用 React Redux 做一个 Todo List 的 WebApp，通过这个练习，新人可以很快的上手 React 框架。还有中间这一块是 Website 开发知识，我们准备了一个在线书店的 Website 开发作业，新人可以通过完成这个 Website，学习路由怎么做、Session 怎么处理、Web request 的整个生命周期，等等 Website 开发所需要的常规知识。

图：技术学习资料

除了常规知识的 Homework。我们还定制了一套基于项目的 Homework，由于项目的技术栈是基于一个 SOA 服务的，所有的数据查询、提交、存储操作都不需要直接对数据库进行访问，而需要通过调用这个 SOA 服务所提供的 DSL 来实现。为了让新人学习理解这一套 SOA 服务和 DSL。我们真对性的准备了一套 Homework，这套 Homework 在项目实际代码仓库下的一个分支里，根据项目的一个真实功能而改编。新人通过在这个分支上工作，完成这个功能来学习这套 SOA 服务框架和 DSL。当新人 Checkout 到这个分支，可以看到左边是这个 Homework 的背景介绍和所需要学习的知识点。右边的是我们已经准备了 12 个 Homework 需要写代码的地方，每个地方有详细的注释，比如图里这个例子，新人需要在这里加一个 ViewModel，把数据从 request 接进来，根据注释和学习资料进行学习，当完成学习后，掌握 ViewModel 这个知识点。我们总共设计了 12 个点，搜索#homework，就可以找到这 12 个点，学习并完成这 12 个点后，就基本可以掌握最常规的 80% 的知识点了，至此新人完全可以开始独立在这个框架下工作了。

图：项目框架学习资料

新人状态看板，由于同一时间上新人的数量比较大，我们希望减低上新人的风险，希望每位新人最终经过两周到四周后，都能达到 ProjectReady 的程度。所以我们采用了新人状态看板来监控每个新人的状态。

前面提过，我们会为每一个新人指派一名 Buddy(伙伴)，Buddy 会和新人工作在一个 team 里。Buddy 一般会选工作经验比较久，在项目里时间比较长的老人。Buddy 会为新人提供在 Onboarding 过程中所有的帮助和支持。

在开始大规模上新人的时候，每周会在周三和周五的时候把所有 Buddy 都叫到一个会议室里。Buddy 需要更新自己所带新人的状态，是红、黄、还是绿？绿的含义是：自己所带的这个新人，从当前的实践来看，按照预期到 ProjectReady 是没有风险的。黄的含义是：有一定风险，需要针对性的制定一些 Action 行动，降低或消除这个风险，让新人最终能在规定的时间内 ProductReady。红色的含义是：所带的这个新人可能已经 out of the control，风险已经不在自己能力的控制范围内了，可能需要公司的 People team 或者 HR team 一同介入，了解一下这个人当前的状态，是否需要一些外界的帮助？一起制定接下来的帮助或者行动 Action，或者根据他 / 她的意愿进行调换，可能到别的更适合的项目去。

图：新人状态看板

经验教训，经过这三个月到六个月的大规模上新人的时期，我们回顾了一下在这个过程中的经验教训：

• 总共加入 55 位新成员，4 位未通过 Onboarding 流程，被淘汰。有人没有通过 Onboarding 流程被淘汰。被换到别的项目，或没有过试用期离开公司。我们觉得 55 新成员，4 位未通过，这是一个比较正常的比例。
• 新成员明确知道 “Project Ready” 到底需要什么，完成赋能，开始独立交付工作。在新人进入项目的那一天，我们就帮他 / 她介绍了项目，说明了下面的 Onboarding 流程，什么是 ProjectReady，同时也为他 / 她指定了一路同行的 Buddy。以便更好的明确 ProjectRead，保质保量完成 Onboarding 的整个旅程，最终开始独立工作。
• 自组织，自驱动，自迭代的 Onboarding 赋能过程。我们的 CraftSkill Map，Homework，等都是在 Onboarding 的过程中不断地迭代，不断地改进行成的。
• 形成人员快速成长标准流程，加速新成员成长。再回到当初的那个问题。是否可以从原来老带新，依靠师傅手艺的方式，转变成流程化的快速成才过程？加速新人成熟过程？经过前面的不断摸索，我们基本上找到了一个流程，能解放一部分老人带新人所花费的时间。

我们抽取了一些数据，想分析一下，看看这个 Onboarding 流程，到底有没有加速新人上项目时间？如下图左边，我们抽取了相似背景的新人，比如都是三年左右工作经验，都在 Onboarding 过程中是黄色，出现风险的。或者都是五年左右工作经验，Onboading 过程是绿色，没有风险的。统计数据如下图右边，可以看到 Onboarding 流程，缩短了新人上项目的时间。但是我们也发现了一个有意思的情况，新人的工作经验大于七年的这几位新成员，Onboarding 流程基本没怎么加速，和一对一，老人带新人的方式，没有什么提升，上项目的时间都非常快。主要是一些工作经验少的人，Onboarding 流程可以加速他们上项目，到 ProjectReady 的时间。也就是说，新人的资历越浅 Onboarding 流程所起到的作用会越大一些。

图：入职情况分析总结

现在我们也还在不断的优化这个 Onboarding 流程，让它更快，在小于四周的时间内完成。

线上事故回顾 – 报忧文化

线上事故回顾 – 报忧文化，也是团队在高速扩张中的能力构建与质量保证的一个非常重要的部分。报忧文化其实是我们从 Google 学到的。Google 有一个专门讲报忧文化的网页。就是下面截图的内容。Postmortem culture。直接翻译成中文是验尸文化。Learning from failure 从失败中进行学习。The cost of failure is a education。失败的代价也是一次教学。我们将其转换为自己的“Good news and bad news”文化。项目的负责人在跟大家开全员大会的时候，很多时候只说好消息，比如说：我们又赢得了新的客户，销售额又增长了。但是很少说不好的消息。Google 的实践是，对失败 (线上事故) 学习 (验尸) 并在全员大会的时候公开给大家，不是只说好消息，同时也说不好都消息，比如：我们的某个服务又宕机了 1 小时，损失了多少收入，供大家学习和反思，避免再次发生。

图：报忧文化

我们在自己的项目上也总结了线上事故回顾模板。例如下图，回顾总结事故的 Summary、Impact、 Rout cause、Trigger、Resolution、Detection、Action items 后续行动，通过这些行动以便阻止这类事故的再次发生，或者缓解这类事故发生的机率。Lessons and Learned 事故的教训，在整个事故中做的好的，做的不好的？在这次事故中比较幸运的事情，最后是整个事故的时间轴。每个线上事故都会这样总结，并分享给全项目组。

图：线上事故回顾模板

线上事故回顾 – 报忧文化，总结有下面几方面的好处。

• Lessons and Learned、Timeline、增强 Log、后续 Actions、实施效果。
• 提升功能测试覆盖率，增强质量保障。
• One Team 线上事故实战经验分享，增进团队融合。

如下图，经过三个月到六个月的努力，我们最终做到了客户的要求，通过分析统计可以看到，2018 年 1 月到 6 月严重的线上事故有 4 起，在人员快速增长的下半年，7 月到 12 月有 5 起，2019 年上半年 1 月到 6 月 1 起，7 月之后到现在还没有发生。

图：线上事故统计分析

同时这也是现在业界比较流行的度量团队效能的一个维度，从 2019 DevOps 4 Matrix 来看 Change failure rate 和线上事故的发生率非常一致，也是一个很好的度量团队效能的维度。即便是没有在大规模上新人的时期，也可以实践一下线上事故回顾 – 报忧文化，度量并改进一下项目的 Change failure rate.

图：DevOps 4 个关键指标

人才梯队构建

为了防止项目新人过多所带来的文化稀释，知识稀释。人才梯队建设是非常有必要的。才梯度构建主要包括下面三个方面:

• 可视化人才梯队看板。PM/TL、SecondTire、KeyContributor、Others、Risk
• 每季度基于 Facts 的 Review，进行梯队调整。
• 梳理人员提升 Actions、帮助团队成员提升。

图：人才梯度看板

如上图人才看板。人才看板，把团队里的人分为了五个阶段：PM/TL、SecondTire、KeyContributor、Others、Risk。PM/TL：项目负责人 / 技术负责人。SecondTire: 很有潜力成为项目负责人 / 技术负责人的第二梯队。KeyContributor：项目主要贡献者。Others：一般人员。Risk：有风险人员。同时每个阶段里再分为：Well done 完全准备好了，找机会随时进入下一个阶段。Medium 中等，还需要锻炼。Medium Rate 刚刚进入这个阶段，还需要不少锻炼。

我们分为主要的五个维度进行打分和度量，以评估团队成员现在所处哪个阶段。这五个维度是？Contribution、Customer focus、Skill、Impact、Develop Others. 由于我们项目的工作性质，工作内容。我们定义了这五个维度，当然你可以根据你的项目，你的工作，按照你的需求，来定义适合你项目所需要和关注的维度（可参考 StrengthsFinder 2.0 来设计你自己需要关注的维度）。

每个季度，我们会根据每位成员在项目里所做的工作，发生的事实，按照这五个维度进行打分，区分团队成员所在的阶段和分维度打分只是一个方法，最重要的目标是帮助团队成员提升，让他 / 她们发展自己，遇到更好的自己。所以对于 review 回顾最重要的是提出改善意见，希望团队成员不断的在人才看板上向前移动，最后成为项目的主要负责人 / 技术负责人，可以自己去开启并负责一个新项目。

社区 & 自学习团队

社区，自学习，是激活团队氛围，形成良性知识分享土壤的有效实践。社区 & 自学习团队，主要包括对内对外下面两点：

• 内部形成技术 Chapter, 构建规律的技术分享活动。
• 外部打开眼界，关注行业，融入社区，从参与者到讲师、激活团队氛围、形成良性循环。

图：ING’s New Agile Organizational Model Has No Fixed Structure—It Constantly Evolves. (Source ING)

上图是现在比较流行的一个项目团队的组织结构图。这个竖向的，黄色的 Squad，其实就是我们的 1 pizza team, 一个全功能团队。多个这种全功能型团队就组成了整个项目团队，就是这里画的 Tribe。Chapter 是这个横的蓝色的框框。我们需要构建这样的 Chapter。比如说一个项目上，所有的前端人员组成一个 Chapter，所有的后端人员组成一个 Chapter，所有的 QA 人员组成一个 Chapter。让各个 Chapter 内部进行分享。比如在后端 Chapter 里一起分享项目在后端上有哪些可以一起改进的东西 / 技术债，有哪些通用的东西，可能是某个 team 已经踩了坑，完全可以把经验分享给别的 team。我们的项目是有一个固定的时间，每周二、周三下午 4 点到 5 点，一个小时，每周两次，大家报名议题，来进行分享。前端是每天有半小时一起的 code diff，所有前端一起进行交流。QA 也是每周有碰头和分享。与此同时，项目上 Onboarding 的后端、前端、QA 的 Homework 也是由各个 Chapter 来牵头迭代改进的。

除了关注项目内所发生的事情，同时我们也应打开眼界，关注行业里都发生了什么，需要融入社区，这是一个非常好的激活团队的办法，希望团队借此形成一个良性的知识分享循环。参加外部的社区，学习外部不同的技术和经验，同时带回到项目中来，结合项目的工作，找到一个合适的地方去使用这些新技术，同时结合业务需求，形成有商业价值的功能。我们希望产生这样的化学效果，比如前端同事去参加外部活动，发现 AMP、PWA 其实可以结合项目上的一些需求，做一些东西来更好的服务用户。比如后端同事去参加社区活动，发现了一些新的性能调优的思路和工具，带回到项目来优化性能。QA 同事参加社区活动，发现契约测试对项目是有帮助的，开始在一些测试方法上进行改进。

图：活跃的社区

因为参与社区，有同事被 Google 作为社区优秀讲师，邀请到美国现场参加一年一度的 Google I/O。我也被邀请参加了 Google GDG 社区组织者东北亚峰会，一同讨论如何构建更好的社区。参加社区的同事反馈说：有人从不喜欢社交 social 交谈，变得更加自信和善谈。有人开始喜欢上写 Blog 做知识分享了。有人从听别人讲，尝试自己开始内部小范围讲 Session，然后到社区大范围演讲。

回顾 – 投入产出

• 不断完善的 Onboarding 流程，顺利完成了团队的高速、高质量扩张，避免了风险，提升了效率。
• 总计加入 55 位新成员，4 位未通过 Onboarding 流程，被淘汰。
• 从 1 对 1 的老带新的方式，演变为自组织自驱动体系，大大节约了时间成本。
• 构建人才梯队，防止知识稀释，并没有因为团队快速扩张，而产生额外的线上事故。

回顾 – 启示

最后，希望在这个议题里，可以有让大家有 Take away 带回去的东西。我总结了三点：

• 当需要快速完成新成员能力构建的时候？可以采用 CraftSkill Map，Onboarding 流程，新人状态看板。
• 当需要系统化的进行人才梯队构建，防止知识稀释的时候？可以采用人才看板，报忧文。
• 当需要激活团队氛围，形成良性知识分享土壤的时候？可以采用内部 Chapter 赋能，外部打开眼界，加入社区。

作者介绍：

张思楚，ThoughtWorks Tech Team Lead，高级咨询师。拥有超过 10 年的软件开发及项目管理经验，多项 Web 专利技术发明人，畅销 Web 产品 SpreadWeb 架构师。现专注于网站性能优化，综合信息系统基础平台的设计和研究。采用设计思维，精益式产品启动等方法，提高团队交付能力。采用 Ionic Hybrid 混合应用技术，实践复杂业务 App，多平台发布，节约移动端开发成本。深入客户现场，采用设计思维，精益产品启动，快速迭代演进新产品，尽早面向客户收集反馈，尽早验证产品。

链接：https://www.infoq.cn/article/HxvZbNKPxYXWJtE1gJzB