FreeWheel容力：如何打造更高质效的技术团队

技术团队的管理包罗万象。但归结到底，无非在于二字：道、术。

听过很多人讲二者间的关联，却大多未全然说透。道与术的关系本质上就是一个指导思想与具体手段的关系，是心法与招式的关系。从技术角度来看，管理中的“道理”、“心法”或可界定为技术定位、技术与业务的融合、企业文化、技术与哲学等；“方法”和“招式”，则就如技术团队组织架构、产品开发流程、制度规范的建立、架构设计等。

怎样将“心法”与“招式”融合在一套特殊的理念和决策之下，或是困惑多数技术管理者的一道难关。带着对如何打造顶尖技术团队、如何在技术、文化以及技术人成长间搭建更优桥梁、如何培养团队荣誉感及价值感等问题，InfoQ 专访了 FreeWheel 高级副总裁容力及其所领导的技术团队管理者（技术副总裁党政法、技术副总裁王强），了解在这样一支跨国团队协同合作的环境背景下，作为 300+ 人团队的总负责人，他是如何塑造高效敏捷的行动力、团队方向感、追逐感、凝聚力，以使庞大（甚至是跨国界、跨时区）的队伍能拥有更好的创新力和生命力。

曾在知乎上看过一个提问：“互联网公司，如何管理一个 8-10 人的技术团队？”，下列的跟评有着林林总总各式不同的看法，其中一人大致列了三条最简单也最复杂的见解，即了解人、了解事和了解业务。所以，我们和 FreeWheel 技术团队的交谈也从这几点开始。

公司高速发展的时候非常需要适时的管理。从刚刚成立扩展到几百人的规模，这是每个公司发展需要经历的一个很大的槛。有些企业疯狂式的增长，是对现实性的考虑模糊。我（FreeWheel 高级副总裁容力，以下均以第一人称“我”代之）观察到过去太多大公司人员的迅猛增长，并非是由公司的效益或业务需求所驱动的，而是取决于领导层的话语权。

FreeWheel 在 2007 年刚刚成立时只有 10 个人左右，2015 年 3 月我加入时已上升至 150 余人，而截至目前，FreeWheel 又扩增了一倍，达到 300 余人规模。经历十余年的发展，整个创业和探索的过程非常曲折和艰辛。但一直以来，团队的扩建都是由业务所驱动的（FreeWheel 每年保持大约 70% 的营收增长率），因此这决定着更为良性的增长动因和态势。

人员持续扩张的背后，“Hire the Best”是在招贤纳士时秉持的最重要的基准。何谓 Best，如何定义？表层意义上来说，Best 就是顶尖的，具体分析主要体现在两个方面：一个是在校招中，学历与毕业院校的卓越性，另一个更重要的是在技术上的扎实积淀和积累，放在不同的招聘环境下具有不同的侧重点。但同时，Hire the Best 的难点在于，你不能只看他现在会什么，而是要预测他将来是否能更快地学到更多。技术人的学习能力，其个人长期的潜质和潜力应该在面试环节得到更多的加分。

我个人有一个理念，不管是在应聘还是在招聘的时候，都会秉承一个非常浅显的道理：我们看待一个人适合不适合这家公司就看三点，第一，是这个人能为公司带来什么价值；第二，公司能带给他什么，双方是互利的过程，仅仅看这个人给公司带来什么，不看公司带给他什么，这个交易也谈不成；第三，这个人能够在公司做多久。我们是对人才的投资，工作也是他生命中贡献时间和青春很重要的一部分，所以是否能够长期在一家企业效力很重要。因行业而异，因公司而定。

如何从一线的工程师转成技术管理者，对个人和工程师团队文化来说都是非常重要的一环。我非常看重的的一点是，技术公司的管理人员一定需要从技术第一线提拔而来，这样才能让公司保持工程师团队文化，而且这种文化才具有与生俱来的某种技术特性。

我当时来 FreeWheel 就跟一线管理人员说，如果你的技术能力不能让你在团队里服众的话，那你还能给团队带来什么。在我的定义和 FreeWheel 的文化中，转变为团队领导的人必须要在他的团队里具有最顶尖的技术水平。我们一般会以 10 人左右的团队为一个评价标准，如果他是技术大拿，只要他说了别人就觉得有信心，愿意按照他说的去做，那么他才能成为一个合格的团队领导者。很多硅谷的互联网公司也是这样，并不是按级别的高低来选择最适合的管理者。

