杀死初创科技公司的四大工程陷阱

2016 年，我为一位首次创业的企业家提供技术建议。在我看来，这家公司做出的每一项技术决策都是错误的。

公司的 CEO 认为应该给工程师“放权”。他们让第一个工程师选择框架（Scala/Play），因为这刚好是这位工程师想要使用的框架，而不是因为它对公司、他们的使用场景或招聘有任何意义。他们很多早期的技术工作都是外包出去的。他们的产品路线图非常乐观（Web 和移动同时铺开），尽管大多数业务仍然未经过验证。

初创公司的工程与其他类型的软件工程不同。相比“正规”的构建系统，它们需要的是中短期的生产力。它们更加重视那些能够进行快速迭代的人，它们更倾向于实用的技术选型，而不是选择被炒作过度或稳定的技术。

如果你的初创公司还没有找到可以打入产场的产品，那么就需要避开以下四个常见的工程陷阱。

初创公司最常见的工程错误是过早扩大规模。

过早扩大规模是指当公司还很小的时候就构建大规模的系统。过早扩大规模是用眼前的生产力换取未来可能永远无法兑现的好处。

过早扩大规模这个问题在初创公司中非常常见。在 2010 年代早期，因为 NoSQL 数据库（如 MongoDB 和 Cassandra）的无限可伸缩性，人们在一定程度上开始避免使用 SQL 数据库。在微服务的大潮中，初创公司单体系统的生产力优势消失殆尽。多年来，Rails 一直被认为不适合初创公司，因为它比其他框架慢。

过早扩大规模会浪费工程资源。对于早期的初创公司来说，在产品进入市场之前就进行规模扩张很可能是毁灭性的，因为这些公司并没有多少钱，也没有多少工程师，但功能需求巨大，需要不断进行迭代。

如果说过早扩大规模是创业公司的头号杀手，那为什么它会如此频繁地发生呢？

首先，扩大规模是一件很有趣的事情。Twitter 最初只是一个简单的单体 CRUD 应用程序，任何一个刚参加完训练营的工程师都可以搞定它。短短几年，Twitter 就出现了一系列有趣的问题：查询大量数据、停机成本巨大、资源使用高峰期、用户群庞大。为解决这些问题而加入可扩展的技术是一件很令人感到兴奋的事情，但这种兴奋却是工程团队在早期容易掉进去的一个陷阱。

其次，构建高性能的系统似乎是非常合理的。一些工程师对“hack”系统感到很震惊，好像在他们看来这是一种道德沦丧。对于那些曾经在大型科技公司工作过的创业公司的工程师来说，这种对可能不优雅的解决方案的厌恶尤其是个大问题。 “做不可扩展的事情”是 Y Combinator 的一条常规信条，它不仅适用于业务流程，也适用于工程领域。

技术债务扼杀初创公司的可能性比你想象的要小得多。如果你成功了，就有足够的钱来弥补之前犯下的工程错误和走过的捷径。

第三，在建立工程路线图和工具时，他们对未来充满了乐观的情绪。创业公司的领导者对业务的增长太过理想化，否则他们就不会创办公司了。即使你的产品契合市场——一个需要重新评估工程决策的关键里程碑——但你仍然可能会高估必要的规模水平，这是很危险的。

在未来的需求出现之前就对其进行预测，会占用当前目标（开发人们需要的产品）的宝贵资源。

当初创公司过分依赖那些闪亮的新技术时，他们会伤害到自己。

闪亮的新技术正是软件工程师迫切需要的。新技术往往会让工程师的生活在极短的时间内变得更轻松、更愉快。但是，因为过度依赖新技术，往往会错过在中期内对团队来说最有成效的东西。

例如，对于 JavaScript 开发人员来说，与使用关系型 SQL 数据库相比，MongoDB 的 DSL 和 JSON 数据存储让编写代码变得更容易。但是，易用性不应该是选择数据库的主要标准。

在一次面试中，一位软件工程师告诉我，他不会在一家不使用 CoffeeScript 的公司工作。如果正确的解决方案与他的偏好不一致，他会拒绝考虑使用其他工具，这可是一个大问题。

新技术有其自身的问题。人们对新工具可能会发生的故障知之甚少，因此很难预测会发生怎样的问题。新的语言或框架没有太多的可用库，也没有太多可以熟练使用它们的工程师。缺乏这些资源会增加开发工作量，并让招聘工作面临挑战。况且，你还需要让稀缺的工程资源去学习新的东西，而他们本应专注于创建对用户来说有用的功能。

部分问题在于工程师（尤其是非创始人）总是希望实现那些让自己看起来与市场与时俱进的技术。这是创业公司最需要担心的事情。在前端工程等领域，如果工程师要追赶技术炒作周期，可能每 6 到 12 个月就要重写一次系统。

开发人员在其职业生涯早期倾向于使用闪亮的新技术，而不是那些对手头的项目来说最有意义的工具。他们没有经历过什么技术炒作周期，也看不到新技术存在的不足。

