小而美的团队在成长中会遇到哪些难题？从100人到1000人
以下文章来源于TGO鲲鹏会 ，作者沈淦
上图是目前大搜车的研发团队情况，2016 年底，团队大概是 120 人左右；2017 年，团队人数达到 300 人，相当于翻了三倍；2018 年，团队人数有 600 人，到了年底就有了 900 多人；今年，团队人数已经突破了 1100 人。
在团队成长的过程中，我们在比较早期就开始强调打造技术管理能力。技术管理，简单来说就是把技术和人很好的结合在一起。虽然通常管理学上的内容也都适用技术管理的场景，但技术管理因为有比较强的特点，因此还需要加上一些技术人特有的色彩才能打造真正意义上好的技术团队。
为了方便讨论，我将团队的成长分为 4 个阶段，针对每个阶段团队比较突出的痛点进行简单的讨论，然后再分享我们团队针对这些痛点分别所采取的对策和实践，这些痛点很大一部分来自于团队中不同层级管理者的局限性。
在人数比较少的时候，一个小团队的主要痛点大部分和 Leader 自身的技术能力和格局有关。举个例子，在不少团队中都存在这样的同学，他一个人可以亲力亲为 Coding，并把很多事情干得很好，但是他可能不擅长做架构规划、系统分析等工作。在团队规模处于小而美的阶段，我对 Leader 的要求一个是基本功要扎实，另一个是架构能力、抽象能力、设计能力，包括前瞻性技术规划的能力要稍微有一点儿。在我们团队中，在团队人数较少的阶段，管理方式基本以 Leader 个人风格为主。动手能力强的 Leader，相对比较喜欢更多亲力亲为的管理方式；而有些人就喜欢放羊式管理，比较随意，团队成员也比较自由一些。
随着团队的成长，一个小而美的团队快速扩大到扁平化结构的团队。当 Leader 们需要处理的管理工作越来越多时，带领团队能力的差异问题就马上显现出来了。
这个阶段，管理团队成员的心态开始出现差异，有些同学自身技术功底不错，但是相对而言，技术管理能力比较弱，如果只靠亲力亲为地建立团队纽带，那么很难在团队中形成系统化的管理行为；还有些同学，因为有比较强的沟通能力，所以他能自发地在日常工作加入一些管理动作，从而慢慢积累了一些自己的心得和体会。
这时，我们通过外部培训、拆书及内部训练营等方式引入一些技术管理的思维框架和具体工具，引导大家去思考究竟什么样的人才是严格意义上的技术管理者，训练大家深入理解和掌握诸如评价与考核、管理规划、团队建设等技术管理工作的认知和技能。这时，团队中开始有不少同学在日常工作中有意识地进行技术管理方面有益的尝试。
当规模再大一些时，团队容易出现一个比较严重的问题——整体技术管理的能力远远跟不上团队规模增长的速度。技术管理能力包括技术视野和技术格局，以及诸如交付能力、运行保障能力、带团队能力等这些需要真正落在具体工作场景中的核心技术能力（我们称之为技术人的硬实力），也包括诸如上面讨论的团队规划、绩效考核、团队建设等偏软性的技术管理能力。
既然我们提到了在团队规模变化到不同程度时出现的一些问题，那么我们在遇到这些问题时，该如何解决呢？
首先，我认为如果是一个快速成长的团队都应该被当作一次创业，创业本身就是一帮“不合格”的人去干有挑战的事。在“创业”的过程中，需要不断地建立团队自我成长能力，不断打磨、检验自己的团队。因此，打磨团队的能力对一个创业团队来说是一项十分重要的生存技能。
打磨出一个优秀的团队，我们从队形、执行力、目标导向、在线等四个方面着手，积累了一些经验。简单的说，队形就是聚心；执行力就是聚力；目标导向就是聚焦；在线就是拿结果。
作为一名团队 Leader，需要理解打造团队是日常工作首当其冲的任务，这项任务的优先级和复杂度都远高于具体的产品和项目推进类型的工作。意识到这一点对于一个技术 Leader 来说是非常重要的。
在实际工作中，有些同学对做具体项目充满热情，但是却对打造团队的工作缺乏兴趣，或者有畏难情绪，导致自己所带领的团队无法进入良性循环通道，久而久之，团队的战斗力越来越弱。无论在任何时期，作为团队 Leader，都要走在团队前面，为团队规划方向、定义技术路线和架构模型、建设与之匹配的团队组织结构、团队骨干和 backup。当然，不同的团队，在技术路线、架构模型、团队结构等方面的要求不相同。
用我们做一个新的系统开发来做类比。优秀的团队，在进行系统建设之前，一定会先定义系统架构（哪怕只画一张概要的系统架构图），而不是一上来就直接进行 Coding。有了规划之后，会不会在具体执行时出现和实际脱节的现象呢？答案是肯定会有的。规划的作用是明确方向，并在执行时不断检查和调整。因此，团队的顶层架构和规划不但必须先行，而且还需要定期的 review 和调整。
组织架构先行的认知建立起来后，你可能会遇到另一个问题——我是先搭好台子，还是先找人呢？我的建议是，先搭台子，再找靠谱的人。
以大搜车 2016 年至今的团队架构迭代为例，看看大搜车的团队架构发生了哪些变动。
2016 年时，我们只有 3 个团队：车牛、大风车、弹个车。
到了 2017 年，我们将大量业务铺开，形成了平台架构部、金融业务开发部、各类开发部和一个上海分部，这是一种扁平的状态。
2018 年时，我们认为之前的团队架构不太适合当时的发展情况，因此我们将团队改为了一个有点像中型标准公司的团队架构，其中包含了行业开发团队、技术保障团队、工程效率团队等，每个行业线上都有专门做业务、应用、共享服务和业务平台的部门。
今年，大搜车又有了全新的布局，每个业务前台在不同的事业部里都有自己的研发团队，所有研发团队都依赖统一的研发中台底座。研发中台里包含了技术平台、业务平台、共享服务平台、支付平台、数据平台等，以及一个服务公司后台和职能部门的开发团队。
实际上，大搜车在每一次组织架构迭代调整的过程中，都是通过很多很小的调整最终聚集成一个大的调整；通过组织结构每一次小的迭代，形成组织结构的进化。
执行力比较硬核的东西就是要有扎实的技术功底，其中包括纯技术功底、工程能力、技术视野、架构和细分能力、分布式系统设计、领域建模等，技术功底是技术管理者必须跨过去的门槛。简单来说就是，我不会写你的代码没关系，但是必须具备判断代码好坏的能力。
除了硬实力之外，软实力也非常的重要，对于不少从技术一线一路打怪升级上来的技术管理者来说，软实力一直是相对比较欠缺的部分。
软实力主要分为两部分，一部分是偏技术管理方向，另外一部分是偏纯管理方向。当你职位越高时，沟通能力、情商、向上管理能力相对来说也就越重要；除此之外，作为一名技术管理者更重要的是自身技术管理能力的提升，尤其是角色认知、规划能力、项目管理能力等。
在推进技术管理团队软实力提升的过程中，我发现不同的方式产生的效果是不一样的。为什么会产生这样一个差别呢？我认为核心原因是承载这些软实力的思维框架和认知，有别于硬实力型的知识模型。技术同学按照传统的学习方式掌握软技能落地效果往往大打折扣。
我想分享几个提高执行力落地的方式，一个叫拆书，也就是通过一个统一的集体行为，来达成集体共识；另一个叫翻转课堂，来打造集体学习集体成长的氛围和环境。翻转课堂的具体方式大致是：确定集体成长的目标；约定预习时间和预习要求；预习结束后，大家集中在一个相对舒适的封闭空间，由讲师进行知识点的快速串讲；然后大家利用预习和串讲时所收获的知识进行主题 PK。后来，我们将拆书和翻转课堂结合起来，变成了一个成长训练营，具体流程可参考下图：
目标导向
通过组织架构的持续迭代，我们的整体队形和能力整齐了，但是大家的目标还没有完全聚焦和统一。因此，我们第三件武器就是目标导向，使用的工具是 OKR。为了让团队更好的掌握 OKR 工具，我们也这采用了通过成长训练营来推进的方式。
上图是内容推进流程，是一个非常严格执行的流程，里面每一个环节都是有非常强的实践落地的过程。
OKR 的落地，大致分宣贯、定义、执行和评估四个环节。并通过这四个环节的反复迭代，形成闭环（一般以季度为单位）。大多数团队对 OKR 的定义环节都执行的比较深入，这方面的经验和案例分享也相对比较多，这里就不在赘述，我在这里重点强调一下执行和评估。
执行环节，我们在一个开源工具的基础上自研了符合我们实际需求的 OKR Action 记录跟踪系统，以周为单位记录、跟踪和回顾每个 KR 在本周产生实际效果的 Action。同时，我们还采用 IRR 沟通模型的方式来推进回顾环节（仍然以周为单位）。执行和回顾环节在 OKR 落地中所占的时间比重很大，同时也是让 OKR 真正发挥威力的很关键的环节。常规的推进方式有两种，一种是团队全员进行讨论，另一种是一对一。大搜车采取的是一对一的方式，同学和他的 Leader 进行一对一对话，针对 OKR 系统中每个 KR 下本周发生的 Action 进行逐一的讨论、聚焦、反馈和更新。
为什么我们要强调 IRR 对话模型的重要性呢？通常来说，如果不建立一种能产生反馈并凝聚共识的对话模型，那么 OKR 的评估环节很可能变成了工作汇报的方式，与我们期望的 OKR 评估活动的收益相差甚远。IRR 是一个互动的过程，参与方除了建立一个线上信息流的平台之外，还需要复盘和达成共识。想要达成共识，一方面是对你本周的推进结果形成共识；另一方面是对后续的推进形成共识。
在每个季度的关键时间节点，还需要进行相对比较大的回顾，一般大型回顾是一个月做一次，主要目的是对 KR 进行修正和调整。另外在季度结束时，也需要对本季度的整体 OKR 执行情况进行全面的回顾和评估，产生的结论也会作为下一个季度制定 OKR 的主要依据之一。这些评估活动，我们目前也计划在通过在线化工具的方式来进行。
除了做好队形、执行力、目标导向之外，我们还要关注自己拿到的是什么样的结果。作为技术人，我们希望有一个更直观、明确的结果，那就是在线。一切行为在线，一切结果在线。用在线的方式来推进工作的最大好处是，由于工作的行为在线化，导致我们可以用比较低的成本对结果进行数字化的透明的评估。一切不能在线的行为都是无法客观评价结果，一切无法评价结果的行为都是“耍流氓”。很多时候，一件事情就算说得再多再好，如果无法在线化，形成开放透明甚至自动的结果评估，都会使工作陷入自嗨模式，甚至与业务价值渐行渐远。反之，通过良好的在线，快速推进技术和业务迭代的例子也比比皆是。
我们主要通过打造全面覆盖研发活动流水线的 DevOps 平台来达到在线的效果，DevOps 平台主要从过程管理、工程环境、运行保障、工程效率等几个方面来建设。
运行保障
目前，运行保障主要指的是监控和报警。对于一个团队来说，工程能力主要体现在如何看待线上。如果你认为自己的东西交付后就代表结束，那么你的工程意识还差得很远。因为一款产品到了线上之后，才是开始发光、发热，这比你把它从 0 到 1 做出来更重要。
另外就是全链路和日志平台，现在基本上是每一个互联网公司的标配了。
工程效率
工程效率简单来说就是打造一个完整的构建流水线。当你的团队业务流程比较复杂时，我建议大家尽快地去启动这方面的工作，将构建和测试环节尽最大程度自动化。
下图中的脑图是我们用来生成黑盒测试的一个工具。
过程管理
第三部分是过程管理，项目管理是项目推进，主要是把项目每个节点的情况在线化的过程。
另外，就是故障响应的部分。目前，我们都是通过钉钉来处理故障。我们在钉钉里设计了一套语法，比如你可以想要报工单，或者记录某些内容，都可以在聊天的窗口中完成。
过程管理中还有一个很重要的就是提测单和发布单，分别对提测和发布两大节点进行管控。
工程环境
当团队规模变大后，多环境的建设变得非常重要。在开发环境和测试环境下并行工作的项目数量非常多，所以工程师对开发环境、测试环境能支持多环境的需求也比较旺盛。早期，我们采用虚拟机的方式进行环境资源的管理。随着业务规模的不断扩大，虚拟机的方式很难跟上业务和系统迭代的速度，今年开始，我们逐渐把虚拟机方式向容器方式切换，使开发和测试同学能通过自助方式申请资源。
在实际工作中，不同类型的项目对项目节点的要求不同，导致在每个节点上需要完成的小的流水线目标和具体流程也不同。所以我们现在把它变成一种开放自助的方式，每个项目都可以根据自己的实际情况建立项目在不同节点上的流水线闭环。
上述讨论的内容都是比较偏行为在线的范畴，我们之所以把全部的行为都在线的目的，一方面为了提升效能；另一方面，行为在线为后续的工程效率分享迭代提供了很强的数据基础，我们可以在此之上分析整个工程方式的合理性，并加以迭代。
结果在线还有一个比较实用的价值，可以利用在线的结果（比如故障响应时长）在团队中快速建立一些人性化的奖惩机制，从而达到快速推进工程迭代的效果。
今天，我主要针对队形、执行力、目标导向和在线四件技术管理的武器进行了简单的分享。最后用一句话来作为小结：技术 Leader 没有天花板。
在我们整个技术管理工作中，大部分同学都会在某个阶段面临技术管理和自己能力不匹配的困境。从我自己以往的经验来看，我们绝大部分同学其实还远没达到自己的能力极限，唯一的差别在于，有些同学不断突破自我，不断打破自己的能力和认知天花板，而有些同学则固步不前。作为一个技术管理者，我们也应该有勇气去进行一次又一次的突破。如果说真有一个彻底无法突破的天花板的话，那么，这个天花板应该就存在于你自己的心里。
往期推荐
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。