我曾在微软和雅虎工作了将近十年，从最早的编程开始做起，到做一线的技术管理，再到管理 100 人、300 人的团队，这种锻炼是一步一步做起来的。十多年里，从一线的管理逐渐转变到管理更大的团队，我也有了更扎实的体会。关于如何建设团队；如何做长期的规划；对于一个团队，以至于一个比较大的团队组织，怎样获得长期且稳定发展；如何在良性竞争中胜出等问题，微软和雅虎都为我提供了很好的学习平台，所以在加入 FreeWheel 之后，可以很自然地将这些理念和思路应用在具体的技术管理场景中。

在雅虎期间，我能感觉到那种硅谷的沸腾的氛围，而且在硅谷不同公司之间的交流也非常频繁。在硅谷，不管是大公司还是小公司，大家就像是在一起创业的大家庭，时间长了就形成了一种工程师文化，说的简单点是自由、平等、开放。这种工程师文化会让每个人都持续保持进取的态度，很少有人抱怨，心态也会更加开放。

都说技术老大的角色决定了一家公司技术团队建设的模式，FreeWheel 联合创始人兼 CTO Diane 在工程师开放文化的构建上起了非常关键的带头作用，我们的开放主要体现为在信息维度的充分共享和在思维维度的创造激发。整个公司发展中，技术层面和商业模式层面的信息，可以在领导层和员工之间做到充分的沟通和共享，使得全员在任务处理上能更好地把握整体方向、理清事情的优先级，做对公司最重要的事情。另外，大家做事情都是本着平等开放的原则，不会因为说话的人不同，就对他提出的问题或者方案有不同的态度，不因人废言，更不因言废人。这样做的目的就是要激发大家的积极性，充分发挥每一位员工的创造力。

追求 Engineering Excellence，是近期 FreeWheel 整个工程师团队的最大变化。在公司整体度过了生存期的挑战并进入到加速生长期时，我们要关注的事情，不再是到处救火，而是要追求卓越， 要打造一个可以在未来几年里，支撑业务发展的优秀技术平台。 在这个新的目标下，FreeWheel 工程师团队也发生了不少变化，包括对 Full Life Cycle Engineer 理念的倡导，对 CI/CD(持续集成 / 持续交付) 等高效开发流程的探索和精进等。

敏捷开发模式跟传统的开发差别之一是对变化的拥抱。传统的开发相对会拒绝变化，即计划制定好之后不希望有任何变化，有变化会对开发流程造成很大的影响。敏捷文化是拥抱变化，当有问题发生的时候需要会主动做调整，当然这对团队的组织和行为方式也带来了很大挑战。这里，FreeWheel 有一些比较好的实践经验可以分享。

第一是团队的组织。FreeWheel 一开始按照敏捷开发的原则将团队组织成 Scrum，在这种管理方式下，所有相关人员（主要是测试人员、开发人员，和在美国的产品团队）会形成一个比较紧密的团队，消除相互间的壁垒。所有人从一开始就会融入到产品的设计、开发、测试里去，通过快速反馈和及时沟通，能最迅速地解决项目过程中各种问题。

第二是团队的管理。敏捷开发与传统模式相比，最显著的特点就是人和流程的关系有很大不同。传统开发中会制定一个固定的流程和周密的计划，人被添在了这个流程和计划中。敏捷开发的变化多、迭代快，如果套用一种管理模式并强加给团队，往往会带来生产力的倒退。所以管理的方式应该是给团队更大的自主性，注重引导而非控制。一个公司往往会有很多个敏捷团队，我们最终是让各个团队用他们的聪明才智解决问题，但同时各个团队之间又可以互通有无、取长补短。有的时候你会是第一个踩坑的人，但这个踩坑的过程是有价值的，得到的经验教训可以跟大家分享。

第三是做事的方式。当把任务拆分的更细时，反馈就能更及时。如果有一大块的东西挡在你的工作流里，会对你的敏捷性造成障碍。所以我们一开始就会对所做的事情进行拆分，把任务拆分得更细，使得任务更容易被排期。同时在技术上实现 CI/CD，对产品持续不断地做测试，并且把它集成到研发流程中。当工程师做了某些改动后，整个系统会立刻产生结果评价，告知你做的是对还是错，然后大家基于这个结果再看如何继续推进。

