Indiehacker修炼手册.pdf【建设篇】

在上一篇中，我们探讨了如何为你的产品寻找创意，为了避免陷入无尽的头脑风暴和胡思乱想的循环，你需要尽快开始建设，产品推出得越快，就越快看到人们是否愿意使用它，客户如何使用它，以及希望看到建设什么新功能。如果不发布产品，很难了解客户想要什么，当然也有例外：苹果公司几乎不使用任何焦点小组或用户调研，按照乔布斯标准选择发布最好的产品。这也仅限苹果公司，再说我们也很难做到乔布斯那种境界。

1、短平快的建设方式

虽然十年前的产品开发周期一般很长，需要大量的规划才能做好，但现在我们可以在短短几天内从想法转变为MVP产品。

我们需要拥有价格低廉且易于设置的服务器（如VPS等），以及PaaS可以解决服务器设置的所有困难。像Linux这样的服务器操作系统已经变得相对简单，可以在网上轻松找到教程，Nginx可以让我们搭建一个基本的Web服务器，而不需要太多的配置。像Python、JavaScript、PHP及其框架如Django、Laravel等语言使得构建产品变得简单，无需从头开始。

我的观点是现在的互联网发展速度非常快，这个时代的用户需求也是瞬息万变的。现在一切都在快速变化，过去人们可能会使用一个产品几天或几周，现在只有几秒钟的时间去产生用户影响，否则就会关闭或卸载它，所以你必须快速行动以保持领先。我们这个时代的另一个特点是极简主义，用户接受了极简的界面和功能，只要一个产品能做好它所说的事情，功能上只做一件小事但做得非常好，就已经取得了相当大的成功。

快速开发推进产品的弊端

让产品快速发展的文化也有缺点，造成一些产品在发布时仍存在大量Bug，它们可能在所有的移动设备上都无法正常工作，也没有经过测试。有些产品在推出后的第一周运行得很好，但是开发者们之后就停止了维护，几个月后它们就会出现故障。当产品停止运行时，剩下的用户会感到烦恼，由于开发过程快速、粗糙，因此就出现这样的结果。

另一个缺点是你没有时间去精细化和处理细节，代码很可能变成一团糟，因为涉及的架构规划较少。但话说回来，你总是可以重写代码，对吧？至少你已经发布了，用户并不关心你的代码看起来如何。

完成比完美更重要

你快速发布的原因是为了避免因追求完美而产生的不作为，不光是从现在开始，以后也要避免追求完美，这适用于创业的所有阶段。完美主义是有害的，因为十次中有九次并不能改善任何事情，只会导致无所作为。

如果处于公司的初级阶段，你要尽快发布新产品。我认为在整个阶段，这样做都是有益的，因为用户喜欢新功能，他们喜欢测试新东西，他们其实对遇到错误还算能接受，他们也知道开发工作很有Bug。我的意思是，Gmail都处于测试版长达十年，只要他们能使用新的东西，只要错误得到修复，只要他们有途径反馈产品的错误且用户就能接受错误。我认为，尽快推出新产品是头等大事。

避免完美主义是你需要培养的一种技能，你要学会接受一切并非都完美无缺，并非所有事物都会完美无瑕、体验上乘的。也许你的网站会有错误的图片，错误的背景颜色，而且logo的颜色与页面其余部分的品牌文字样式不匹配，这些都不重要。这些问题总要在某个时候解决，但它们并不是优先考虑的事情，保障产品是可以使用的就行。对于那些优先级较低的事情，不要投入太多的精力去追求完美。你总会有时间稍后去完善事情，总能迭代和发展它，使其在以后变得更好。为什么不一步一步地完善它呢？做出小的改进。

当然这种做法也是有限度的，不要制造糟糕的产品。随着MVP的兴起，有越来越多的人开始发布外观糟糕、几乎无法正常使用的产品。MVP版产品应该运行得非常好，如果有一些小错误，那也没关系，但核心功能应该是可以使用的，它至少应该看起来还可以，否则只会让用户离开，用核心功能满足最核心的需求就好。

建设什么程度才是最小可行产品（MVP）？

最近看到的糟糕MVP正在引发一场反对精益产品开发趋势的运动，这是可以理解的。但精益或最小可行产品并不意味着它可以是糟糕的，它起码保证真正能够运行，用户必须能够使用它，虽然存在一些错误，但用户应该有反馈的入口（比如弹出聊天框、邮箱等）。你必须快速修复错误，否则随着产生错误越来越多会让用户感到烦恼，开发最小可行产品意味着它必须是可行的，这不是偷懒和做一些马马虎虎不能用的功能作为借口。所以这比较考验大家的工作平衡，开发一些强大功能的东西，可以是最小的，但一定要确保它能正常使用。

2、自己建设或开发外包

许多人问我，是否应该自己开发产品，还是将其外包给其他程序员，或者雇佣程序员为开发产品？

关于这个问题，我有一个相当激进的观点，这与大多数人的说法相悖，但我认为我是对的，因为时代在变化。

自己动手做 vs 雇人代开发

我认为，让他人为你开发产品可以让你走得很远，但问题在于，从长期来看，你的开发速度将无法与具备开发技能的Indie hacker相媲美。

举个例子：我的一天通常从醒来开始，然后洗澡，喝点咖啡，看看今天有谁通过邮件/Twitter反馈给我网站上有哪些错误（几乎每天都有人给我发送错误报告），我会看看能否立即修复。然后我发现网站上的其他不友好的功能，我会即时进行更改，所有这些通常只需要几分钟，这些只是每天的小迭代，但一年下来就像是300到1000次的小迭代，这些迭代就会累积起来发挥价值。

想象一下，如果你把所有这些都外包出去，可能需要向程序员提出1000次的修改要求。对我来说，一个小的迭代或者修复一个错误只需要几分钟，因为我可以自己搞定。但对你来说，每一次的迭代都需要向你的程序员发消息沟通，然后他必须在那一天是工作日才能修复它，可能还需要和他的团队开会讨论。所以，这可能需要几个小时，或者几天，甚至几周的时间。

再想象一下，如果我们有同一个网站，你和我相互竞争，在你给你的程序员进行消息沟通的时间里，我已经修复了5个错误并且在产品中增加了2个新功能。这种状态下，谁会赢？谁更快？一定不是你。

最后再想想你的客户，由于你的程序员正在休假，而客户已经被一个错误困扰了三天，回到我的产品已经修复了这个问题。

在早晨喝咖啡的时候，我只用了5分钟就解决了那个问题，你的客户会选择哪个产品？你的一直有问题的产品，还是我的正常运行的产品？

然而，并非所有事情都是那么美好的，长期来看你也无法独自完成所有事情。如果你已经证明了商业模式的可行性，那么最明智的做法就是不断重复它（通过扩大规模），雇佣更多人为你工作，你负责产品管理和运营，而不是花精力继续修复小问题。但这些不是这本书的主题，我们在谈论的是新产品开始，这种情况下，自己动手做总是优于外包。

自己动手做 vs 获得风险投资的团队

我已经看到无数的真实例子，那些获得风险投资的公司在建立庞大的开发和设计团队上花费大量资金，或者将同样的钱支付给外包的开发和设计机构。但有些例外是正确的（比如：滴滴打车），但大多数情况下，这一开始就会严重拖慢你的进度。

比...