(是的，实际上这就是公司的名字。这就是你让我来取名字的下场。弹珠机，人，有啥区别呢?我已经跟Bill Budge道歉过啦)

　　所以如果你像我的投资人那样，好奇为什么这个过程用了整整一年，我就应该解释一下我是怎么完成事情的，或者至少解释下我们是怎么完成Stack Overflow，Stack Exchange和现在的Discourse的：

　　对你所在领域中的每件事做足够详细的调研。成功的：他们现在做错了什么?失败的：他们有做对的地方吗?没有人应该比你更了解你所在领域的历史。你要有一个有道理的故事，你相信它，并且更重要的是，你能让别人相信它。

　　根据调研，组建一个团队并完成能做些有价值工作的最简化可实行产品(minimum viable product, MVP) 。如果你需要创始资金，是去争取的时候啦，所以我希望你很擅长第一步中的工作， 再有些名气，最好还已经很成功，否则你就完蛋了。

　　让你和你的团队开始没日没夜地使用最简化可实行产品。这远大于单纯的软件开发：这就是你的生活。如果你不活在你开发的软件中，每天，天天，一整天。。。事情就会不可避免地在每个参与者泪流满面中收场。说实话，如果我还要给你解释的话，你猜怎么着?你完蛋了。

　　开展简单的内测，从你那些“特别的网络朋友们”中收集对你已完成产品的反馈。我知道你是这样想的：朋友!该死!我早知道这些家伙迟早会派上用场!不管这些反馈有多蠢，开明地听取他们的意见。找出并修复每个出现的主要问题。你的产品会仍然很糟糕，但是会糟糕得少那么一丁点儿，你也会比不做这些工作完蛋得少那么一丁点儿。(这就是我们商务专家说的“竞争优势”。查查看。)

　　迅速地公开发布。这很糟糕，但不管怎样你都要交付它。不要搞砸了发布的组织工作。你知道我在说啥，因为你见过那些差的发布会。不要成为那些公司，不要成为那些团队。没关系，下一步你有的是时间堂而皇之地搞砸所有事。

　　嘿，记得那些依据第一步痛苦详细调研得到的好点子吗?看样子一旦你把它们放在现实中真实诚实的用户的面前，结果它们全部。。完全。。错了。接下来的一年你什么都不做，就修复你白痴般搞砸的事和愚蠢的错误吧。

　　???

　　利润!

　　我从没说过这是个开发软件的好计划，但是至少这是一个计划。

　　这些步骤中的每个都值得花一篇博客来说明，但是今天我只专注第六步，因为在我看来这是整个所谓“计划”中最关键的部分。我把这个阶段叫做“抱怨驱动的开发”:

　　尽你可能让更多的用户使用你的软件。

　　听取他们抱怨的所有事情。这……可能很多。

　　找出并修复人们一直不断抱怨的前3项问题。

　　再来一遍。

　　我们当前有一点不公平的优势是因为Discourse是一个讨论软件。我们就在Discourse上主持讨论关于Discourse的问题。但这也是我们最初为什么要开发一个开源的讨论平台–我深信，真正听取你用的意见对你的业务至关重要。

　　假设你有办法听取你用户的意见，抱怨驱动开发也没那么困难。在你深入进展到一个多年计划之前，你只要处理来用户的相当明显、很容易修复的抱怨。你只要面向他们倾听就行。正如Steve Krug在《Don’t Make Me Think | 点石成金》中说的：

　　你没必要找到所有问题，实际上你测试的任何东西，你永远也找不到所有的问题。并且因为如下事实，即使你找到了也没什么用：

　　你半天发现的问题，比你一个月修复的都多。

　　相对于你有资源去修复的问题，你总是能找到更多。所以重要的是你应该专注于修复最严重的问题。3个用户就很可能遇到很多与你测试任务相关的最严重的问题。

　　举个例子，我们发布Discourse的一个需求是所有标题和正文应该大于某个最小字符长度，因为我们认为特别短的帖子，特别是标题，不利于实际的交流。原则上讲，对我们来说这是一个重要的默认设置，因为它与我们核心任务强烈相关：开发一个软件提升因特网上有意义的交流。

　　不幸地是，用户讨厌它：

　　我觉得它特别的讨厌，它没有标志你必须输入多少字符。你只有“回复”按钮灰或不灰，并且不是所有用户一开始都意识到它是灰的。即使这样你点击“回复”按钮，如果你的帖子大多数是空白，它也可能弹回给你。它糟糕透了。

　　这是我们早期收到的反馈中持续最强的地方之一。因此发布后7天内，我们很快地在编辑器的右下角添加了一个实时字符数目。