更糟糕的是，这些开发人员并没有意识到，被炒作的技术并不一定适合被用在初创公司中。一种很常见的情况是，在还没有做出适用性评估的情况下，直接生搬硬套知名创业公司或大公司的技术栈。当团队规模很小时，开发人员并不总能得到经验丰富的工程师的指导，以抵消外部媒体对他们的“侵袭”。

初创公司的开发人员经常引用 Paul Graham 的“Python 悖论”。这个悖论是说，与 Java 相比，Python 更能提高初创公司的生产力。Graham 的文章通常被用来证明每一个新框架或每一门新语言的实现是否正确。但实际上，Graham 的真正观点是，软件工程师应该选择能够最大限度提高初创公司生产力的工具，而不是本能地偏好最新的技术。事实上，2013 年在 Y Combinator 与初创团队见面时，Graham 被问及他心中理想的语言是什么。他说：“我的意思是，有些初创公司还在使用 PHP，这让我感到有点担心，但它并没有其他事情那么让我感到担心”。

作为一名工程师，加入初创公司实际上已经冒了巨大的风险。你不应该再把采用被过度炒作但不必要的技术的风险也带进来。

很多初创公司的工程问题源于招错了工程师。

初创公司通常喜欢找“摇滚明星”或“忍者”这样的人。他们想要华丽的学历证书或者从大公司出来的小精灵。在硅谷，初创公司偏爱使用闪亮新技术的候选人，而不是那些能够快速学会怎么使用工具的务实工程师。一旦公司以“忍者”和“摇滚明星”作为标准，就为后面招聘的每一位员工奠定了基调。

初创公司的大部分软件工程师最初都是在非初创公司工作。因此，大多数加入创业公司的工程师都没有受过创业工程方面的培训，也不具备在创业环境中取得成功的技能和心智。因此，初创公司往往不得不依赖这些并不完全合适的工程师。

这些工程师存在以下这些风险：

• 大型公司的工程师经常接触大规模的系统，并且可能不习惯于“hack”代码。他们也不太可能会接触到他们的用户。

• 优秀的计算机科学家会对管道式工程感到厌倦，这类工程是初创公司早期阶段的典型代表，会导致过度工程化。

• 被初创公司吸引的初级工程师可能会注入太多的新技术，但却很难架构好他们的系统。

• 开发团队往往倾向于使用能够让他们在跨多个客户时仍然能够保持高效的技术。这些团队没有动力为特定客户学习新工具，他们也不具备足够的动力做出关键的早期技术决策。

相比之下，理想的初创公司工程师应该对公司的使命保持认同感。这样可以确保他们在公司不可避免地遇到挑战时仍然不会离开公司。

他们拥有最小可行性产品的概念，并能够适应不断迭代的流程。最优秀的初创公司工程师通常都具备几年的工作经验或开源项目经验，因此他们已经学会了如何维护系统，而不仅仅是开发系统。

他们不把特定的技术看作是灵丹妙药，而是喜欢选择那些能够满足公司中期需求的生产力工具。伟大的初创公司工程师将技术视为解决问题的手段。他们经常考虑的是问题空间（用户的需求）以及如何使用软件来解决这些问题，而不是把关注点放在新技术可以解决那些的问题上。

他们需要有一种“我能行”的态度。他们面临着巨大的挑战，同时要缓和产品所有者的乐观情绪，而不是去反对他们。这些工程师需要具备用户同理心和直觉，因为他们在产品迭代过程中经常扮演产品人的角色。

需要注意的是，初创公司的工程师在每个阶段获得的经验也可能完全不同。在一个 5 人初创团队中表现优异的工程师在 25 人的团队中可能表现得很糟糕。初创公司在招聘人才时，看到一位从成功的初创公司出来的工程师，但其实表面的光鲜往往会掩盖这个人之前的实际工作表现。

初创公司应该看透表面的光鲜，最重要的是要根据当前项目的实际需要来招聘人才。

有很多初创公司的错误源于产品和管理，而不是工程。

初创公司的创始人总是过于乐观，产品路线图通常会超出团队的能力。这种乐观情绪导致了过多的招聘、过多的融资，最终精疲力尽。在管理层看来，这似乎是因为“工程师表现不佳”，但实际上是因为管理层没有设定好清晰的愿景。

初创公司的另一个问题是，管理层经常会找工程顾问——其他成功初创公司的工程师——来指导自己的公司。当这些顾问把在他们公司学到的东西生搬硬套到一个他们只花了几个小时去了解的新公司时，相当于从可能不相关的公司或领域引进所谓的“专家”，这可能是个大问题。

最后，管理层需要认识到，工程师是重大产品决策的关键组成部分。很多时候，工程师被看作是一个服务组织，当出现重要的商业决策时，他们就会被压垮。因此，为了确保有一个健康的产品和工程关系，招聘合适的工程师是十分必要的。

即使你避开了这些初创公司的工程陷阱，仍然会面临其他挑战。但避开这些陷阱起码可以让你不那么担心给自己造成伤害。

https://hackernoon.com/four-startup-engineering-killers-1fb5c498391d