与此同时，上面提到的“Hire the Best”理念也会对团队建设和管理带来一定挑战。如果团队人员的水平和能力呈现为梯队型，自然而然管理会相对容易；但如果大家都处于较为平均的基线范围内，就会面临更多协调、平衡及取舍方面的工作。最近 FreeWheel 正在尝试 SAFE，即将团队都分成不同的 squad，一个 squad 即为对产品有贡献的垂直的功能性团队，需要挑选并重组在前端、后端、数据库方面具有差异化优势的小组成员。但将优秀的成员都放在一起做一件事很容易有人做的多，有人做的少，有人满意，有人不满意，这就跟项目管理、软技能训练等相关。

通过实行敏捷模式，工程师团队的整体趋势会越来越扁平化，但是扁平化主要还是发生在一个模块内部。比如，目前 FreeWheel 中国的工程师主要被划分为五个分支技术团队——AdServing、Forecasting、Reporting、UI 和 OPS，其中，AdServing 模块内部被大概分成了 6、7 个小型团队；Forecasting 被分成 3 个小型团队。其他四大模块情况也类似。在团队组织上，部分小型团队成员可以直接汇报给一线研发经理，例如，UI（负责核心业务系统的研发与测试）模块的 80 人团队（北京分部）大概有 6 个研发经理，他们各自领导着十人左右的团队。因此，分支技术团队总负责人和普通工程师之间只有一级，向上的沟通和汇报会更加通畅。而且，负责管理的同事有更多的机会直接与小型业务开发团队进行协作，第一手掌握他们真实的想法、他们的困难和反馈意见，以便缩短做决策的时间周期。

对于 Full Life Cycle Engineer，现在业界有两种声音，一种是 Full Stack（全栈）Engineer，指能够掌握前端、能写 Web，能写后端服务器，还能开发 mobile 程序等，要掌握不同的技术。这种声音存在一定的争议。另外一种方向是 Full Life Cycle Engineer。比如写 C++ 的就不需要掌握 web，但要能对使用 C++ 开发软件的整个生命周期熟稔于心：当新的功能要求提交出来时能用 C++ 对它进行设计，写完之后能够用相关的工具测试并将服务进行发布，后续还需要支持服务的运维。举个很简单的例子，测试、运维的环节常常被技术管理者忽略，随之而来的问题便是产品质量不可控、BUG 一堆、发布成功率低、运维人为事故频发。但对 Full Life Cycle Engineer 理念的倡导可以有效减少此类问题的发生。

因此，FreeWheel 非常倡导 Full Life Cycle Engineer，其直接优势在于可以消除上下游间明显的界限。比如一开始设计的时候就会将测试的实施方案、后期发布、运维上的问题一并考虑进去，而不是执行一半之后再去想怎么“填坑”。这是敏捷模式下最为可行的方式，如果整个软件交付过程中还要上下游切换，沟通成本就会很高，整个团队不可能敏捷起来。

研发团队之间的协作非常重要，协作和沟通的效率在很多时候都是解决复杂技术问题时的必备条件。开发过程中，如果我们在上线环节亦或开发测试环境中发现了一个具体的技术问题，不同的研发团队负责人或该领域的资深专家会组成一个临时小团队，不断地调研，分析和研究后认定问题根源并划定应该由哪个团队、哪个工程师具体跟进和解决。解决方案落地且开始执行后，大家还会回过头来进一步验证，确定目前的解决方案是否有其他风险存在。

对 FreeWheel 而言，最大的挑战之一是跨地域、跨时区的沟通与协作。FreeWheel 除了在美国、中国、法国有研发机构以外，在欧、美、亚洲的多个国家也会有自己的办公室。这些国家的团队规模及成熟度较高，但都存在较大的时差。

相比通过电话、电子邮件进行跨时区的交流，我们会尽可能地采用很多其他的方式优化跨时区、跨地域的合作和沟通。比如北京的各模块的研发团队会持续派轮岗人员，去美国等地不同的实验室和不同部门，与产品经理在一起紧密地合作一到三个月。这样做的好处之一就是当产品经理面对更多的客户、分析客户需求的时候能得到研发团队第一手的支持，比如从技术角度看业务设计是否合理、能否实现、实现难度大小等。

