如何在国内构建一个硅谷级的高效技术团队？

六安热线 · 发表于 2018-11-21 16:40:08

作者 | 姚旭编辑 | 小智本文将通过对比传统国内互联网公司和 Facebook 等硅谷互联网公司的团队构成和项目流程，结合其中对比的利弊，以及融合两种风格在小红书落地的实战经验，总结一条，以数据驱动和 Ownership 为核心的高效团队组建和协作的方法论，作为增长型公司如何在“效率”上超越大公司的最核心的竞争力。本文整理自 QCon 2018 上海站上的演讲。

从硅谷到中关村到底有什么差别？以 Data Driven+Ownership 组建高效团队！
' ?! t/ _3 t/ @

效率差距在加入小红书之前，我曾先后在百度、知乎、Facebook、Airbnb 工作。今天就想分享我在这过去的十几年间看到过、经历过的不同公司在“效率”上不同做法，以及一些自己的总结。
“从硅谷到中关村到底有多远？”大家在十年前觉得硅谷是技术型公司的圣殿。但是，今时今日中美互联网公司，这些差别都变得非常小。

2018 年初 Mary Meeker 的年度互联网报告里面，Top 20 市值 / 估值的互联网公司中国占了一半，但从实际角度，还是在一些领域内差距明显。以 Facebook 和阿里巴巴为例。他们两个的市值曾经非常接近。但平均每个员工创造的收入，Facebook 大概是阿里巴巴的 3 倍。这个数据代表了一个公司的效率。

站在今天，中美互联网企业最明显的差距就是团队效率。

接下来，我们将对比差别产生的原因，及能从硅谷能学到的东西，包括在小红书的一些实践当中看到的效果和遇到的问题。
互联网时代的软件工程我们今天对于效率的讨论，都是在互联网时代这个大背景下如何能够最大化团队的效率，最大化团队的产出。但中文互联网元年大概是在 2000 年左右，我们现阶段的所有互联网企业都是脱胎于那个软件时代。

软件时代和互联网时代有什么区别？软件时代 release 周期大概是半年到一年，背后的逻辑就八个字：质量第一，按期交付。

我们来讲讲其中的巨无霸：微软。

在中国互联网企业里，大家沿用了微软的开发流程。PM 中心制，以交付文档作为各个阶段的结果产出。这是一个对于整个软件开发而言好的流程。

但到了互联网时代，这样软件工程有什么问题？

