抱怨驱动开发_最新动态_新闻资讯_程序员俱乐部

　　英文原文：Complaint-Driven Development

　　如果我去年没怎么发博客的话，是因为我们一直忙着完成我谈到过的“文明用语建设工具包(civilized discourse construction kit)”这件事。

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

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

1. 对你所在领域中的每件事做足够详细的调研。成功的：他们现在做错了什么？失败的：他们有做对的地方吗？没有人应该比你更了解你所在领域的历史。你要有一个有道理的故事，你相信它，并且更重要的是，你能让别人相信它。
2. 根据调研，组建一个团队并完成能做些有价值工作的最简化可实行产品(minimum viable product, MVP) 。如果你需要创始资金，是去争取的时候啦，所以我希望你很擅长第一步中的工作， 再有些名气，最好还已经很成功，否则你就完蛋了。
3. 让你和你的团队开始没日没夜地使用最简化可实行产品。这远大于单纯的软件开发：这就是你的生活。如果你不活在你开发的软件中，每天，天天，一整天...事情就会不可避免地在每个参与者泪流满面中收场。说实话，如果我还要给你解释的话，你猜怎么着？你完蛋了。
4. 开展简单的内测，从你那些“特别的网络朋友们”中收集对你已完成产品的反馈。我知道你是这样想的：朋友！该死！我早知道这些家伙迟早会派上用场！不管这些反馈有多蠢，开明地听取他们的意见。找出并修复每个出现的主要问题。你的产品会仍然很糟糕，但是会糟糕得少那么一丁点儿，你也会比不做这些工作完蛋得少那么一丁点儿。（这就是我们商务专家说的“竞争优势”。查查看。）
5. 迅速地公开发布。这很糟糕，但不管怎样你都要交付它。不要搞砸了发布的组织工作。你知道我在说啥，因为你见过那些差的发布会。不要成为那些公司，不要成为那些团队。没关系，下一步你有的是时间堂而皇之地搞砸所有事。
6. 嘿，记得那些依据第一步痛苦详细调研得到的好点子吗？看样子一旦你把它们放在现实中真实诚实的用户的面前，结果它们全部...完全...错了。接下来的一年你什么都不做，就修复你白痴般搞砸的事和愚蠢的错误吧。
7. ？？？
8. 利润！

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

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

• 尽你可能让更多的用户使用你的软件。
• 听取他们抱怨的所有事情。这……可能很多。
• 找出并修复人们一直不断抱怨的前 3 项问题。
• 再来一遍。

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

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

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

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

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

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

　　不幸地是，用户讨厌它：

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

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

　　我觉得这会有用。但不是，称我们对标题和正文长度的默认限制为糟糕、极差、繁琐的抱怨像潮水一样。所以我们试验用红色的边框或者在字段上添加红色的背景，让这些要求更清楚。

　　我们实施了上面的和更多的改动。抱怨一点也没少。现在是配置的设置，如果你想在你的社区中让标题和正文的最小长度为 1 的话，可以在浏览器中花大概 15s 来设置。坦白来说，我开始特别厌烦听到关于这个设置的所有抱怨。

　　所以我们最后实施了“核”选项：当字段失去焦点的时候，立即弹出错误对话框。

　　自从这次改动，我再也没听到一个字抱怨我们正文和标题的默认字符长度限制的糟糕、复杂。一个字也没有。

　　这就是在发布会后我们去年的每天、每周都一直在做的事情。我们用了整整一年的抱怨驱动的开发来让软件更有价值。即使我们现在谨慎地接收用户，我们仍在每天进行抱怨驱动的开发，只不过也许对于付钱给我们的用户的权重更大些。

　　从你的社区得到反馈确实是件麻烦的工作，并且你得到的 90% 的反馈会因为各种各样的原因很糟糕。你很容易幻想一个英雄般的专家从天而降并且神奇地告诉你正确答案。好吧，希望你白日梦成真。我见过的唯一有用的办法就是深入实践，和你的用户站在同一视角，和他们交流并且发展关系。这才是你找出那稀少 10% 精彩的、具有变革意义的社区反馈的办法，这才是你构建一个关注你所做事情的社区的办法 — 足够认真地真正听取他们的意见，并且改动他们关心的地方。

　　翻译： 伯乐在线 - Five

　　译文链接： http://blog.jobbole.com/64630/