十年硅谷技术管理经验总结的 6 条技术工程原则

一位常年征战于硅谷技术管理前线的技术工程文化践行者认为竞争的核心在于“效率”、“质量”和“人才”。本文将分享他用十年的经验总结的 6 条技术工程原则，并详细解说技术工程文化在团队中实践落地的案例与方法。

先跟大家说说我对科技创新的看法。在我读书那会儿，觉得创新、创业都是学霸们做的事情，毕竟有多少人会写 PageRank 呢？

现在，随着一些代码的开源，随着很多开发工具的深入人心，创新的门槛降低了，这让更多在产品、设计方面有天赋的同学可以更好地加入到其中，这是一件好事。

过去的技术产品创新靠的是技术的壁垒，现在我们更强调的是走心，产品要抓住客户的心理。

再说到“平台”。我有时候在想，像亚马逊的云计算平台 AWS、以及安卓等，如果没有它们的话，现在也许一半的初创公司都不会存在了。

因为有了平台的出现，创新的资本要求也降低了，资金可以重点用在用户增长方面，而不是更多地花在基础建设和硬件上。

我们且不去讨论这是不是走偏了，是不是行业过热的表现，我觉得我们作为这一代的科技人，无论你是来自创新公司，还是身在已经进入成熟发展阶段的大公司，都要认清现在的变化，适应现在的变化，理解竞争的机制，寻找对策。

毫不夸张地说，现在的科技界感觉像到了春秋战国时期一样，百家争鸣。如果有人问你下一代的核心科技是什么？答案众说纷纭。

有人说是自动化的再次爆发，无人机、无人车，连机器人项目都已经开始做成平台了。

也有人觉得是人工智能，机器学习、深度学习已经不仅仅是局限在想战胜人脑，而是想要彻底颠覆人类学习新东西时所采取的方法。

还有人说是共享经济，现在包括衣食住行在内的我们生活中的很多活动都在实时化、个性化。

当然也有人相信是物联网，在不久的将来，如果手机丢了，我们估计就是寸步难行、无家可归。

因为没有手机你的汽车就不能发动、你就打不到车，就算走回了家，估计没有了手机你连房门都打不开。

在这样一个科技的盛世中，到底是小公司更容易立足了，还是大公司更有优势？

如果我们回过头来看过去的 30-40 年，从硬件到软件、从信息到社交的网站，历史似乎告诉我们是大公司的优势更大。

因为在每个时期，最后只有那么一家或者几家公司可以代表这个时代。

国内一位有名的投资者曾经说过，新科技带来的生产力的提高会逐渐地转化成由资本支撑的竞争优势，但当资本的投入到了趋于饱和的时候，规模化是我们人类社会在下一步科技出现前的一种等待。

尽管现在的科技领域非常多，但是资本介入、规模化每天都在发生。

从另一个方面我们也看到，相对于企业软件来讲，我们现在做面向个人消费者的产品，研发周期在缩短，智能手机的普及对产品的更新迭代提出了更高的要求。

在这样的环境中，大公司还有没有优势可以继续保持这样的速度？不管是所谓的大公司，还是初创企业，面临的最大挑战都是人才的问题。

十年前学软件的同学可能都在学 Java，而现在因为领域多了，人才开始比较分散。现在好的研发能得到的机会太多了，而且每一个选择的风险成本正在降低。

当然，不管科技怎么发展、时代怎么变革，作为一个公司、一个商业主体，有一些东西是不会变的。

那就是：我们永远要做用户需要的产品。降低成本、提升效率是公司竞争永恒的主题，高效且不失质量是一个产品、一个公司的立足之本。

过去 10 年，我有幸在硅谷的三家公司效力，我先去了如日中天的业界新贵 Google，后来去了一个大家认为躺着都能赢的初创企业 Twitter，现在在 Lyft。

在外界看来我们 Lyft 的竞争压力非常大，但是在我们内部有一种打不死的小强精神。

