技术的发展迎来盛世，是机遇还是挑战？环境在急剧变化，竞争压力在不断增加，技术型企业和研发团队如何在竞争的大潮中屹立不倒稳步向前？
一位常年征战于硅谷技术管理前线的技术工程文化践行者认为竞争的核心在于“效率”、“质量”和“人才”。本文将分享他用十年的经验总结的 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：组合型发展
这里的关键是要寻找到产品的功能开发和基础架构之间投入的平衡点，全栈式的...