本文转自：何晓阳读书笔记，公众号ID：hexiaoyang101 当我们宣布 RethinkDB 公司正式倒闭的消息时，我曾经承诺要写一份事后总结检讨。我花了一些时间来审查过去这段经历，现在我可以把它清楚地写下来。在 Hacker News 上，网友帮忙指出了很多 RethinkDB 失败的原因，既有人性本身难以理解的刚愎自负，也有来自 MongoDB 营销团队的“精明”策划，还有人说，是因为我们缺少有经验的Go-to-Market 团队，以及对64位以上浮点运算缺乏支持。我将这些评论和总结放在这里，希望能够给大家带来一些启发和建议：
首先，我必须说明，其中的一部分原因有一定的真实性，但是它们仅仅是问题的表现，并不是真正的原因。比如我我们没能赚钱就是一种同义反复，它并不能解释我们失败的原因。
我们在事后进行了复盘，发现有两个方面存在问题：第一个，我们选择了一个非常槽糕的市场，并且按照错误的“优秀衡量标准”进行了产品化。甚至每一个错误都可能将 RethinkDB 的价值减少了一到两个数量级。因此，如果当时我们能把其中任何一个方面做对，RethinkDB 都可能会达到 MongoDB 的规模。如果我们能把两个方面都做对，最终我们就能达到Red Hat 的规模也未尝可知。（备注：当然，别对数字太较真。作者说的是大概的数字，不过这应该能够让你了解这些错误造成的后果）
糟糕的市场 我们当时的想法是这样的，一家新的数据库公司不太可能会超越甲骨文。因此，我们想创办一家新的基础架构公司，数据库市场规模极为庞大。如果我们能够打造一款优秀的产品，即使只能够占领一部分市场，那么，我们也会变成一家非常成功的公司。
然而，公司处在哪个市场中并不是由自己的看法来决定，而是由“用户认为你是一家什么公司”来决定，而RethinkDB 的用户显然认为我们是一家提供开源开发工具的公司，因为那就是我们的实质。不幸的是，开源开发工具市场是公司可能会倒闭的“最糟糕的市场”。目前，成千上万的用户都在使用 RethinkDB ，而且通常是在业务环境中使用，但是大部分都不愿意为产品的终身使用权支付哪怕超出一杯星巴克咖啡的价格（也就是说，用户并不愿意付钱）。
但这不是说，因为产品太好了，已经不需要大家付钱来支持发展了，亦或是开发人员没有控制好预算，亦或者是资本市场的失败。答案或许可以用基本的微观经济学原理来解释：开发者们都喜欢建造开发工具，而且这些工具通常是免费的。因此尽管存在庞大的市场需求，而且供应量也非常庞大，进而就促进了备选开发者工具数量的增长，然后导致价格的不断下降，以致接近于零。
如果想了解这个模式，我们可以看一下 MongoDB（估值约为16亿美元，拥有约700名员工）和 Docker（估值约为10亿美元，拥有约300名员工）。这两家公司都在各自所在的市场拥有完全的主导权。有两条关于私营发展阶段的科技公司的经验法则：估值是年收入的10倍，平均每个员工的年收入是20万美元。这就意味着，MongoDB的年收入是1.4-1.6亿美元，Docker的年收入是6千万到1亿美元之间。虽然这些数字看起来还不错，但是对比一些非开发者工具市场中的 B2B 企业，像 SalesForce、Palantir，还有 Box（虽然面临着激烈的市场竞争），MongoDB 和 Docker 的收入在他们面前就显得有点 “微不足道”。
当然，市场上很多的成功的大企业发展也不是一帆风顺的，即使拥有良好的合作伙伴、优秀的分销策略和很多大客户资源的成熟企业尚且面临着发展的问题，处于萌芽阶段的创业公司的处境是怎样的呢？
对 RethinkDB 来说，这还意味着难以解决的“客户获取漏斗”模型 。如果说在机会众多的 B2B 市场，100条销售线索能转化成10个商机，最终实现1个订单的话，那么对开发工具创业公司来说，这些数字都要乘以10。你能得到大量的优质潜在客户很多用户愿意下载你的产品，跟你亲切的进行交流，但是你需要消耗多得离谱的线索，才能最终拿下一个订单。这就带来了灾难性的“多米诺骨牌效应” 。整个团队士气受挫，并且很难吸引投资，也很难请到顶尖的技术人才。接下来这种情况会不断恶化，进一步限制你的资源，让你无法对产品和分配进行充足的投资。创业公司存在生死危机，而初期的分销策略几乎注定了，你最终将走向灭亡。
错误的优秀衡量标准
诚然，市场环境不好，但是其他的开发工具公司依然还是卖了很多产品，为什么 RethinkDB 还是没有做到呢？
虽然，虽然我们无法左右市场动态（除非我们转行换业），但是，产品决策完全可以由我们自己掌握，所以我们想打造一款优雅、耐用而且好看的产品，因此我们按照以下标准进行了产品优化：
准确性：我们做出了非常严格的保证，并且认真贯彻执行； 界面的简洁性：我们承担了安装过程中最复杂的工作，这样使用我们的应用的开发人员就免去了很多麻烦； 一致性：从查询语言、客户端驱动、集群配置、使用文档，以及首页的营销文案，我们都做到了尽可能的一致性。
这些权衡条件是不是看起来眼熟？那是因为它们直接来自那篇《更坏就是更好》的文章。但是，实践结果表明，对大部分用户来说，准确性、简介的界面性和一致性都是错误的优秀衡量标准[5]。其实，很多用户想要的是下面这些效果：
及时出现：他们希望产品在他们需要的时候已经存在，而不是三年之后才上线； 速度明显：人们希望RethinkDB 在他们尝试的任务量中表现迅速，而不是我们建议的“真实世界”的任务量。举个例子，他们会写一些脚本，来测试在不用读回的情况下，插入成千上万个文档需要多长时间。MongoDB 在这个层面表现优异，而我们却在徒劳地试图教育整个市场； 客户案例：我们打算打造一个良好的数据库系统，而用户想要的却是一种完成 X 任务的好方法（例如，存储来自 hapi 的 JSON 文档的好方法，存储和分析日志的好方法，或者生产报告的好方法等等）
我们并不是没有尝试过加快产品发布，提升 RethinkDB 的速度，并且搭建与之相关的生态系统，来轻松完成现有的工作，我们真的努力了。但是一个正确、简洁、一致的软件需要花费很多时间来打造。这就让我们比市场落后了三年的时间。当我们觉得 RethinkDB 满足我们的设计目标，我们足够自信地向别人推荐使用它时，几乎所有人都在问：“RethinkDB 跟 MongoDB 有什么区别？”我们努力解释为什么正确性、简洁性和一致性很重要，但是最终发现，这些并不是大部分用户在意的优秀衡量标准。
坦白来讲，这点很伤人。我们真的很受伤，我们很难理解为什么人们会选择一个那样的系统：几乎没有它本应实现的功能（存储数据）；带着一个 kernel lock；随机抛出错误；执行单节点功能，却在你选择 shard 时停止运行；作为产品的核心功能之一，sharding系统几乎不能用；基本没有正确性保证，并且展示出来的界面五花八门，毫无一致性可言。
每次 MongoDB 发布新产品时，人们都会祝贺他们做出的改进。我心里却感到怨恨。他们宣布解决了 BKL 的问题，但是实际上他们把粒度级别从数据库降到了 collection。他们宣布增加了新的操作，但是却不是一个与系统各部分匹配的组合式界面，而是简单地加了个一次性指令。他们对 sharding 进行了改进，但是显然他们并不愿意或者没有能力实现最基本的数据一致性保证。
但是随着时间的流逝，我学会了欣赏“群众的智慧” 。MongoDB 在人们最需要的时候把普通的开发人员变成了“大英雄” ，而不是让他们等待多年。它加快了数据存储的速度，而且帮助人们加快了产品发布的速度，而且 MongoDB 也在不断发展。他们解决了一个又一个基础架构的问题，现在它已经变成一个非常优秀的产品。它也许不像我们所期待的那样好看，但是它完成了任务，而且完成得很好。
2014年中期，我们显然已经在这场竞争中落败，于是我们努力与 MongoDB 区别开来。我们发现了一种增加实时推送[6]的好方法，期望这能够让开发人员打造以前无法实现的新一代应用。但是那并不够。我们忽然发现自己还在跟 Meteor 和 Firebase 在竞争，在我们想到这个方法之前，他们已经在实时问题处理上投入了多年的时间和努力。这意味着，我们又比市场晚了三年，然后再一次在竞争中落败。
最后的一根稻草：云 有些人建议我们开发一款云产品。实际上，我们的确做了一款，因此接下来我要讲的问题，也很有意思。
如果一家小公司要想打造一款云服务，那么其中一个非常突出问题，就是这种模式符合一个常见的创业失败模式精力分散。开发、分发和运营一款可靠的多用户云服务真的很难。它需要非同一般的专业技能和资源，因此如果你走上这条路，你就会发现自己似乎同时在运营两个创业公司。但是当时我们面临着已经存在的威胁，而且很快就将走投无路时，我们还是不管不顾地尝试了一把，假设现在我们已经顺利完成了。
我们的推理过程是这样的：数据库云产品有三种选择：主机托管、数据库即服务（DBaaS）、增值平台即服务（PaaS）。我们再用前面用过的经验法则，平均每个员工的年收入为20万美元，来算一下：
所以这些市场都很小，比数据库市场本身还要小。但是会不会其中一个比另外两个选项要好一些呢？主机托管本质上就是在AWS 上替人工运行数据库。你也可以在AWS上自行设置数据库。这很痛苦，不过倒也没那么难。因此主机托管服务的定价有个上限。考虑到 Compose.io 和 mLab 提供的 MongoDB 的用户量比我们高一两个数量级，我们推断，推出主机托管并不会引起市场注意。
数据库即服务比主机托管更复杂，DBaaS 完全从用户那里接手了抽象节点管理。你只需要运行你的查询，系统就会处理。你不必了解系统内部运行多少个节点。这个业务富有挑战性，一方面是因为 DBaaS 公司不得不跟大公司竞争（例如 Dynamo DB 和 Document DB），一方面是因为在有众多备选的情况下，客户并不情愿把数据管理工作完全交给一个创业公司来做（你知道有哪家公司在用创业公司的 DBaaS 产品吗？因此 DBaaS 这个选项也被排除了）
最后一个选项是打造增值平台即服务。我们以为这个方面有希望，因为我们拥有巨大的技术优势。Firebase 和 Meteor 需要基于 MongoDB 打造应用级的实时逻辑，这从根本上限制了实时查询能力和性能表现。与之相反，我们实现了自上而下的全栈式控制，因此我们的产品相比以上两者会具有显著优势。
因此我们打造了 Horizon，并且开始打造 Horizon 云，这样用户就可以部署和调整 RethinkDB/Horizon 应用。一个小创业团队同时进行三个大项目的挑战（RethinkDB，Horizon，以及 Horizon Cloud）最终让我们尝到了「 恶果」。在发布云产品之前，我们的资金就用完了。不过工程师团队还是很了不起的，他们只差一点点就能够完成了。
最根本的问题是什么？ 我们还可以再做一层根源分析。为什么我们选择了一个糟糕的市场，而且按照错误的标准进行了产品优化呢？
在我小时候，我想自己做一个收音机。我用胶合板做了一个盒子，往里放了一些废金属，然后给盒子连上了电源线。我家有一些电子学的书，但是我以为我不需要它们我坚定地认为，我自己能搞定。最终我的确做出了一个能用的收音机，但是数年之后，我才终于意识到，其实，我还是需要学一些基本电子学知识。
早期的 RethinkDB 是类似的情况。我们并没有市场和产品方面的直觉，因此我们就简单走一下过场，创办了一家公司，却并没有真正理解我们在做什么。而且我们还抱有极大的乐观主义倾向。就像医生明明知道医药公司的礼物会给他们开药方时带来一定的影响，却深信自己并不会受到这种效应的影响一样，我们相信我们也不会受到企业经营的经济和数学规律的影响。当然，这些经济和数学规律最终让我们尝到了恶果。但是，我们当时能做些什么来避免这些错误吗？就像我小时候尝试做收音机一样。其实，我们没有什么能做的，因为我们能力不足，却不自知，而且经过好几年时间，我们才意识到这个问题，为时已晚。
一些人指出，如果我们当时能组建一个有经验的面向市场的团队，我们就能做得更好。这句话100%正确，但是我们的自我发展与公司需求并不一致。最初我们并不知道我们需要面向市场的专业人才，因此就没有在初创团队中招募这样的人才，顺便提一句，辨别缺乏强大的商业直觉的优秀商务人士，就跟辨别缺乏强大的工程直觉的优秀工程师一样难。等到我们建造出符合现实的心理模型时，我们才发现资金短缺，身处一个“槽糕”的市场，身边遍布强有力的竞争对手，而且我们的产品比市场落后了三年的时间。在那个时候，即使是世界上最优秀的市场团队也救不了我们了。
写在最后 相信很多人对开发者工具市场怀有非常强烈的感情。因为工程师们热爱打造好用的开发工具，因此他们极其希望开发工具公司能够繁荣发展。我也不愿意贬低整个市场，一方面是因为我不想因为单方面的经验就一概而论，另一方面是因为我不想说“不可能”，市场上就是存在很多特例，像 GitHub、MongoDB 和 Docker 都发展成了大企业，包括 GitLab 和 Unity 发展得也不错。
如果你真的打算创办开发工具公司，我希望你能够谨慎行事。市场上有很多好的替代产品，用户期望很高，产品价格却很低。你需要深入思考：你能给用户带来的价值是什么。请记住一点想让世界以某种方式运行是绝对行不通的。
2009年，我们在YCombinator 演示会上向一群投资者推介 RethinkDB 的早期构想（当时我们还没有软件）。我们的推介最后提出了三个要点。“如果你只记住了RethinkDB 的三点内容”我们说。“记住这三点” 这个办法非常奏效。人们没有记住这次推介会的其他内容，但是他们的确记住了最后的三点。
现在我给你留下要记住的三点内容。如果你能记住这篇文章，记住这些就够了： 1. 选择大市场，针对特定用户； 2. 认清团队缺乏的人才，然后拼命找到这样的人才； 3. 认真阅读《经济学人》，这样你们会进步得更快。 爱分析是一家专注于创新企业研究和评价的互联网投研平台。爱分析以企业价值为研究内核，以独特的产品形态，对创新领域和标杆企业长期跟踪调研，服务于企业决策者、从业者及投资者用户群体。关注爱分析公众号ifenxicom，及时获取重要信息。
新金融 |
注册
登录
