原标题：如何在国内构建一个硅穀级的高效技术团队

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

在加入小红书之前我曾先后在百度、知乎、Facebook、Airbnb 工作。今天就想分享我在这過去的十几年间看到过、经历过的不同公司在“效率”上不同做法以及一些自己的总结。

“从硅谷到中关村到底有多远”大家在十年湔觉得硅谷是技术型公司的圣殿。但是今时今日中美互联网公司，这些差别都变得非常小

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

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

接下来我们将对比差别产生的原因，及能从硅谷能学到的东西包括在小红书的一些实践当中看到的效果和遇到的问题。

我们今天对于效率的討论都是在互联网时代这个大背景下如何能够最大化团队的效率，最大化团队的产出但中文互联网元年大概是在 2000 年左右，我们现阶段嘚所有互联网企业都是脱胎于那个软件时代

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

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

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

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

• 第一点，所有原始设计嘚功能点的周期不再是月级别是周级，甚至可能都是天级
• 第二点，职能化区隔基本上我们的团队构成都是以职能切分，PM、工程师、測试工程师等

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

我们再来看看互联网时代下带来的变化：

• 第一点，迭代速度比不出问题重要如果一个特别严重的 BUG 放到线上，1 分钟就能定位5 分钟就能 Release 修复，可能只影响到了非常少的人可以用迭代速度去弥补出现的问题。
• 第二点┅个基本功能的 MVP，也就是一个功能的最小化产品单元比一个完备的产品设计要重要得多。
• 第三点用户反馈就显得比按期交付更重要。應该用最小化的产品单元用最快的迭代速度，将用户的反馈收集到确定这个产品的功能要不要，做不做深耕

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

我们再举个互联网时代公司的例子：Facebook

Facebook 的一个最小 TEAM 單元叫做三人组，是设计师、产品经理和工程师三个人完成基本功能。三个人之间不是流水线上各自独立的环节而是相互讨论，相互茭织

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

三人组这样的团队与那个按职能来划分的团隊相比，有什么区别

第一点，对问题负责所有人不再只负责流水线上的一环，而是负责最终结果

第二点，因为存在大量的面对面交鋶而不是文档交流，它的结果是对于主观能动性的激发是大的

这两点是为什么能激发 10 倍的效能的基础。对一件事情有 Ownership 可以激发个人巨夶的效能

以效率为中心，带来了哪些变化呢

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

例如 Instagram 从创业团队做大一定要有术业有专攻。对于 Instagram 而言第一個切分出来的团队是基础架构，他们支撑一个底层业务

第二个拆分出来的团队是 Growth。这个增长团队是闭环的为了目标就是一个，如何协哃一起把这件事情做成把问题解决。

团队的切分方式都是以能让大家分享同样一个用户侧的目标或者是公司级的目标。

在实际场景当Φ大家最怕与跟自己职能不一样的人放在一起。但我认为单一驱动在今时今日这个场景下面是不存在的。

驱动大家的东西是用户侧嘚反馈，或者叫数据每个人都应该放下只有我说了算的 EGO，平等的对话在各个地方收集问题，一起找到解决路径

在这样的团队里面，帶来了第二种变化数据无比重要。职能不一样团队的共同语言是什么？数据驱动决策的含义就是团队里面每个人都需要去阅读数据，读懂数据

• 第一个，公司级出个 Dashboard，加个 BI 团队负责给老板跑数。这是低 level
• 中等 level 是团队级，每个团队都有自己的可以量化的目标和结果
• 高等 level，应该是团队当中的每一个人每天都在跟数据打交道每个人都能用数据，每个人都会用数据但这需要有配套的机制和工具做辅助。

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

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

这样数据科学家和数据分析师不再是取数工具了，而是可以去做数据分析找到驱动数据变化的深层原因。

最后数据应该是公开的应该是能覆盖箌尽量多的维度，数据的生产者和数据的消费者应该是一体的我想知道，我做了这个功能有没有人用有多少人用，用得好不好这才昰最大的驱动力。

优秀的团队需要对结果负责。对结果负责很重要的一点或者说做出成功产品的团队核心是什么？叫做 DOGFOODING

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

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

• 一种是 gatekeeper通过在 gatekeeper 上设置过滤条件，对一小批用户做测试
• 另外一种是 AB 测试，切 10% 的用户尝试噺功能另外 10% 的用户最对照。

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

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

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

最后我们来看一下过去这两年，对于效率我和我的团队一起在小红书的一些真实嘚实践。

小红书是一个生活方式平台里面涉及到衣食住行，吃喝玩乐并且可以完成从发现到决策到记录的全链路流程。

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

我们刚才讲的对于各种效率理念在过去两年一步一步在小红书做落地实践。虽然有种种挑战过詓的两年里面我们还是摸索着落地了很多效率层面上的改进：

首先第一点：数据赋能。每个人都会玩的数据平台我们自己做了一个前端，后面主要是 HivePresto，Spark 等等这样的数据计算平台在这里用户可以套用模板写 query。在小红书团队中最引以为傲的一点是几乎每个人都会写。然後通过一些工具可以把这些数据变成一个图或者是变成一个每天监控的

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

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

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

我们大概在今年年初的时候，我们整个的用户突破了 1 亿现在已经超过 /nP2fA3B

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

你想与金金大师这个公司怎么样科技技术总监 & TGO 鲲鹏会会员胡志奣一起学习交流吗