你好！

本周作客大咖对话的嘉宾是 Keep CTO 彭跃辉，曾于 2010 年加入豌豆荚，从零开始搭建豌豆荚的应用搜索，打造最全、最准、最快的内容库。2016 年加入 Keep，搭建近 200 人的技术团队，带领团队快速迭代，通过内容、数据和智能打造运动的闭环，Keep 长期稳居健康健美的榜首。今天我们主要与他聊了聊搭建高效团队相关的话题。

极客时间：您能先简单介绍下自己，以及您目前主要负责的工作方向吗？
彭跃辉：我毕业后加入豌豆荚，主要做应用搜索、内容库相关的工作，2016 年 3 月份来到 Keep，当时 Keep 的技术团队大概有 20 多人，现在整个团队有 200 多名技术人员，成功搭建了一个迭代稳定高效的技术团队。目前主要专注于运动领域，包括 Keep APP、智能硬件、线下体验空间等。

极客时间：那在搭建高效的技术团队上，能否分享一下您的经验呢？

彭跃辉：在团队搭建及管理方面，我可以分享一下我们的做法，主要有四点。

第一，引入 OKR，并把它定位成沟通和管理工具，使团队对目标的理解保持一致。我们在确定每个团队的核心目标时，不论向上还是向下，都会进行几轮沟通，确保大家理解一致。核心目标确定后，会从多个维度考虑怎样衡量这个目标，一般会将目标数字化，划分为具体的数据指标，相当于 OKR 中的关键结果。，再根据 OKR 去设定每个季度的 Roadmap，这样做的好处是大家的目标会统一。同时，在执行的过程中，我们会每三个月 Review 一次，并在 Review 的过程中对目标进行调整。

第二，提倡数据驱动，不管是技术优化还是产品功能，甚至是算法，我们都会去设计它的数据指标，像一些比较长期的改动，我们都会设定较多的 AB 测试，通过 AB 测试验证我们的改动对用户是否有效。为了做这件事，我加入 Keep 的第一件事就是搭建数据系统，现在被叫做数据中台，相当于提供了一套可以交互的数据查询系统。除此之外，我们还搭建了 BI，即商业智能分析及调度系统，进一步用好数据。

当然，在打造数据中台期间我们也遇到了很多挑战，其中数据是最核心的一个问题，确保数据准确就花了很多时间。数据不准确有很多方面的原因，有可能是因为对目标的定义不清楚，也有可能是产品经理提的需求不够准确。即使目标是准的，需求也是准的，但在开发的过程中，不同开发人员的技术能力不一样，有时候也会导致数据不准确。再到后面进行数据分析的时候也会出现很多问题，比如每个部门对数据的理解不同，等等。

为此，我们做了一些工具来解决这些问题，比如需求评审时更细致，在开发过程中进行灰度测试、半自动化测试等，以及搭建数仓等基础设施，把公司内各部门对相关数据的定义统一起来，使数据的维护与管理在一个统一的系统中进行。现在，不仅技术、产品、运营、市场等部门的同事在使用跟数据相关的系统，我们也正在跟财务、市场等部门对接，将一些财务相关的数据也打通，从而提高公司整体的运营效率。

第三，工具的使用，我们鼓励团队成员使用工具来提高效率，并给予一定的费用支持。我们现在用的是 Phabricator，这是 Facebook 的一个代码管理和项目管理的工具，通过 Phabricator 我们进行敏捷迭代，基本保持每两周一个迭代的频率，给用户提供一个稳定的版本，除非过年，或者十一期间可能会有延期发版的情况。除了 Phabricator，我们还会使用谷歌的一些套件，如日历、邮箱、共享文档等，我们比较提倡通过在线的方式来评论、协作和交流工作。

第四，做好技术人员的成长路线，主要会从两个方面着手，首先，打造技术人员的专业定级体系，这点很重要。我们会从多个维度去定义一个工程师的级别，很多工程师选择走专业路线，那他得知道自己当前的位置在哪，要到下一个级别还有哪些欠缺等。我们从 2017 年 10 月份开始对技术人的专业定级，给他们提供了一个明确的成长路线，我们也会根据定好的级别来调整他们的薪水、奖金等，逐步打造了一个相对完善的技术职级体系。

