在工程技术方面，早期创业公司最容易遇到的 4 个陷阱

编者按：本文来自微信公众号“光涧实验室”（ID：lightstream0），作者Nemil Dalal，经授权发布。

在光涧接触的创业者中，有很大一部分不是技术背景，或者暂时没有找到合适的技术合伙人，因此他们对于项目技术的选型和工程师的招聘标准常常有很多疑问。光涧实验室今天为大家分享 Nemil Dalal 的文章，希望更多非技术背景的创业者，也能从中了解到创业公司在工程技术方面的应该如何取舍。

2016 年的时候，一家初次创业并获得种子轮投资的食品外卖公司，向我寻求技术建议。在我看来，这家公司在技术方面的每个选择都是错的。

这家公司 CEO 认为，应该赋予工程师足够的权利。他让公司招聘来的第一个工程师选择了技术框架（Scala/Play），仅仅因为它是这名工程师想要使用的，而没有考虑公司的业务、使用场景以及是否好招到人。这家公司的早期工程技术大多数是外包的。他们的产品路线图过于乐观（网站和 App 同时在开发），而没有考虑到公司的业务还没有得到验证。每件事都算是灾难吧。

初创公司的工程技术，不同于其他类型的软件工程。初创公司的工程技术，相比于用「最佳方案」构建系统，更需要短期和中期的生产力；它更欢迎能够快速迭代，乐于使用破解（hacky）代码的人；它更喜欢技术上的实用主义，而不是选择最尖端或者最稳定的技术。

如果你的创业公司还没有找到产品和市场匹配（PMF），应该尽量避免下面这四个常见的工程陷阱。

初创公司最常见的工程失误就是过早地扩张规模。

过早扩张规模，指的是当你的业务还很小的时候，就想搭建能支持大规模业务的系统。这种方式牺牲短期效率，为的是长远考虑，但是这种长远考虑大部分情况都起不到作用。

过早扩张规模在创业领域很常见。2010 年初，SQL 数据库因为在无限扩展性上不及 NoSQL 数据库，比如 MongoDB 和 Cassandra 而被很多公司抛弃。但很多公司最终发现配套的 microservices 架构更适合复杂的业务，并不适合创业公司。过去很多年，Rails 被认为不适合创业公司，因为比其他框架慢（但现在变得流行）。

过早扩张规模会导致工程资源浪费。在未达产品市场匹配（PMF）之前就扩张规模，对于资金不充裕以及工程师很少的公司而言是毁灭性的打击。

如果说过早扩张规模是排在第一位的初创公司工程杀手，为什么这种情况会经常出现呢？

首先，规模扩张很有趣。Twitter 最早的版本是一个简单的单片式 CRUD 应用，任何工程师现在都能搭建一个。几年前，Twitter 遇到了各种问题，要查询大量数据、停机成本巨大、使用量大幅增加、用户数快速增长。使用扩展技术，来满足这些需求，对于工程师而言是一项非常有吸引力的工作。这种吸引力使得早期创业公司扩张规模，变成了工程团队最容易进入的陷阱。

第二，建立一个高性能的系统是看起来更合理的事情。一些工程师对 hacky（破解）技术感到惊讶，他们认为这样做意味着道德水准不高。这种对于不优雅解决方案的厌恶，通常对于那些曾经在大公司工作，处处都要考虑规模化的员工而言是比较大的挑战。Y Combinator 的创业基本法中有一条就是「做事情别考虑规模化」，不仅业务上如此，在工程上也是如此，实用至上。

很少有公司真的是因为技术债（因早期使用不成熟的技术，无法应对后期业务成长）而导致失败的。通常，如果你的业务成功了，你有足够的资金来修复之前所有的工程就错误和曾经走过的捷径。

第三，工程路线图和技术是依据对未来的最乐观判断而设定的。创业公司的管理者，对于业务的增长往往很乐观，否则也不会去创业。但是，即使你的公司找到了产品和市场匹配的阶段——关键的里程碑，工程决策需要重新审视——你可能还是高估了工程需要达到的规模水准。

想要预测未来需求，会导致珍贵的工程资源远离你最直接的目标：开发出人们真正需要的产品。

2.使用未经验证的技术

创业公司经常因为过度依赖最新的、最时髦的技术，而引发问题。

时髦的技术是软件工程师喜欢追求的。因为这样的技术会让工程师的工作更轻松、更愉快，尤其是在短期内。但是依赖最新出来的技术，会对于整个团队的生产力造成影响。

举例来说，MongoDB 类似 JavaScript 的 DSL 和 JSON 数据存储，使得 JavaScript 工程师编写代码更容易一些，尤其是跟 SQL 数据库相比。但是这种易用性不应该成为选择数据库时候的主要标准。

在一次面试中，一个软件工程师告诉我，他绝对不会在不使用 CoffeeScript （今天这种争论可能是 Elixir）的公司工作。如果一个正确的解决方案可以解决问题，但是与他的偏好不匹配，他也不会考虑。

新的技术往往也带来问题。大家对新工具的失败状态了解不多，所以很难想到会出什么问题。新的语言或框架意味着可用的库不会多，懂的工程师不太多。这种资源缺乏，往往导致开发成本增加，招聘人才的挑战更大。它还意味着，本来你可以专注于开发用户需要的功能，但却不得不花时间去学习怎么使用新技术。

部分原因在于工程师——特别是非创始人的工程师——想要使用让他们看起来走在市场前沿的技术。这是个问题。在一些领域，比如前端开发领域，如果工程师追求最新的技术，通常意味着每隔 6-12 个月就需要重写一次。

