扼杀创业公司的3个工程错误

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

我从事工程咨询工作，担任兼职首席技术官（CTO）角色，已经大约一年了。目前的工作与我之前在企业的工作截然不同。

首先，我的客户群体更加多元化。在亚马逊，我主要与工程师共事。而咨询行业中，我合作的大多数创始人都是非技术出身。

因此，沟通被赋予了更高的优先级——以最简单的方式向客户解释技术问题。

此外，由于大多数初创公司都是从零开始构建产品，我原以为这会让工程开发更容易。但事实证明并非如此。

我的许多客户花费超过六位数的资金和几个月的时间来构建 MVP，结果项目却耗时过长或根本无法交付。

他们来找我，想办法让他们的产品重回正轨。

幸运的是，这种情况完全可以避免。我已经见过几十个客户遇到过类似的情况，我发现这些项目失败往往都是因为同样的三个错误。

这种情况通常发生在初创公司：

• 错误地设定了功能构建的顺序

• 在产品的第一版中塞入了太多功能。

• 别让完美主义阻碍了速度

如果创始人专注于避免这 3 个错误，他们就可以避免数月的挫败感，并更快地将产品交付给客户。

1. 构建功能的顺序很重要

创始人犯的第一个错误就是没有要求工程师按照正确的顺序构建功能。

通常情况下，创始人会带来一份设计文档，其中列出了产品的功能，然后要求工程师去实现它。

但是，在列出要构建的功能时，构建功能的顺序很重要。

具体来说，你希望工程部门首先构建核心技术，而不是最后才构建。

核心技术是指客户从产品中获得最大价值的部分。

例如，如果你是像谷歌这样的搜索引擎，那么返回正确的搜索结果比“手气不错”按钮更难构建，但能为客户带来更多价值。

所以，搜索算法是工程部门首先要构建的东西。

对于像 Uber 这样的共享出行产品来说，在 5 分钟内将您与司机联系起来，远比任何账户设置页面都重要得多。

因此，你首先需要关注的是构建司机和乘客之间的匹配过程。

你会先构建哪个页面？

我见过很多工程案例，比如一些机构会花几个月的时间构建用户界面，但到了构建实际软件的时候，他们却失败了。

如果代理机构无法构建对您的产品至关重要的特定功能，您需要尽快了解此事。

我最近一次通话中就遇到了这种情况。一位客户花了数千美元请另一位工程师帮忙，结果现在他想在网站上嵌入一个财务计算器。

当我问他们发生了什么事时，他们给我看了他们最后一位工程师建造的东西：

这位工程师花了两个月时间开发了这两个页面，但他们始终没有实现应用程序的核心部分——计算器！

而到了制造计算器的时候，他们却发现做不到，因为有些计算在数学上太复杂了。

如果客户当初要求工程师先构建计算器，他们就能更快地发现这个困惑，并确定构建核心技术是否在他们之前招聘的员工的技能范围内。

因此，在开发产品时，以下三个问题可以帮助您确定功能优先级：

1. 您认为应用程序中的哪一部分是“核心”技术？

2. 应用程序中哪个部分开发起来最难、风险最大？

3. 你的应用中有哪些功能是其他产品已经内置的功能，又有哪些功能是全新的？

关于第 3 点，如果产品中有些部分是你以前没见过其他人构建的，那么在构建其他任何部分之前，你可能需要验证该部分在技术上是否可行。

2. 初次申请功能过多

功能构建顺序错误导致的必然结果是，需要构建的功能过多。

当客户将工程视为构建“一系列功能”时，就会出现这种情况。例如，如果他们看到一辆汽车，他们会将其视为所有功能的总和，包括：

• 信号灯

• 加热座椅

• 空调

他们会把造车看作是按清单逐项完成功能。

然而，这几乎肯定会造成工程项目延误，因为它会产生一个庞大的功能列表，需要构建的功能会给工程部门带来巨大压力。

我经常告诉客户，与其将产品视为一系列功能，不如更多地关注他们试图为客户解决的问题是什么。

对于每一个功能，都要问自己：“这个功能如何帮助解决客户的痛点？”，以便缩小工程需求列表。

例如，汽车解决的主要问题是帮助人们更快地从 A 地到达 B 地。

因此，对于最初的原型车来说，我们当然不需要空调，也不需要后备箱，更不需要座椅加热。

如果我们关注这个问题，这就引出了一个问题：我们是否真的需要汽车？因为或许滑板车、自行车，甚至滑板也能帮助人们更快地从 A 地到达 B 地。

我经常鼓励创始人思考他们最初产品的“滑板版”是什么，而不是只考虑功能。

这将有助于更快地推出原型，有时可以将工程估算时间从几个月缩短到不到一周。

示例：制作一个图钉克隆产品