我们每年都有两次技术定级的答辩，到高级工程师的级别后，此后每一个小级别的晋升都需要进行答辩。答辩规则是 5 到 7 人评审，两票否决制，一旦有两个人否决，则答辩失败。

其次，组织内部分享和外部交流，我们内部每一个小组，都会有半年到一年的分享计划，也会经常跟一些其他行业的人沟通、交流。我们和谷歌、苹果的合作较多，每年都会挑选优秀的员工去参加 Google IO、WDDC 等大型会议，由公司承担机票、酒店等费用。另外，我们是腾讯投资的公司，所以也会去参加腾讯举办的各种培训。

一般团队的架构都是三角形的，级别越高的人越少，处在三角形底边的人更多，但我们现在正在通过以上提到的这些方法，慢慢让这个三角形的底部变窄，相当于将初级技术能力者的比例减少，增加中层级别甚至高级别的技术专家，将整个团队往精英化方向打造。

极客时间：Keep 现在基本稳定保持两周迭代一次版本，这是一个很大的挑战，能否分享一下你们在这个过程中遇到的困难？你们又是如何解决的呢？

彭跃辉：中间的确是遇到过很多挑战，最初，保持两周迭代的问题是我们的交付内容不能得到保障，从产品到技术再到测试，每个环节都可能出现问题导致最后影响到迭代周期与质量。反思过后，我们明确了整个流程，以及每个职能在各个环节要做的事。在实践中，基于两周迭代一次这个事实，我们将整个迭代分成几个不同的环节，虽然每两周一个迭代，但你可以认为这两周是一个开发、测试的周期，而我们在每个迭代开始前一周，就会开始需求的评审评估，并在当周内将需求确定，然后在迭代开始前就制定好具体的排期表，明确各个职能在不同阶段和不同时间点该交付什么内容。

到第二阶段，业务增长后变得复杂了，团队成员也增多了，很多时候项目需要依赖其他部门，这时就会发现项目对接或项目推进上出现了一些问题。对此，我们为每个小项目设定一位总负责人，他来负责跟其他技术团队对接，他会去推进前端、后端、客户端等整个流程。

另外，我们会在每一个迭代中，都产出一份数据报告及质量报告，数据报告更多是产品功能层面上的数据表现，包括技术改进、优化的数据等。质量报告会显示一些版本信息，比如崩溃率、首页加载时间、某些业务核心指标等，相当于质量部（包含 QA 和运维 SRE）每两周输出一份质量报告。各个职能的成员就可以根据这些数据，有针对性的提升和优化本部门的效率和质量。这样也就形成了一个较为完善的迭代和反馈优化的节奏。

极客时间：在您看来，技术人如果想走上管理路线，该如何打开边界提升自己的管理能力呢？

彭跃辉：我们现在对技术管理者的要求分为三部分，第一部分是技术能力，他需要具备把某功能或某业务实现并实现好的能力，我们会通过质量、效率等维度评估。技术能力是技术管理者最基础的一项能力，除了自身成长外，我们也会提供各种技术学习活动，比如内部分享、外部交流，以及利用更复杂的项目去锻炼中层管理者等。

第二部分是对业务的理解能力，比如，你需要知道这个业务未来的方向，以及你的技术架构如何为这个业务服务，包括在当前阶段，应该做什么事情，不应该做什么事情。我们希望技术 leader 能够发现业务的问题并解决它，从而推进业务进一步发展。我们有很多功能都是由技术 Leader 提出并推进的，包括从提出需求，到落地需求，再到负责相关数据的整个迭代过程。

针对技术管理者的业务理解能力，我们会定期组织大家针对业务中存在的问题进行开放性讨论，让大家畅所欲言，从实践结果来看，这个方法比较有效。另外，针对公司中层管理者以及其前线的管理者，我们会统一组织管理能力培训，包括领导力、沟通、文化、绩效、财务等诸多方面的能力。

第三部分是创新能力，对于创业公司来说，会比较看中技术 leader 的创新能力。我们会鼓励技术 leader 去做一些有挑战的事情，比如我们会把 hackathon 中产生的一些点子，落地到产品中做成某项功能。比如最近要上线的游泳记录硬件，它可以记录游泳的姿势、游泳的距离等，就是在 hackathon 中产生的 idea。

以上三点是我们对技术管理者的要求，如果技术人想走上管理路线的话，可以参考一下，有针对性的做一些学习和锻炼。