比较新入行的开发者，很容易想使用最新的、最时髦的技术，而没有考虑对这个项目而言最有意义的工具应该是什么。他们还没有经历过热门技术的发展周期，或者没看到过追逐新技术带来的负面影响。当他们看到 Hacker News 上介绍的新技术，或者参加黑客马拉松等行业会议看到新技术，就会把真实的市场需求忘在脑后。

还有更糟糕的情况，这些开发者没有意识到，一个技术很时髦未必就说明这项技术适合创业公司的环境。将一家知名创业公司或者一家大公司的技术堆栈直接移植过来使用，而不考虑是否适合自己公司，是很常见的。当公司团队比较小的时候，开发者比较难得到经验丰富的工程师指导，很容易受到外界影响。

初创公司的工程师，经常引用 Paul Graham 的著名文章 The Python Paradox，里面讲到，与 Java 相比 Python 提升了创业公司的生产力。Paul Graham 的文章经常被用来证明，创业公司应该使用最新的框架和编程语言。然而，他的真正含义说的是，软件工程师应该选择最大化创业公司生产力的工具，而不是不断尝试最新技术。事实上，Y Combinator 的多家创业公司在 2013 年问过 Paul Graham 理想的编程语言是哪个。他说，「我们有的初创公司用 PHP 编写代码，这让我有那么一丁点儿担心，但这事没那么重要，远不及其他更多事情让我担心。」

作为一名工程师，你冒着巨大的风险加入了创业公司。你不应该再增加因为追逐时髦、但必要性没那么强的新技术带来的风险，

3.雇佣了错误的工程师

很多创业公司的工程技术问题，源于雇佣了错误的工程师。

创业公司经常会需要牛人和高手。他们想要华丽的教育背景资历，还想要从知名公司出来的专家。在硅谷，创业公司总是更喜欢在使用新鲜技术的候选人，而忽略掉可以快速学习新工具的实用主义工程师。一旦创业公司开始只招聘所谓的牛人和高手，就设下了基调，之后的招聘也是会优先考虑类似的人才。

没有人专门教怎么在创业公司做工程师。大部分软件工程师都没有在创业公司工作的经历。因此，大多数加入创业公司的工程师不具备在创业公司环境需要的技能和态度。所以，创业公司不得不依赖那些不是最合适该项目的工程师来完成工作。

每种不同类别的工程师，可能会在创业公司遇到不同的问题：

• 初级工程师：容易被创业公司吸引，可能会使用太多新技术，在系统架构上比较弱。

• 外包开发商：更喜欢对很多不同的客户来说都能比较高效的技术，他们通常没有动力去为了每个单独的客户学习新技术。

  作为对比，理想的早期创业公司工程师对公司的使命感到兴奋。这可以确保，当创业公司在达到产品市场匹配过程中，遇到不可避免的挑战时候，工程师可以坚持下来。

  他们有打造最小可用产品（MVP）的思维，对于不断迭代的过程不会感到厌烦。最好的创业公司工程师，通常需要具备多年的工作经验，或者参与过开源项目的维护，知道如何维护一个系统，不只是做出来。

  他们不会把哪个技术当成救命稻草，他们更喜欢适配组织当前状态的生产力工具。最好的早期初创公司工程师，只把技术当成解决问题的手段。他们会思考遇到的问题是什么（用户的需求），如何用软件来解决这个问题，而不是去看有什么新技术可以解决问题。

  他们需要抱着应对挑战的态度。尽管他们面临着巨大的挑战，但是不会轻易说不可能。这样的工程师需要对自己的用户有同理心和直觉，因为他们在迭代的时候经常要扮演产品经理的角色。

  有个需要提醒的地方。在初创公司的工程师里面，不同阶段能获得的经验是完全不同的。一个在 5 个工程师的团队工作很好的工程师，很可能在 25 个工程师的团队遇到问题。创业公司在招聘人才的时候，当看到一个候选人曾经在知名的创业公司工作过，就会倾向于相信他能胜任工作，但常常忽视了这名候选人在这家公司到底做了什么。

  创业公司应该不要把注意力放在知名公司的牌子上，而是根据现在项目的需求匹配度来招聘人才。

  

  4.产品管理的问题

  很多创业公司在工程方面的陷阱，是因为产品管理的问题而引发的。

  创业公司创始人通常都很乐观，产品路线图通常超出了小团队的能力范围。这种乐观会导致招聘过多的人、花费太多融资的钱以及最终难以为继。对于管理者来说，通常他们会觉得工程师们能力不行，但实际上问题在于管理者没有设立清晰和明确的目标。

  另一个可能的问题是，创业公司管理层经常会找到外部的顾问——来自其他知名公司的工程师——来指导初创公司的工程业务。这样引入的所谓专家，很可能是从跟业务无关的公司或领域请来的，这些专家会把他们公司的做法介绍到新公司，但对于新公司，他们只是花了几个小时去理解业务，通常很难深入理解业务。

  最后，管理者需要认识到，工程师是所有重要产品决策的关键组成部分。在很多公司，工程师被认为是服务机构，等已经做出重要的业务决定才通知工程师最终结果。这样做肯定是不对的。只有建立健康的产品-工程关系，才能做出令人骄傲的产品。

  总结

  即使你能避开上述所有这些创业公司会遇到的工程技术陷阱，你还是会面临许多挑战。但是，毕竟每避开一个陷阱，就多增加一些工程效率。

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

  标题：Four Startup Engineering Killers

  作者：Nemil Dalal

  翻译：光涧实验室