这三个公司属于完全不同的产业，不同的规模，也有着完全不同的竞争压力。然而从研发团队管理的角度来看，我觉得他们有很多东西是共通的。

今天，我将与大家分享 6 条技术工程原则，这 6 条原则是我作为一个研发工程师和技术主管在这么多年的工作中总结下来的一些经验，希望对大家有所启发和帮助：

• 研发责任制
• 数据驱动
• 迭代式发展
• 组合型发展
• 客户为先
• 统一性

当然这 6 条原则都是从研发角度出发的，不能代表商业竞争的全部。但作为科技公司，研发至关重要。我们推广技术工程原则要达到的目标是：一提高效率、二保证质量、三培养人才。

接下来提到的不少技术工程原则，都是耳熟能详的。所以在接下来的分享中我尽量多举一些例子供大家参考。

原则1：研发责任制

研发责任制是要让工程师能够在“做什么产品”、“怎么做产品”等问题上有更多的发言权。

在谷歌获得了巨大的成功之后，美国硅谷以研发工程师为主导的科技企业的企业文化也随之悄然流行。

很多人认为只有让研发工程师做自己有兴趣的产品，才能最大地激发他们的潜能。

这条原则最好的实践案例可能是谷歌当年的“20% Project”：每个工程师可以在每星期花一天的时间做与自己本职工作完成无关的东西，可以是一些原始的项目，也可以是一些看似无稽荒谬的点子（谷歌早期的很多产品都来自于这些点子）。

谷歌这么做是对研发团队以及工程师的无限信任，虽然很多年之后由于公司规模的扩大他们最终放弃了这个政策。

我们在评估工程师业绩的时候，要和他们所负责产品的商业价值做直接的挂钩，通过用户得到的价值、利益来体现工程师的贡献。

而对于所做产品不是面向终端用户的研发团队来说，我们也可以找到内部的客户。

总之，我们要把“客户的需求被满足”这一指标度量化，来客观地给研发团队打分。

我们希望研发团队有足够的自主权，尤其是在产品开发的初期。他们要不受其他职能部门的限制，敢于做一些其他的事情，不管是不是技术，都需要他们勇于探索。

他们甚至可以在不影响商业指标的情况下做技术与非技术的决定，提高团队效率，比如可以由研发领头来进行 Beta 测试等。

我们希望通过培养全栈式研发团队，降低跨部门合作的壁垒。其他的职能部门更多的是对研发部门起到辅助的作用，以此减少每个团队对其他团队的依赖。

践行这条原则时需要注意：

任何技术工程的原则都不是一个数学公式，不能直接套用，我们在实践过程中要注意不能矫枉过正。

比如上文中提到的全栈，全栈不能过度，如果过度，全栈会产生对技术的不统一。

盲目追求全栈，把所有做基础架构的人都分配到全栈中去，对基础架构的投入就会不足。

再来说说“研发至上”。研发至上是从谷歌开始推行的，本意是让工程师可以有足够的自主权决定做什么，结果却会造成一些过度追求工程完美的现象出现。

有些产品可能从工程的角度来看非常好，但是市场切入点不够，或者由于产品太前卫没办法找到匹配的用户和需求，无法流通于市场实现其价值。

我们不妨拿“Google Wave”这个产品举例，这个产品当时的目的是想改变电子邮件的呈现方式。

大家熟知的电子邮件是：我给你发一个邮件，之后我还想修改，可我并不能在你收到的那封邮件上直接进行修改，而是需要另外传送一封修改过的邮件。

有的同学喜欢逐字逐行回复，这样再经转发，后来被加进来的同学就不能实时看到修改的痕迹，很难得知和参与之前的讨论。

Google Wave 就是想把电子邮件通过像网络文档的方式来处理，把整个电子邮件链发展的过程呈现在眼前。

我个人非常喜欢，这是一个非常好的产品，很多功能是工程师想出来的 idea，但是当时并没有足够的市场，以至于这个产品最终甚至于没有发布。

原则2：数据驱动

