全文共2820字，预计学习时长8分钟

　　图源：unsplash

　　无代码是个非常宽泛的术语，这是一种点击式解决方案。我已经写了20多年代码了，说实在的，无代码并不是什么新鲜事。但如果说无代码现在很流行又太过轻描淡写了，就像在2016年时说比特币很流行，或者在2010年时说移动应用很流行一样。

　　这一趋势是类似比特币的发展趋势还是向着移动应用发展的方向演变？在我们搞清楚这个问题之后，可以说现在是无代码的“蛙跳”时刻，因为无代码的用例已经从整合软件功能发展到允许创建整个软件应用程序。

　　然而，在这篇文章中，我不想把讨论“无代码”局限于构建和部署应用程序，我想谈谈如何不写太多代码就创建一个完整的公司和产品。

　　无代码解决方案有三大类，你可以混合使用、相互搭配。当然，也有异常值类型和用例，但这些是最普遍的。让我们先从解决方案类型开始。

　　第1种：Widget builder——这是提供基于云的功能片段的简单服务。例如，如果你需要一个表单来输入数据，便可以使用任意数量的服务来创建一个简单的小部件，用于在云中收集和托管数据。

　　第2种：Webhook builder——这就是Zapier所做的。它是一个用户界面，能访问应用程序中的webhook，从而让应用程序之间进行交流。它就像一个API，但是更简单。而且许多软件产品甚至提供了内置访问，以进入自己的webhook。

　　例如，Stripe有一个webhook，你可以将其配置在自己的Stripe帐户。这样每当有人完成交易时，就会有一个消息发送到你的Slack帐户。整个过程不需要代码就可以实现。

　　第3种：Application builder：从字面上理解它即可，你可以使用它拖拽一个完整的web或移动应用。再次重申，这不是一个新概念，但是如今的无代码解决方案需要以较为高级的知识为基础来提供更多的功能。

　　接下来，我们谈谈用例。

　　图源：unsplash

　　九个月前，我开始创建Teaching Startup。在开始一个月之后，我决定不写任何代码来创建它。我得重申一遍，我会写代码，但是我还有很多别的事情要做。这就是我选择无代码方式建立公司的理由。

　　在整个公司中，有些事情可以人工完成，但这会耗费大量时间；有些事情可以通过自动化完成，这需要投入大量资金来启动。

　　这些功能存在于公司的各个方面，从边缘业务到核心业务。例如，我的产品中含有付费电子邮件，所以我需要一个有各种定制选项的批量电子邮件器，我还需要信用卡处理器。

　　当我在2010年创立ExitEvent时，我的需求几乎没有改变。所以我着手开始尝试，花了好几个星期的时间，结果有很多地方都出了故障。此外，每次我需要做一个小改动，我不仅需要完成整个改动，还要进行测试，这太耗费时间了。

　　另一方面，我本可以使用第三方组合服务来满足对这两个功能的需求，但这些组合服务价格高昂，功能有限。更为重要的是，将这些服务整合到我的产品框架中所需的成本将不仅提高了前期成本，还会变成一项持续开支。

　　于是，我选择了一个提供全套服务的电子邮件提供商和一个提供全套服务的信用卡处理器，随后我使用Zapier和其他几个小工具将它们绑定在一起，并将它们整合到我的产品框架中。这就能按需满足我的用例需求，而这是组合服务提供商无法满足的，而且费用比全套服务提供商便宜60%。

　　电子邮件服务提供商可以提供非常优质的电子邮件服务，信用卡处理器可以非常出色地处理信用卡，Zapier确保两者之间信息的流通。它们都比“全套”服务提供商做得更好，也比我在几周内写的任何代码都更高效。

　　现在确实存在一些限制。但问题在于，这些限制迫使我不再考虑我想要做的所有选择、定价和包装，只是为了证明客户会为产品付费。

　　我花了一个月的时间才决定创建一个无代码公司，原因在于我最初只打算以无代码的形式创建Minimum ViableProduct。MVP建立起来后，我意识到如果我替换了无代码解决方案，我也就替换了本不需要替换的轮子。

　　无代码解决方案是围绕MVP建立基础设施并确定产品可行性的完美方式。如果你不必考虑核心产品及与产品相关的组件，包括其他非核心产品功能整合的可行性，那么你能花更多时间构建更好的核心产品。

　　MVP的目标是测试产品核心功能的可行性。问题在于，要完成这个测试，这台营销、销售、实现和维护产品的机器必须工作。如果机器的任意组件出现故障，你在测试中就会产生噪音。

　　此外，这台机器的制造成本很高，所以为什么要浪费数千美元来为一款没有在市场上经过可行性测试的产品构建完美的基础设施呢?

　　图源：unsplash

　　接下来要做的是将是构建所有我想要的额外功能，而不仅仅是处理电子邮件的功能，这个功能在我补充的众多额外功能中已经不值一提。所有这些都能靠写代码完成，但我需要花时间为客户创造更多的价值，这就是构建无代码产品的理由。

　　我的产品路线图上有一大堆功能，都是我迫不及待地想要去实现的。我只是不知道我的客户是否需要这样的功能。如果我能试试，并证明这个功能的可行性，就像我证明了自己产品的可行性一样，又会发生什么呢?

　　很长一段时间以来，现有企业一直在使用无代码解决方案，用于为其业务用户提供自定义功能，并且不会增加技术债务。现在的无代码应用程序构建器解决方案让我们从等式中去掉中间层，并直接迅速地向客户提供相同类型的关键功能，且不会消耗太多的费用或技术债务。

　　有的时候确实会存在一些限制。在某些时候，这个功能确实可能需要用“真正的”解决方案来替代。

　　但这些都是九个月前我在构建MVP的时候提到的。我为自己节省了一大笔钱和时间，只是需要延迟更换我的无代码组件，或者也许永远也不会换它。我把这些钱和时间花在构建一个更好的核心产品上。

　　我经常被问到这样一个问题：任何人都可以创建并使用一种产品，这样的无代码趋势是否会助长大量垃圾产品的出现?当然会有。现在有垃圾产品是由终身程序员和受到高度吹捧的IT部门开发的吗?这会导致产品过载吗?这个可能不会。

　　市场上肯定有越来越多无法存活的产品。但作为消费者，我们购买的不是市场，而是产品。允许使用创新的思路提供不同的解决方案来解决旧的问题，这样做利远大于弊。

　　这也同时证明了，无代码不仅仅是一种趋势。

　　留言点赞关注

　　我们一起分享AI学习与发展的干货