另外，美国的产品经理会每个季度飞到北京来与这里的同事工作 1-2 周的时间商议未来 3-4 个月的研发及项目规划。这类协同工作的目的都是尽可能地减少跨时区、跨地域沟通的难度和障碍。如果团队之间没有很好的沟通，做完以后发现有很多问题，但由于一开始没有识别出来，最后就会演化得愈发严重。

人才培养更关注个体，团队建设更关注集体。团队一方面要做事，另一方面要育人，人才是团队的核心资产。在团队中可能只是很微小的一粒存在，你也必须要给所有技术人以存在感和价值感，让他们能看到自己的付出能改变产品、改变公司，甚至改变整个行业的走向。

在 FreeWheel，不论每个同事的职务或工作职责如何，技术管理层都会首先注重帮助所有人在公司找准自己的定位，也会帮助他们分析清楚自己的长处和短板，并有针对性地制定相应的工作计划及提高个人能力和适应职业发展的规划，帮助所有人找到他对公司的价值所在。这样做一方面会让每一位同事在工作上形成满足感，另外一方面也保证了他做出的贡献和体现的价值能被公司所认可，因而能有更好的职业发展机遇。

对工程师来说，发挥价值的地方仍在于与产品的强联系。我们非常提倡让技术人深入到第一线工作中，让大家去直面解答客户的问题。在 FreeWheel，销售和客户服务团队是直接做售前、售后服务的人，每个季度聚集到北京参加 PI Planning（Program Increment Planning），制定下一季的产品计划，从而去打破技术人员、产品经理、销售这一套人员固定模式上的隔阂，让工程师团队能感觉到自己做的东西所发生的变化、对用户所产生的影响，直接参与到用户的意见反馈环节中去。

另外，随着业务的发展和体量的增大，FreeWheel 也正在实行大规模的技术重构工作。当每天的工作中都有可能面临到新的技术挑战时，就能更好地保持团队的进步感。

以 UI 模块团队为例，从 2007 年到目前，前端技术框架经历了多次演变，去年开始 UI 团队 (同时也包括其他团队) 都在推行微服务化 SOA 架构。后端的业务逻辑会通过 Golang 服务封装成一个一个不同粒度的微服务，这样我们整个前端的框架会更多专注在业务交互上，跟核心业务逻辑直接相关的实现都会封装在底层的微服务框架上。但对于像 Go（包括我们前端目前正在使用的 React.js 框架）都是比较新的技术框架，会在技术细节方面面临更多的挑战，很难通过参考别人的经验就能获得有意义或有帮助的答案。所以我们更多是依赖于自己的研发团队，深入地具体分析某一些技术问题产生的原因：为什么在我们这样的产品环境下会发生；能不能做一些实验，尝试找到一些解决办法；论证我们的解决办法，确保不会带来其他的衍生问题；对我们的系统稳定性、可靠性是否造成影响等。

很多的问题都是挑战，而克服挑战、解决问题的过程才能让大家感受到每天的进步以及明天未知的新奇。

FreeWheel 常常说我们的企业文化是 Proudly Unique、Deeply Caring，还有 Purposeful，虽然是几个形容词，但是在日常工作中会遇到很多事情，大家会经常在一起谈解决问题的方法，遇到矛盾的时候又怎么解决，这会让所有人感觉与他人连同在一起，是有意义的存在。

另外，企业的定位和愿景同样会对技术人的价值感形成带来很大的影响。我入职前，跟 FreeWheel 的 Co-CEO 进行了一轮电话面试，谈公司的发展前景时，他用十年前苹果和诺基亚做了类比的例子，并说：“虽然在公司规模上，我们在业界和主要的竞争对手相比非常弱小，但是如果把竞争对手比作诺基亚（那个时候），那我们就应该是苹果。”举这个例子的目的在于说明，即使目前的你尚且弱小，但只要你的产品有非常清晰的、适合市场发展的战略，也一定能够打败当时占领市场 80% 份额的巨无霸。

在这样的目标之下，我们也相信，优秀的工程师会逐渐认知到企业和自身的使命，认知到他在做的这项技术的前景与价值。