首先，数据可以帮助确定优先级。对每个公司而言，产品、项目优先级的确定都非常重要，尤其是初创公司更要学会关注。

用数据去决定优先级，而不是靠专家。无论你是做市场调查、做 Beta 测试，还是对之前的产品做一些研究，都要用数据说话。

这些数据除了用户对产品使用的指标之外，还要考虑人力成本、要计算人均产出。要考虑团队人数和角色构成，除了技术、产品、运营、设计等以外还有没有其他的角色。

作为研发团队要做到数据驱动，在讨论设计的时候，就要确定数据采集的要求。数据的采集和分析是有滞后性的。

因此在产品发布之前，我们希望说清楚成功的指标是什么？怎么去衡量？这里建议大家用一些比较有独立性的指标去衡量你的产品是否成功。

什么叫有独立性的指标？因为有一些很好的指标都不具有独立性，这里跟大家举一个不能算反例的“反例”。

例如 Lyft 每次推出司机功能的时候，我们会考虑平均司机驾驶的时间，这不是一个有完全独立性的指标。

我遇到过一个司机，在旧金山一个小时之内只要开 50 分钟的车，就可以满足我们对司机奖励的机制，最后 10 分钟，他不用真的去开车，也不用去接单，只需要把 APP 打开。

如果我们只计算平均驾驶时间的话，会发现这样的司机多了 20% 的驾驶时间，但这并不代表他们对产品的粘度真的增加了。这就没有换来我们真正想要测量到的东西。

再有一点，不管这个产品或架构有多复杂，很多时候都可以用最简单、最简洁的指标去测量。

这里的案例我们说说谷歌的搜索，这么多年来，每次在讲到搜索质量的时候，谷歌都是沿用一个非常简单的方法，就是收集谷歌的搜索结果和其他搜索引擎搜索到的结果让用户进行盲测、打分。

我们当年每个季度末开大会，Google 的两位创始人 Larry Page 和 Sergey Brin 上台的时候，就能以非常简单和清晰的方式对过去的一个季度打分，然后让所有人都知道接下来的一段时间的目标在哪里。

践行这条原则时需要注意的方面：

充分发挥数据的作用需要海量的数据样本，或者即便你有海量的数据，也有可能存在着不确定的因素。

所以我们建议研发团队不能迷信数据，该做决定的时候要勇于做决定。

还有一点，在社交网站搭建的过程中，有一些功能在刚推出的时候，只有一部分的用户在用，还没有起到网络的效应，这个效应有一定的滞后性，这个时候数据并不一定能完全说明问题。

原则3：迭代式发展

迭代式发展的精髓是：先设置一个大的目标，但要一步一步脚踏实地地去达成。

说到团队、项目要迭代时，大家都能理解，但其实每个研发工程师在负责自己项目的时候，也可以去迭代。

这个迭代指的是你要有这个能力把自己的项目分块，分成不同的部分去展现阶段性的成果。

比如在研发过程中有个很关键的环节：做代码检查。