第一点，所有原始设计的功能点的周期不再是月级别，是周级，甚至可能都是天级。
7 P0 X. c: p* Y& C' O8 ]
第二点，职能化区隔。基本上我们的团队构成都是以职能切分，PM、工程师、测试工程师等。
2 M% d6 f* i. z( @* Z2 q0 |- Y; Y

在复杂的互联网场景中，我们就会出现 PM 的需求和排期，会分别细化到客户端团队，到服务器后端等。Team 越来越大，时间却越来越少。流程能带来安全和质量，但流程不能带来效率。
我们再来看看互联网时代下带来的变化：

第一点，迭代速度比不出问题重要。如果一个特别严重的 BUG 放到线上，1 分钟就能定位，5 分钟就能 Release 修复，可能只影响到了非常少的人，可以用迭代速度去弥补出现的问题。* |5 o/ L4 Z7 E7 g" m- a G
第二点，一个基本功能的 MVP，也就是一个功能的最小化产品单元，比一个完备的产品设计要重要得多。
6 b& g: a; g6 \% f. ]! ~) D5 H2 U9 u
第三点，用户反馈就显得比按期交付更重要。应该用最小化的产品单元，用最快的迭代速度，将用户的反馈收集到，确定这个产品的功能要不要，做不做深耕。 M( T0 M; Z7 D/ D9 N

在互联网时代下，对比传统软件时代，我们的最终生产效率能差多少？10 倍肯定是有的。效率就是第一竞争力。

我们再举个互联网时代公司的例子：Facebook。
Facebook 的一个最小 TEAM 单元叫做三人组，是设计师、产品经理和工程师，三个人完成基本功能。三个人之间不是流水线上各自独立的环节，而是相互讨论，相互交织。

产品经理，他不再只是 Product Manager，而是 Problem Manager，让大家能看到问题的全貌，一起来探索解决的方案。

三人组这样的团队，与那个按职能来划分的团队相比，有什么区别？
第一点，对问题负责，所有人不再只负责流水线上的一环，而是负责最终结果。
第二点，因为存在大量的面对面交流，而不是文档交流，它的结果是对于主观能动性的激发是大的。
这两点是为什么能激发 10 倍的效能的基础。对一件事情有 Ownership 可以激发个人巨大的效能。
以效率为中心，带来了哪些变化呢？
变化 1：团队

我们先来看看团队的变化。

例如 Instagram 从创业团队做大，一定要有术业有专攻。对于 Instagram 而言，第一个切分出来的团队是基础架构，他们支撑一个底层业务。
第二个拆分出来的团队是 Growth。这个增长团队是闭环的，为了目标就是一个，如何协同一起把这件事情做成，把问题解决。
之后，还会切分出 Engagment 团队，以及 monetization 团队。
团队的切分方式都是以能让大家分享同样一个用户侧的目标，或者是公司级的目标。
在实际场景当中，大家最怕与跟自己职能不一样的人放在一起。但我认为，单一驱动在今时今日这个场景下面是不存在的。
驱动大家的东西，是用户侧的反馈，或者叫数据。每个人都应该放下只有我说了算的 EGO，平等的对话，在各个地方收集问题，一起找到解决路径。
在这样的团队里面，带来了第二种变化，数据无比重要。职能不一样，团队的共同语言是什么？数据驱动决策的含义，就是团队里面每个人都需要去阅读数据，读懂数据。
数据驱动分几级：

第一个，公司级。出个 Dashboard，加个 BI 团队，负责给老板跑数。这是低 level。
8 K8 G+ y2 m1 g- @& T" N
中等 level 是团队级，每个团队都有自己的可以量化的目标和结果。. O5 N0 E9 K @. I. [# m* u
高等 level，应该是团队当中的每一个人每天都在跟数据打交道，每个人都能用数据，每个人都会用数据。但这需要有配套的机制和工具做辅助。 W# }! Y0 ^% u& G6 U& c$ z

在 Facebook 内部，五年前有三大工具：Scuba，Hive，Ods。ODS 传统 KV 储存，主要是一些计数器。HIVE 就是数据仓库，可以跑很大的数据量，缺点就是反应慢。SCUBA 在 Facebook 内部是人大家日常使用最多和最有帮助的工具，可以实时地做多维聚合。

实际应用工具当中的一个转变，对人的影响是非常大的，工程师关心的不单是 CPU、MEMORY，关心的是全链路业务上面的用户反馈，要有工具能看到结果长什么样子。产品经理也要有能力自己取数，要有 data sense。

这样，数据科学家和数据分析师不再是取数工具了，而是可以去做数据分析，找到驱动数据变化的深层原因。
最后数据应该是公开的，应该是能覆盖到尽量多的维度，数据的生产者和数据的消费者应该是一体的。我想知道，我做了这个功能有没有人用，有多少人用，用得好不好，这才是最大的驱动力。
变化 3：职责优秀的团队，需要对结果负责。对结果负责很重要的一点，或者说做出成功产品的团队核心是什么？叫做 DOGFOODING。

DOGFOODING 是什么意思呢？就是自己用自己的功能，自己吃自己的狗粮，或者狗屎。自己做出来的功能，首先自己要先用起来。

在 Facebook 有几种简单的工具去支持大家快速做用户侧尝试，哪怕是只给自己使用尝鲜：

一种是 gatekeeper。通过在 gatekeeper 上设置过滤条件，对一小批用户做测试。
! T1 V0 D" {& E; s8 Q+ w( t+ A
另外一种是 AB 测试，切 10% 的用户尝试新功能，另外 10% 的用户最对照。3 e4 i) {! K" c q+ K( a

那工具为什么可以让大家变成对结果负责呢？原因叫做赋能。因为有能力，所以有担当。

除了靠各种 CI，Canary 工具以外， gatekeeper 和 AB testing 也可以让你小流量去实验，实验个 5000 用户，觉得没问题，再放大，用这样的工具去辅助这样的权力。

总结来说，在互联网时代，为什么 Data driven 和 ownership 可以提供 10 倍的效能差别？因为在大目标对齐的情况下，各个小团队之间可以组成一个分布式的决策机制，大家可以跨职能的团队协作，去中心化进行决策，做到面对不确定性时的敏捷。

小红书的实践
最后我们来看一下过去这两年，对于效率，我和我的团队一起在小红书的一些真实的实践。
小红书是一个生活方式平台，里面涉及到衣食住行，吃喝玩乐，并且可以完成从发现到决策到记录的全链路流程。

我们是一个面向用户、有丰富数据的平台，这是我们产品上的天生优势。我们一天的用户阅读量有数十亿次，这种流量规模情况下，我们可以做非常多的 AB Testing，用 1% 的流量就可以做非常多的事情。

我们刚才讲的对于各种效率理念，在过去两年一步一步在小红书做落地实践。虽然有种种挑战，过去的两年里面我们还是摸索着落地了很多效率层面上的改进：
首先第一点：数据赋能。每个人都会玩的数据平台。我们自己做了一个前端，后面主要是 Hive，Presto，Spark 等等这样的数据计算平台。在这里用户可以套用模板写 query。在小红书团队中最引以为傲的一点是，几乎每个人都会写。然后通过一些工具可以把这些数据变成一个图，或者是变成一个每天监控的 dashboard，还可以变成 high level 的报警。

第二点，工程赋能。工程师有能力决定自己功能什么时候上，要什么时候上，或者要不要上。我们用了 Phabricator 做 Code Review，集成了后面 Jenkins 做 CI。所以工程师在这里边每天会看到说我现在有多少个 Diff 等着我去 Review，以及我的 diff 在被 review 的状态是什么样子。当有一个 reviewer 点击了 accept，就代表可以上线了，就触发了我们最终的 deploy 流程，就上到线上，这是对于工程权力的下放。

第三点，实验赋能。我们现在线上 AB testing 平台一天有 300+ 个实验，也就是说我们每天在尝试的新功能有 300 多个。AB testing 就是应该犯错的，AB testing 就应该是 10% 的成功率才对，或者更低，代表实验的效率更高和跑得更快。

我们刚才讨论这些关于效率的话题，在小红书团队里面都有所实践并且一直在进步。我能看到工程师、产品经理、数据分析师在团队里面效能的变化，效率成倍的激变。

我们大概在今年年初的时候，我们整个的用户突破了 1 亿，现在已经超过 1.5 亿。小红书所有核心指标都是一年 4 倍到 5 倍地指数级增长。

我们就是一个从十来个人的团队到 100 多人的团队，QPS 从百到万到十万，去撑起了这么一个每年 5 倍左右的核心 metric 的变化。

那么从硅谷到中关村到底有多远呢？

在小红书，我们其实就是 为一线团队做两件事情，一个叫做放权，一个叫做赋能。
放权的意思是通过 Data Driven 的方式给予决策权的分布式下放；赋能的意思是通过工具，无论是测试工具也好，CI 也好，实验平台也好等等这样的工具能让团队每个人有 ownership。最后，欢迎大家加入小红书团队，来一家高增长的公司高效率地做事情。
本文彩蛋硅谷一直以其“不断创新、鼓励冒险、包容失败、崇尚竞争、平等开放”的文化闻名于世。许多公司从一个灵感迸发的火苗，在这里长成参天大树。究竟硅谷公司里有哪些令人着迷的工程师文化，可以让人管中窥豹略见一斑呢？请在 InfoQ 后台回复关键词：硅谷，获取一篇以 Facebook 为例的项目开发流程和工程师的绩效管理机制文章。
作者介绍

姚旭，小红书社区技术负责人，端到端地负责小红书的社区功能，包括大前端，搜索、推荐、基础架构和相关的机器学习系统。加入小红书前，曾在 Airbnb、Facebook、知乎和百度等公司担任首席架构师和主任工程师职位。

可能是讲分布式系统最到位的一篇文章

高效的技术团队需要技术管理两手抓，你找到正确的上升途径了？关注新一届的 QCon 大会，100+ 技术大咖给你解答启发。
QCon 北京 2019 现已全新起航，除了一些常规的专题设置外，新增了用户增长、智慧零售等当下热点话题，在技术深度和广度上不断延展。目前大会 7 折报名中，立减 2640 元。识别二维码了解 QCon 十周年的精心策划。

议题讲师持续邀约中，如果你有好的话题并乐于与他人分享，欢迎点击「阅读原文」提交议题。

来源网址：http://www.yidianzixun.com/home?page=article&id=0KdET5Wf

如何在国内构建一个硅谷级的高效技术团队？

相关帖子

客服电话