技术领导力实战笔记_203_大咖对话_|_彭跃辉：保持高效迭代的团队是如何炼成的
你好，本周做客大咖对话的嘉宾是keep CTO彭月辉曾于二零一零年加入豌豆荚，从零开始搭建豌豆荚的应用搜索，打造最全、最准、最快的内容库。
二零一六年加入keep,搭建近两百人的技术团队，带领团队快速迭代，通过内容数据和智能打造运动的闭环。
Keep长期稳居健康健美的榜首。
今天我们主要与他聊了聊搭建高校团队相关的话题。
即刻时间问，您能先简单介绍一下自己以及您目前主要负责的工作方向吗？朋友回答我毕业后加入豌豆荚，主要做应用搜索内容库相关的工作。
二零一六年三月份来到keep,当时keep的技术团队大概有二十多人。
现在整个团队有两百多名技术人员成功搭建了一个迭代稳定、高效的技术团队。
目前主要专注于运动领域，包括keep APP、智能硬件、线下体验空间等。
即刻时间问，那在搭建高效的技术团队上，能否分享一下您的经验呢？朋友回答，在团队搭建及管理方面，我可以分享一下。
我们的做法主要有四点，第一，引入OKR,并把它定位成沟通和管理工具，使团队对目标的理解保持一致。
我们在确定每个团队的核心目标的时候呢，不论向上还是向下，都会进行几轮沟通，确保大家理解一致。
核心目标确定以后，会从多个维度考虑，怎样衡量这个目标一般会将目标数字化划分为具体的数据指标，相当于OKR中的关键结果。
再根据OKR去设定每个季度的roadmap.这样做的好处是大家的目标会统一。
同时在执行的过程当中呢，我们会每三个月review一次，并在review的过程中对目标进行调整。
第二，提倡数据驱动，不管是技术优化还是产品功能，甚至是算法，我们都会去设计它的数据指标。
像一些比较长期的改动，我们都会设定较多的AB测试通过AB测试，验证我们的改动，对用户是否有效。
为了做这件事儿，我加入keep的第一件事情就是搭建数据系统。
现在被叫做数据中台，相当于提供了一套可以交互的数据查询系统。
除此之外，我们还搭建了BI及商业智能分析及调度系统，进一步用好数据。
当然，在打造数据中台期间，我们也遇到了很多的挑战。
其中数据是最核心的一个问题，确保数据准确就花了很多时间。
数据不准确，有很多方面的原因，有可能是因为对目标的定义不清楚，也有可能是产品经理提的需求不够准确，即使目标是准的，需求也是准的。
但在开发的过程当中，不同开发人员的技术能力是不一样的，有时候也会导致数据不准确。
再到后面进行数据分析的时候呢，也会出现很多问题。
比如每个部门对数据的理解不同等等等等。
为此，我们做了一些工具来解决这些问题。
比如，需求评审时更细致，在开发过程中进行灰度测试、半自动化测试等，以及搭建数仓等基础设施，把公司内各部门对相关数据的定义统一起来，使数据的维护与管理在一个统一的系统中进行。
现在不仅技术、产品运营、市场等部门的同事在使用跟数据相关的系统。
我们也正在跟财务市场等部门对接，将一些财务相关的数据也打通，从而提高公司整体的运营效率。
第三，工具的使用，我们鼓励团队成员使用工具来提高效率，并给予一定的费用支持。
我们现在用的是范ber kitter,就是facebook的一个代码管理和项目管理的工具。
通过famber kitter,我们进行敏捷迭代，基保持每两周一个迭代的频率，给用户提供一个稳定的版本，除非过年或者十一期间可能会有延迟发版的情况。
除了fmber katter,我们还会使用谷歌的一些套件。
比如说像日历、邮箱、共享文档等，我们比较提倡通过在线的方式来评论、协作和交流工作。
第四，做好技术人员的成长路线。
第要会从两个方面着手，首先打造技术人员的专业定级体系，这点很重要。
我们会从多个维度去定义一个工程师的级别。
很多工程师选择走专业路线，那他得知道自己当前的位置在哪，要到下一个级别，还有哪些欠缺等。
我们从二零一七年十月份开始，对技术人员的专业定级给他们提供一个明确的成长路线。
我们也会根据定好的级别来调整他们的薪水、奖金等，逐步打造了一个相对完善的技术职级体系。
我们每年都有两次技术定级的答辩。
到高级工程师的级别之后呢，此后每一个小级别的晋升都需要进行答辩。
答辩规则是五到七人评审两票否决制，一旦有两个人否决，则答辩失败。
其次，组织内部分享和外部交流。
其们内部每一个小组都会有半年到一年的分享计划，也会经常跟一些其他行业的人沟通交流。
我们和谷歌、苹果的合作比较多，每年都会挑选优秀的员工去参加google、 IOWDDC等大型会议，有公司承担机票、酒店等费用。
另外我们是腾讯投资的公司，所以也会去参加腾讯举办的各种培训。
一般团队的架构都是三角形的，级别越高的人越少，处在三角形底边的人更多。
但我们现在正在通过以上提到的这些方法，慢慢让这个三角形的底部变窄，相当于将初级技术能力者的比例减少，增加中层级别甚至高级别的技术专家将整个团队往精英化方向打造及刻时间问keep现在基本稳定，保持两周迭代一次版本，这是一个很大的挑战。
能否分享一下你们在这个过程当中遇到的困难，你们又是如何解决的呢？朋友回答，中间的确是遇到过很多的挑战。
最初呢保持两周迭代的问题是，我们的交付内容不能得到保障。
从产品到技术再到测试，每个环节都可能出现问题，导致最后影响到迭代周期与质量。
反思过后呢，我们明确了整个流程以及每个职能在各个环节要做的事儿。
在实践中基于两周迭代一次。
这个事实我们将整个迭代分成了几个不同的环节。
虽然每两周一个迭代，但是你可以认为这两周是一个开发测试的周期。
而我们在每个迭代开始的前一周就会开始需求的评审评估，并在当周内将需求确定。
然后在迭代开始前就制定好具体的排期表，明确各个职能在不同阶段和不同时间点，该交付什么内容。
到第二阶段业务增长后变得更加复杂了，团队成员也增加了。
很多时候项目需要依赖其他部门，这个时候就会发现项目对接或者项目推进上出现了一些问题。
对此，我们为每个小项目设定一位总负责人，他来负责跟其他技术团队对接，他会去推进前端后端客户端等整个流程。
另外我们会在每一个迭代当中呢，都产出一份数据报告及质量报告。
数据报告更多是产品功能层面上的数据表现，包括技术改进、优化的数据等。
质量报告会显示，一些版本信息，比如崩溃率、首页加载时间、某些业务核心指标等，相当于质量部包含QA和运维。
S二二一每两周输出一份质量报告，各个职能的成员都可以根据这些数据有针对性的提升和优化，本部门的效率和质量同样也就形成了一个较为完善的迭代和反馈优化的节奏。
几个时间问，在您看来，技术人如果想走上管理路线，该如何打开边界提升自己的管理能力呢？朋友回答，我们现在对技术管理者的要求分为三个部分。
第一部分是技术能力，它需要具备把某功能或者是某个业务实现并实现好的能力。
我们会通过质量、效率等维度评估技术能力是技术管理者最基础的一项能力。
除了自身成长之外，我们也会提供各种技术学习活动，比如内部分享外部交流，以及利用更复杂的项目去锻炼中层管理者。
第二部分是对业务的理解能力。
比如你需要知道这个业务未来的方向，以及你的技术架构，如何为这个业务服务。
包括在当前阶段应该做什么事儿，不应该做什么事儿。
我们希望技术leader能够发现业务的问题并解决它，从而推进业务进一步发展。
我们有很多功能都是由技术leader提出并推进的。
包括从提出需求到落地需求，再到负责相关数据的整个迭代过程。
针对技术管理者的业务理解能力，我们会定期组织大家针对业务中存在的问题进行开放性讨论，让大家畅所欲言。
从实践结果来看呢，这个方法比较有效。
另外，针对公司中层管理者以及其前线的管理者，我们会统一组织管理能力培训，包括领导力、沟通、文化绩效、财务等诸多方面的能力。
第三部分呢就是创新能力。
对于创业公司来说，会比较看重技术leader的创新能力。
我们会鼓励技术leader去做一些有挑战的事情。
比如我们会把克森中产生的一些点子落地到产品中，做成某项功能。
比如最近要上线的游泳记录硬件，它可以记录游泳的姿势、游泳的距离等等，这就是在格森中产生的hiidea.以上三点是我们对技术管理者的要求。
如果技术人想要走上管理路线的话呢，可以参考一下，有针对性的做一些学习和锻炼。