很多同学喜欢把整个项目都做完了才发一个 code review request(专指请求别人给自己做代码检查），涉及很多文件，真正做检查的人很难给出有针对性的方案。

我们希望我们的研发可以把他的项目分成几块（逐块进行代码检查），这样做第一是对别人时间的尊重，第二也是一种个人能力的培养。

我们的迭代式发展讲究不惜一切代价快速推出实验，实验的时候不要追求完美。同时，我们也要求团队在做一些探索性的项目时要加上时间的限制。

在预定的时间内，如果没有发现突破，没有看到好的结果，要懂得放弃，降低实验的成本。

践行这条原则时需要注意的方面：

第一，我们经常会过分强调眼前一小步一小步地去达成远景的目标，可是这个远景目标到底是什么？

每过一段时间我们都要根据现在的项目进度及结果来思考是不是需要调整和改变远景目标，以免陷入一种叫“长期性的还债式的项目”。

举个例子：几年前，Lyft 对大数据的架构投入不够，所以造成了我们的系统比较落后。一个系统既要做数据的存储，又要做数据的查询工作，还要支撑数据的计算和整合。

如果我们只是一小步一小步地去优化这个计算，在整合中加以微调，而另一方面我们的业务还在迅速增长。

在这种情况下我们每次得到的提高根本比不上业务增长所带来的新的计算量，长此以往这个债永远都还不清，我们的系统永远都不能取得长足的进步。

所以这个时候这种迭代式的发展，一小步一小步走反而阻碍了我们，需要我们停下来看终点目标到底在哪里。我们可以反向规划，寻求一个长远的投资和短期的痛点之间的平衡。

第二，我们一些负责用户增长的团队，有的时候非常强调迭代，要做海量的实验。但是每一个实验从技术层面上说都很简单。

这样对本团队员工的职业发展可能不是最有利的，一些很资深的工程师、架构师不愿意加入这样的团队。这是我们技术管理者在人才的培养和培训方面需要解决的问题。

原则4：组合型发展

这里的关键是要寻找到产品的功能开发和基础架构之间投入的平衡点，全栈式的团队更要注重组合型的规划。

我们建议让技术主管、技术管理者对架构的投入直接负责；产品经理则要明确地知道不是团队中所有的人力资源都能放在做产品上。

大家都知道技术债务的问题，建议团队定期进行“技术债务偿还周”，就是每个阶段都花一周时间集中精力偿还这段时间所积累的技术债务。

这里说的技术债务，除了一些程序中的 Bug 之外，还包括架构的缺陷，甚至文档的短缺。

除了全栈组之外，我们还希望培养全栈的人才，就是一个人可以扮演多个角色。

一个人扮演多个角色，一方面有助于自己技术的提高，另一方面可以进行人才的轮换，让不同的人在不同的时间做不同的事情，这样也更有利于整个团队的平衡。

践行这条原则时需要注意的方面：

首先，组合型规划要避免在团队中出现小团队。如果明确划分你是做产品的，我是做基础架构的，那这个全栈团队的意义就消失了。

其次，要防止过度设计。在偿还技术债务的时候，也不能过度地追求完美。

举个例子：早年 Twitter 刚开始的时候，所有的程序都在一个程序库里面，当时 Twitter 的网站也就是一个可执行文件，很多初创公司都是这么过来的。

随着时间的发展，随着产品变得复杂，我们必须把单一的程序分解开，变成各个组件。

整个过程 Twitter 花了四年半的时间，因为目标是要把每一行代码都从这个单一的程序库中挪出来，变到其他的组件中去。

这一进程多次延缓或阻碍了产品功能的迅速推出。这就是上文说的当你有了组合型的规划，并对基础架构足够投入的时候，如果过度追求完美，也会带来负面的影响。

原则5：客户为先

每一个团队都要明确自己的客户，这个客户可以是终端用户也可以是公司内部的客户。我们提倡组建服务型、平台型的团队，找到客户并解决客户的痛点。

这里有很多实践案例，比如一个公司的设计团队除了追求美学上的完美设计，还要把研发、产品团队的进度纳入到自己团队的工作计划中去。

做品牌架构的同学经常会抱怨产品组把系统拖垮了，实际上你作为做平台的人就要把整合测试和压力测试作为自己的工作，要争取做出怎么用都用不坏的平台，这才是最好的架构。

面向客户，要时时刻刻关心客户的利益。有的时候增长过快会损害客户的利益，这时我们建议引进一个杠杆指标，对每个增长指标做更全面的考量。

比如在 Lyft 我们所有的产品组都会用到一个叫“T1K”的指标，即每一千单得到用户的投诉率。国内滴滴也在用类似的指标，以此来对所有的事业部进行横向的比较。

践行这条原则时需要注意的方面：

当有一些团队（特别是面向公司内部的服务型研发团队）做出了成绩，提高了其他客户团队的效率，我们希望有一个闭合反馈环，团队之间达成共赢，促进共同发展。

举个例子：在 Twitter、Lyft，我们的反作弊风控团队都开发了一个实时规则引擎。使用这个产品，在不经过提交代码的情况下，风控的运营团队可以比较独立地去抵抗突发事件，这大大提高了他们的效率，减少了他们对研发团队的依赖。

在这个过程中，我们希望运营团队可以用这样的引擎来保持实时关注，并及时发现新攻击种类，为研发团队提供最新线索和第一手资料，这样的反馈可以帮助我们的算法再提高。

原则6：统一性

全栈团队容易造成各个部门之间技术实现的不统一。这时我们可以在全公司范围内跨团队地形成专门针对某个技术领域的虚拟组，由这些虚拟组来推广规范。

当然这里覆盖的面很广，大到技术选择(technology)、架构(architecture)，小到设计模式(design patterns)、代码规范(code style)等。

再举一个与统一性原则相悖的例子：

在 Twitter 的早期，一半的工程师来自谷歌，他们觉得后台一定要用 Java 系统；另一半的工程师是自己创业，他们觉得 Java 太重，所以选择的是另一种语言 Scala，于是造成了 Java 和 Scala 两种语言并存的局面。

而当公司发展到 2000 人的时候，新来的员工上手很慢，因为他们需要重新学习语言，程式库的研发效率也很低，因为它要同时支持两个版本。当时一个不经意的决定成为了 Twitter 发展历史上最大的技术债务。

因此，我们鼓励研发人员在研发的过程中考虑里边的组件（尤其是界面上的组件）的可用性、延展性，这样大大降低了另一个技术的研发成本。

另外，我觉得对一个相同架构进行重复搭建的情况，不仅仅存在于一个公司中，在我们整个行业中也是非常普遍的。

我自己比较了解反作弊风控系统，知道 Facebook、Twitter、Lyft 等每个公司都有几十个甚至上百个研发工程师在重新搭建风控的架构，包括我前文提到的实施的规则引擎，这其实是一个巨大的浪费。

我个人认为实时的风控系统应该被开源。也有很多投资者希望我去创业，把风控的平台做成一个第三方的产品。

不过要实现并不容易，因为这里需要海量的数据和大数据技术，而这些信息都来源于成熟的大公司，只有他们愿意把用户注册账户和登录信息共享给你，你才能正确地看到数据及各种各样的攻击形式。

让这些大公司开源系统或共享数据都很难，第一会牵涉到用户的隐私，第二对公司的业务指标也是一种泄露，“有多少人注册账号”、“多少人登陆”，通过这些数据是可以从中推出这个公司有多少用户流量的。

践行这条原则时需要注意的方面：

跨团队的虚拟组有时会导致程序检查的阻滞，过度追求统一可能出现吹毛求疵的情况。

我们之前说了靠虚拟组来推广一些规范，如果是虚拟组让其他组里做同样技术领域的人来做代码检查的时候，只要不是逻辑的错误，针对代码的问题要提出善意的建议，不要轻易地 block 别人。

还需要特别注意的是对架构统一的过分追求可能会形成某一些资深架构师的单点权威，这样不利于其他研发人员的职业发展，同时也限制了总体的研发速度，最终可能成为发展过程中的瓶颈。

结语

前文提到很多技术工程原理，因为时间的关系都是点到为止。希望在今后的时间里可以做更深入的分享。

这些原理都是我根据自己这十年在硅谷不同公司做技术管理的经验总结出来的，大家在运用的时候一定要根据所处的竞争环境、公司的规模及人才结构来甄别哪些东西是适合自己的，哪些东西是可以直接复制的，哪些东西是需要做改变和调整的，一切方法和经验的借鉴都需要适应实际的国情和体制。

我认为硅谷是一个技术的圣地，但不是科技的神话。科技界未来的几十年里，我们中国的公司要起到更多的引领作用。

我希望更多的中国公司、更多的中国技术人可以归纳出自己的经验，分享给美国硅谷，也希望相互之间做更多的交流沟通，促进技术的共同进步。