我最近和一位创始人聊过，他正在搭建一个类似于 Thumbtack 的网站，但用户可以通过电话获得预订方面的帮助。

Thumbtack是一个可以预订本地专业人士服务的网站。

最初，他们表示希望在原型产品中集成所有这些功能，包括视频通话、支付和预订系统。但每项集成都会增加大量的工程工作，并延迟产品的发布。

但如果客户只是需要预订方面的帮助，或许他们并不需要这些功能。对于原型来说，只需提供一个查看服务列表、拨打电话指定预订服务，然后由专人通过通话处理后续事宜的功能就足够了。

事实上，这款应用与外卖应用 DoorDash 的第一版非常相似。虽然 DoorDash 现在拥有许多高级功能，但他们最初的网站只是一个电话号码，你需要打电话告诉他们你想吃什么。

创始人会打电话给餐厅订餐，取餐后再送到你家。无需任何集成或预订，他们的最小可行产品（MVP）里只有一个电话号码和一些操作说明！

DoorDash 的初始 MVP

这个原型非常简单，他们可以在一周内完成。但如果他们试图加入所有复杂的集成功能，并把现在的大量功能都整合进去，这很容易就会变成一个耗时数月的项目。

因此，在这种情况下，我建议创始人考虑采用类似于 DoorDash MVP 的产品版本来克隆他们的 Thumbtack，而不是采用他们最初设想的版本。

打造产品的“滑板版”，并专注于解决客户问题而不是仅仅列出功能清单，将有助于将一个需要数月才能完成的项目缩短到几周之内。

3. 追求完美的工程架构

最后一个常常导致延误的错误是追求工程完美主义。

创始人往往希望他们的产品从一开始就拥有完美的架构和完美的可扩展性，这给工程团队带来了很大的压力。

他们常常担心，如果像 Facebook 那样在上线后的四个小时内就有 22,000 人访问 Facebook 的第一个版本，就会出现服务中断的情况。

就连Facebook在早期也和现在大不相同。

事实上，大多数产品发布都相当悄无声息。我见过无数次创始人发布产品后，访问量远低于预期。我之所以知道，是因为我记得自己曾经在Reddit上发布RecordJoy.com，当时也满心期待它能一炮而红。

我不仅没得到一个赞，还因为发布垃圾信息被该子版块封禁了😢。

有时，这种完美主义也源于试图模仿大型科技公司的工程实践。他们看到那些公司整洁的代码库和微服务架构，就想当然地认为他们的创业公司也应该这样做。

然而，初创公司的工程设计与大型企业的工程设计截然不同。在FANG（Facebook、Netflix和谷歌）这样的公司中，产品已经实现了市场契合，因此可维护性和可扩展性才是更受关注的问题。

然而，初创公司仍在寻找产品与市场的契合点，它们可能需要多次调整方向，以至于最初的系统可能永远不会被使用。

通常情况下，最好先让功能运转起来，验证这是否真的是客户想要的，然后再投入更多资源进行扩展。

在某些情况下，你可能会发现你最初构建的“权宜之计”可能会比预期走得更远。

Stack Overflow 就是这种情况。

例如：Stack Overflow 的单体结构

《系统设计面试》一书的作者 Alex Xu 曾在推特上讨论过 StackOverflow 的架构。

他指出，如果你在面试中尝试用本地服务器和单体架构来设计 StackOverflow，你很可能得不到这份工作，因为这被认为是一种糟糕的工程实践，而且不具备可扩展性。

但实际上，StackOverflow 就是这样建立起来的！

正如你所看到的，StackOverflow 的“完美”架构是将网站分解成单独的组件，例如评论、用户管理和问题，并将每个组件隔离在自己的微服务中。

然而，他们目前的系统虽然并不完美，但构建起来要简单快捷得多，而且仍然能够扩展到每月超过 1 亿次的访问量！

因此，工程设计中通常也包含实用性因素。与其一开始就追求完美，不如采取迭代方法，先确保功能正常运行，然后在适当的时候进行重构，使其更具可扩展性。

或者像 Stack Overflow 那样，永远不要重构，因为他们那蹩脚的原型碰巧也能很好地扩展 🙂。

结论

三种不同的工程思维转变，可以决定你是陷入长达数月的工程泥潭，还是在一周内就将产品交付给客户。

作为创始人，如果你专注于：

1. 注意构建功能的顺序

2. 首先打造产品的“滑板版”。

3. 优先考虑功能性而非工程完美主义

你也可以走上打造下一个十亿美元创业公司的道路。

你到了之后记得给我留点儿吃的！

💡 如果您喜欢这篇文章……

我每周二都会发表一篇新文章，分享关于创业、工程和生活的实用想法。

订阅即可获得免费电子书，内含我的写作导师联系方式。（请查看欢迎邮件）

点击此处加入我的电子报订阅者行列，已有 3,839 位订阅者。