对话是这样的：

创始人：“我的CTO说我们需要企业级的基础设施。”

CTO提出的要求：“必须从发布起就能应对大规模需求。如果有115个用户同时登录怎么办?我们需要10层微服务架构。”

没有线框图，没有客户访谈，没有任何证据表明有人想要这个产品。只有不切实际的架构设计。

作为一名担任多家初创公司兼职CTO超过二十年的从业者，我保存了一份令人沮丧的清单：31家倒闭的初创公司，总共烧掉了1250万美元。每次倒闭的原因都一样：为根本不会遇到的问题过度设计架构，却忽视了摆在眼前的问题。

百万用户的幻想正在扼杀初创公司

这种场景我已经见过太多次了，套路永远不变：

CTO花六个月时间搭建“可扩展架构”。他们在AWS服务器账单上烧光了资金，而这些服务器却是空的，最终发布时却无人问津，然后他们将责任归咎于“市场环境”，带着漂亮且可扩展的架构(但实际服务用户数为零)关闭了公司。

与此同时，那些由实习生打造出简陋最小可行产品(MVP)的顽强团队却抢走了客户，因为他们专注于解决实际问题。

就在去年，我合作的一家医疗健康初创公司每月在基础设施上花费28000美元，却只有12名测试用户。他们采用了15个微服务、Kubernetes、Apache Kafka，还雇佣了两名全职的DevOps工程师来维持系统运行。他们的架构图看起来就像东京的地铁线路图。

“这太疯狂了，”我告诉他们，“你们用卖柠檬水的预算，却想打造出Netflix那样的规模。”

房间里一片寂静，CTO的脸涨得通红。

“但我们必须做好扩展的准备。”他抗议道。

“你们得先活下来，”我回答说，“你们只有九个月的资金储备。在需要第二台服务器之前，你们就会倒闭。”

数字不会说谎，Stack Overflow第一年仅用两台服务器就服务了数百万用户，WhatsApp用32名工程师就处理了4.5亿用户，Instagram以13名员工的价格卖出了10亿美元。

这家医疗健康初创公司的微服务数量比客户还多，部署需要三个小时，工程师们80%的时间都花在修复基础设施上，而不是与用户交流。

如今，在整合为单体架构并将基础设施成本削减90%后，他们的年经常性收入(ARR)达到了275000美元，拥有120名付费客户。他们仍然在使用那个“简单”的架构，而CTO最初是反对的。

为什么聪明的人会在早期做出糟糕的决策

这个问题的根源并非技术上的无能。而是对初创公司早期生存需求的根本性误解。

我最近的一次对话很好地说明了这一点。一位CEO希望他的团队在第三次MVP迭代中改用TypeScript，尽管时间和预算压力都很大。

CEO：“我想要TypeScript，大家都在用。”

我：“为什么?”

CEO：“它更好，我想要，就这么定了，我付钱给你。”

我：“我能直言吗?你雇我们不是为了编写你喜欢的‘完美’代码，你雇我们是为了生存，快速测试假设，快速推向市场，专注于现在重要的事情，而不是类型安全。”

经过一番紧张的讨论后，我们坚持使用了JavaScript，结果不言而喻：

• 七周内上线，而不是用TypeScript需要的10-11周

• 两周后获得了第一个付费客户

• 进行了三次由用户驱动的快速迭代

• 四个月时进行了转型，节省了六个月的开发时间

• 凭借快速获得的市场反馈，获得了50万美元的融资

八个月后，他们终于看到了使用TypeScript的必要性，但那时，他们已经有了收入、用户和验证：这是做出明智扩展决策所需的基础。

心理上的陷阱在于，经验丰富的工程师往往来自重视规模、可靠性和完美架构的环境。当他们加入初创公司时，却将这些本能带到了完全不同的问题上。

在谷歌或Netflix，过度设计可能是明智之举，但在一家尚未盈利的初创公司，这无异于财务自杀。

实现可持续增长的务实之路

以下是我对每位初创公司CTO的建议：你的工作不是打造令人印象深刻的架构，而是帮助公司生存足够长的时间，以发现用户真正想要什么。

聪明的早期CTO不会为幻想中的数百万用户设计架构。他们会先打造产品以发现用户需求，然后在需求激增时再进行扩展。

那些过早痴迷于自动化和完美架构的公司，往往会错过客户真正需要的东西。你的前100个客户并不关心你的流程是否可扩展——他们只关心它是否有效。

我是通过观察成功公司的做法与我们所受教育的相反之处而学到这一教训的：

• Airbnb的创始人在每周收入200美元(由三位创始人平分)时，还会在周末为房源拍摄专业照片

• DoorDash的创始人亲自送出了前100份订单

• Reddit的创始团队使用不同的用户名发布内容，以使网站看起来内容丰富

• Diapers.com的创始人从Costco购买尿布并以亏损价格出售，只是为了测试需求

这些公司明白了一个关键点：你无法通过优化来达到产品与市场的契合，你必须通过与真实用户和真实问题的直接接触来赢得它。

你初创公司中最危险的人不是糟糕的工程师，而是痴迷于功能的创始人或为想象中的规模而设计的CTO，我亲眼见证了这种心态让一家获得620万美元融资的初创公司耗尽了资金。

为十个用户设计，而不是一千万

我对早期公司的建议非常简单：

• 打造出解决实际问题的最小产品。如果你对发布时的简陋程度不感到一点尴尬，那你就发布得太晚了。

• 关注三个指标：客户满意吗?你在基础设施上的花费是否少于1000美元?你能否在10分钟内完成部署?

• 招聘时注重务实，而非名气。在创业初期，我绝不会雇佣有前FAANG(Facebook、Apple、Amazon、Netflix、Google)背景的工程师。我的经验告诉我，在找到产品与市场的契合点之前，我们就会被过度设计所拖累。早期初创公司需要能够快速推出产品并根据真实反馈进行迭代的构建者。

• 关注资金储备，而非架构复杂性。每一个不必要的微服务都会让你更接近倒闭。每一个花在“完美”代码上而不是与客户交流的小时，都是错过学习重要知识的机会。

我之前提到的那家医疗健康初创公司就付出了惨痛的代价。在经历了数月的架构复杂性后，他们发现用户并不想要他们打造的一半功能。真正的突破来自于一个简单的流程变更，只花了两天时间就实现了。

有时候，最好的技术决策就是选择不采用技术手段。早期初创公司不会死于缺乏Kubernetes;它们会死于缺乏客户。

你早期的CTO应该是一个务实主义者，而不是一个完美主义者。因为学习总是比扩展更重要。

在你还没有十个用户的时候，就不要为第一个一百万用户做准备。为明天你能获得的十个用户做准备，了解他们的需求，然后在成功迫使你行动时再进行扩展。

你的资金储备——以及你初创公司的生命——都取决于此。

企业网D1net(www.d1net.com)：

国内头部to B IT门户，旗下运营国内最大的甲方CIO专家库和智力输出及社交平台-信众智(www.cioall.com)。旗下运营19个IT行业公众号(微信搜索D1net即可关注)。

版权声明：本文为企业网D1Net编译，转载需在文章开头注明出处为：企业网D1Net，如果不注明出处，企业网D1Net将保留追究其法律责任的权利。