过早扩张、未经检验的技术，创业公司最易跳入哪些致命陷阱？
对早期的软件初创公司，请注意避免这些工程错误。
2016 年，我为一个初次创业者提供了技术咨询，帮助他建立一个种子基金资助的食品配送市场。在我看来，他这家公司做出的每一项技术选择都是错误的。
CEO 信奉“将权利赋予工程师”的理念，然后让他们的第一个工程师进行框架（Scala/Play）选择，仅仅因为这个架构是工程师要使用的，而不是因为这个架构能对公司、对实用案例或对人才招募有帮助，他们许多早期的技术工作都是外包的。他们的产品路线图看起来非常乐观（同时发展网络端和移动端），尽管大多数业务仍然未经验证，而这就是灾难的根源。
创业工程不同于任何其他类型的软件工程。相对于构建系统的“正确方式”，它需要短期和中期的生产力。它重视那些能够快速迭代并熟悉黑客代码的人。它在技术选择上注重实用主义，而不是选择最热门的或最稳定的技术。
如果你的初创公司尚未找到适合市场的产品，本文有四个常见的工程陷阱需要注意避免。
最常见的创业工程错误是过早扩张。
过早扩张意味着当你的公司还很小的时候，就进行大规模地扩张。希望过早地扩张能立即获得长久的生产效率提高，但事实上从未实现过，也从未获益过。
初创公司普遍存在过早扩张的问题。在 2010 年代初，人们之所以避开 SQL 数据库，部分原因是由于人们认为 MongoDB 和 Cassandra 这样的 NoSQL 数据库具有无限的可扩展性。在微服务的刺激下，单一的创业生产力优势消失殆尽。多年来，人们一直认为 Ralis 不适合初创公司，因为它比其他框架都要慢得多。
过早扩张会浪费工程资源。在达到产品市场需求之前就进行扩张，对于那些无论资金还是工程师都很匮乏、但功能要求很高且需要不断迭代的早期初创公司来说不啻为一场毁灭性的打击。
既然说过早扩张是初创公司的头号杀手，为什么还会经常出现过早扩张呢？
首先，扩张真的很有趣。Twitter 的初始版本是一个简单的单一 CRUD 应用，现在任何一个集训工程师都可以构建出来。仅仅过了几年，Twitter 就出现了一系列有趣的问题：需要查询大量数据，停机成本很高，使用量激增，用户群庞大。为满足这些需求，Twitter 引入了规模化的技术，使这项工作对那些加入的员工来说更加令人兴奋、更具有吸引力。这种兴奋使早期扩张成了工程团队容易陷入的陷阱。
其次，建立绩效体系似乎是合理的需求。一些工程师对黑客系统感到震惊，仿佛它们就是一种道德沦丧的象征。对于那些为大型科技公司工作的创业工程师来说尤其是个问题，这种可能不太优雅的解决方案令人厌恶，因为在这些公司里，所有事情都必须规模化完成。“不做规模化的事”是 Y Combinator 公司的一条常见建议，它在工程中的应用，和在业务流程中的应用一样多。
技术债务导致早期初创公司的夭折比你想象的要少。如果你成功了，你通常会有足够的资金来弥补你犯下的所有工程错误和你采取的捷径。
再次，工程路线图和工具是围绕对未来过于乐观的观点而构建的。创业领导者对他们的企业如何发展充满了理想主义，让我们面对现实，否则他们是不会创办这些公司的。即使你到达了产品市场的关键里程牌，当工程决策需要重新评估时，危险在于——你高估了你需要的规模水平。
试图在未来需求出现之前就预测它们，会使你的直接目标，也就是开发人们需要的产品，失去宝贵的资源。
当初创公司过于依赖高大上的或新的技术时，往往会伤害到自己。
高大上的技术是软件工程师们梦寐以求的技术。高大上的技术通常会让工程师的生活更加轻松愉快，特别是在极短的时间内。但是，依靠最新的技术，往往没有考虑到在中期内对广泛的团队来说最有成效的事情。
比如说，与使用关系型数据库 SQL 相比，MongoDB 的类似 JavaScript 的 DSL 和 JSON 数据存储使编写代码对于 JavaScript 开发人员来说更容易。但是，易用性不应该是选择数据库的主要指标。
在一次采访中，有一名软件工程师告诉我，他永远不会在一家不使用 CoffeeScript 的公司工作（放在今天，这场辩论应该是关于 Elixir）。如果正确的解决方案与他的偏好不符，他甚至会拒绝考虑其他工具，如此一来，就可能会出现问题。
新技术也有它自身的问题。人们对新工具的故障状态知之甚少，因此很难预测事情会如何恶化。而新的语言 / 框架，它们没有库，也没有很多可以用它们来编写代码的工程师。这种资源的缺乏增加了开发工作量，并使招聘工作面临着挑战。它还意味着，当你专注于创造用户看重的功能时，却要把你的初创公司所稀缺的工程资源投入到学习新东西上。
部分问题在于工程师，尤其是非创始人，想要实施的技术，能够让他们在市场上显得举足轻重。这应该会让初创公司感到担忧。在前端工程这样的领域中，让工程师追逐当前的炒作周期就可能意味着每过 6~12 个月就要重写一次堆栈。
开发人员在其职业生涯的早期，特别容易使用新的、高大上的技术，而不是对手头项目最有意义的工具。他们没有经历过几次炒作周期，也没有看到所选最新技术的缺点。当他们阅读黑客新闻或参加黑客马拉松 / 会议时，可能会错过他们看到的所有营销活动。
更槽糕的是，这些开发人员并没有意识到，仅仅是因为某项技术被大肆炒作，但实际上并不适合在创业工程的环境中使用。在没有评估这些选择的适当性的情况下，采用知名创业公司或大公司的技术堆栈并移植其堆栈是一种很常见的做法。当团队规模还很小时，开发人员并不总是能够得到经验丰富的工程师的指导，从而抵消外界媒体对他们施加的影响。
初创公司的开发人员往往喜欢引用 Paul Graham 著名的文章：《The Python Paradox》，作者在这篇文章中提到，与 Java 相比，Python 提高了初创公司的生产力。Graham 那篇文章经常被用来证明实施每一个最新的框架和语言的合理性。然而，Graham 的真正观点是，软件工程师应该选择能够最大限度提高初创公司生产力的工具，而不是条件反射式地偏爱最新的技术。事实上，在 2013 年看到 Y Combinator 公司的创业团队后，Graham 被问及理想的语言是什么。他指出，“我的意思是，我们有一些初创公司在使用 PHP 来编写代码，这让我有点担心，但不像其他事情那么让我担心。”
作为一名工程师，加入一家初创公司对你来说就是冒着巨大的风险。你不应该增加炒作的风险，但也不应该添加不必要的技术。
很多创业工程问题源于雇佣了错误的工程师。
初创公司经常寻找“摇滚明星”或“忍者”。他们想要华而不实的学历证书，以及来自成功公司的“精灵之尘”。在硅谷，初创公司的招聘职位倾向于那些使用新的、高大上的技术的候选人，而不是青睐能够快速学习必要工具的务实工程师。一旦一家公司从雇佣“摇滚明星”和“忍者”开始，那么它就为以后的每一次招聘定下了基调。
很少有人教授创业工程。大量的软件工程师为非初创公司工作。因此，大多数加入初创公司的工程师都没有接受过创业工程方面的培训，也没有在创业环境中获得成功的技能或态度。因此，初创公司往往必须依赖于那些并不完全适合该项目的工程师。
这些工程师都有自己的创业风险：
大型公司的工程师经常接触到规模庞大的系统，可能对黑客代码感到不舒服。他们不太可能接触到用户。
优秀的计算机科学家对管道式工程感到厌倦，而这种工程代表了早期创业任务，导致工程过度设计。
年轻的工程师往往被初创公司吸引，他们可能会注入太多的新技术，而且他们设计的系统架构设往往很差。
开发部门往往倾向于那些能够让他们在许多客户中保持高效的技术。他们没有为特定客户学习新工具的动力，也没有长期参与到早期关键技术决策的游戏中。
相比之下，理想的早期创业工程师应该对公司的使命感到兴奋。这确保当公司在产品市场适应的过程中不可避免地遇到挑战时，他们会留下来。
他们有一个最低可行的产品理念和不断迭代的舒适感。最好的创业工程师通常有几年的工作经验或开源项目经验，这样他们就可以学会如何维护系统，而不仅仅是构建系统。
他们不会把特定技术视为灵丹妙药，而是青睐于满足组织中期需求的生产工具。伟大的早期创业工程师将技术视为解决问题的一种手段。他们考虑的是问题空间（用户的需求）以及如何使用软件来解决问题，而不是去寻找新技术可以解决的问题。
他们需要有一种积极的态度。在面对巨大挑战的同时，也在缓和（但不是否定）产品所有者的乐观态度。这些工程师需要对用户有同理心和直觉，因为他们在迭代时经常扮演产品的角色。
有一个注意事项需要说明的是，即使在创业工程师中，在创业的每个阶段获得的经验也是截然不同的。一名能够胜任五个工程师的创业工程师，在他 25 岁的时候表现可能会很槽糕。对于招聘人才的初创公司来说，看到一名成功初创公司中的工程师往往掩盖了那个人在那里真正做的事情的细微差别。
初创公司应该着眼于品牌之外的东西，并根据当前项目的需求进行按需招聘。
很多初创公司的错误都源于产品和管理，而不是工程。
初创公司的创始人非常乐观。产品路线图往往会超出他们小团队的能力。这种乐观情绪导致了过多的招聘和筹资，最终让整个公司感到精疲力竭。对于管理层来而言，这个周期开始的时候看起来像“工程师没有尽职”，实际上这意味着管理层没有建立一个清晰而聚焦的愿景。
尽管商业模式存在不确定性，但创始人始终如一的创业心态也让工程团队对如何构建系统产生了错误的确定感。更好的心态是支持乐观的工程师，并培养在内部感到悲观的商业领袖，双方共同努力寻找产品与市场的契合点。
新初创公司的另一个问题是，管理层经常在其他成功的初创公司找工程顾问来指导他们的新初创公司。然而，从可能不相关的公司或领域引进的所谓的“专家”会带来一些问题，因为这些顾问仅仅花了短短几个小时就试图了解这家初创公司，并就把自己过往的经验移植进去。
最后，管理层需要认识到，工程师是任何重大产品决策的关键组成部分。很多时候，公司的工程师经常被视为一个服务组织，当出现重要的商业决策时，这个服务组织被要求强制执行（确保产品和工程之间的良好关系是雇佣合适的工程师的另一个重要原因）。
即使你成功避免了这些创业工程的陷阱，但你仍然会面临很多挑战。但是，通过避开这些陷阱，你就不会那么担心自己造成的伤害了。
https://hackernoon.com/four-startup-engineering-killers-1fb5c498391d