倾听社区的声音，但别被他们牵着鼻子走

原文作者：Jeff Atwood

作者在Twitter上发的一条短讯：

“我希望我们行业里有更多的人先去尝试建立社区，然后再做产品，就像photomatt和WordPress。”

11:28 PM –2012-5-30

译者注：photomatt.net是由Matt Mullenweg创办的一个分享图片的在线社区。（现在这个网站已经自动重定向到ma.tt。）Matt于2003年创建了WordPress——一种使用PHP语言和MySQL数据库开发的开源、免费的博客引擎。目前已经有超过16%的网站在使用WordPress。

大家都知道，面试官是多么热衷于问这样的问题，“你最大的弱点是什么？”“你曾经犯过最大的错误是什么？”这些问题听起来可能都是公式化的，甚至都是些陈词滥调，但是你在回答的时候可要小心了：它们貌似无足轻重，其实不然！

如果有人问我，“在创办Stack Overflow网站的过程中你犯过最大的错误什么”，我会很坦然，因为我不用费尽心思地去寻找答案。我可以很诚实地告诉大家，我在开发Stack Overflow的第一天就犯了个天大的、非常荒唐的错误，而且我还固执地坚持了整整9个月，完全不顾社区里此起彼伏的抗议。我越陷越深，甚至还写了一篇长长的博客去驳斥。

长久以来，我一直有一种很可怕的“搏击俱乐部”式的观念：“Stack Overflow网站的第一条规则，就是你别对Stack Overflow说三道四！”毕竟，大家上这个网站来是为了找到志同道合的人一起学习编程，而不是讨论一个做得很傻的网站。是这样吗？

译者注：《搏击俱乐部》（《Fight Club》）是一部美国电影，改编自恰克·帕拉尼克1996年的同名小说，由二十世纪福克斯电影制片公司发行。故事讲的是，杰克（一个充满中年危机意识、非常憎恨自己的生活的人）偶然遇到了卖肥皂的商人泰勒，两人因缘际会成为了好友，并创建了“搏击俱乐部”：一个让彼此不戴护具而互殴的聚会，旨在发泄情绪……

我没有意识到大家对“元”（meta）的需要。

所谓“元”，就是一个大家讨论自身所处之地的地方。听起来很费解吧，但是其含义值得我们好好想想。“元”是给那些深切关注社区、也愿意更进一步做出贡献、组织起来并费尽心思去研究怎样维持和管理社区的人的。所以，我很懊悔！我当初的所作所为，实际上是在告诉那些热爱Stack Overflow的人们：“滚一边去！”

回想起来，我真是羞愧难当！

在社区的不断刺激之下，也在我反复的防守还击过程中，很庆幸，我最终醒悟了。尽管我们在一开始的测试阶段用了一个第三方的“元”站点，但在公测后的10个月，也就是2009年6月最终发布的时候，我们还是用了自己的域名：meta.stackoverflow。同样的错误绝不再犯第二次，在我们后来做Stack Exchange的时候就注意了——我们为每一个上线的Stack Exchange子网站从一开始就配备了一个“元”。我们现在知道了，“元”的参与是社区有序领导和治理的源泉，我们须培养它，也因此要加以密切的监控。

为了“赎罪”，我也成为了我们自己“元”的顶级用户。在过去的2年又7个月的时间里，我将自己埋身在成堆的bug、功能需求和各种讨论中，而支持所有这些的就是我们的“元”。从我的用户账号概况里可以看出，在那段时间里，我有901天都泡在“元”里，其实差不多也就是每天都在了！我以自己对“元”的参与度而感到骄傲，好比是得了一块勋章，而更重要的是，我认识到了我们应该围绕着用户开展工作。我们在Stack Exchange上所做的任何一件事都是特意公开的——这跟象牙塔式的开发模式完全是对立的。

这一路走过来，在开发社区软件和处理社区反馈方面，我学到了不少的经验和教训。现总结如下：

1．90%的社区反馈都是垃圾

让我们现在就承认吧！在这方面，“史特金定律”是不可能被任何人否定的，无论你是男人、女人、孩子，还是一个社区。“元”社区，我爱死你了；正因为如此，让我们彼此坦诚相待吧：你们提出的大部分反馈和功能需求，其实没有任何可操作性……需要的话，我可以说出一万条理由。

译者注：“史特金定律”（Sturgeon's Law）是科幻作家史特金提出的，其内容是：任何事物，其中90%都是垃圾。以社区网站的内容为例：在社区所有的作品中，90%以上的都是“垃圾”。因此要有能力去芜取菁。

且慢，别忽略了要点：这也意味着，有另外10%的社区反馈是非常棒的！假如你有毅力看上上百条帖子，我保证你会发现其中有10条的含金量很高，而就是它们能让你的网站得到明显的提升。做好准备吧，若想从一大堆社区反馈里挖掘出“宝石”，你需要花很多时间，而且这时间还不是一般的多！我坚信，每个社区总会有一些足够聪明的人来制造一定数量的“宝石”，他们常常让你喜出望外。

2．别抵挡不住诱惑而误入歧途

当你收到反馈和功能需求的时候，你应该立即把它们分成两大类：

我们需要给这辆轿车安上电动窗！

或者

我们需要给这辆轿车加个货车车厢！

显而易见，前者只是给轿车增加一个合理的配件，而后者试图改变车辆的基本特性。软件本身固有的“易于修改的特性”，使得增加功能变得很诱人，但这有时候无异于给轿车加上一个货车车厢。为什么不这么做呢？用户们会不断地反问你。货车多方便呀！真的是这样吗？

别掉进陷阱！牢记你当初的使命。轿车加货车的混合体对于很多人来说都很有吸引力，但是这很可怕，你会最终做出一辆像斯巴鲁Brat一样的车。除非你真的想要做出一辆货车来，否则，如果用户提出想要货车这样的功能，你最好大方地把他们带到附近的货车经销商那里，因为他们似乎来错了地方。

3．坦诚地说出你不想做的事

当看到bug跟踪系统里或反馈论坛里有成千上万条记录无人问津时，我总是很沮丧。这是社区疏于治理的信号，更为糟糕的是，它折射出了社区里一种信赖缺失的关系。这很常见，也很可悲。千万别搞成这样！

尽管很多时候来自社区的反馈是令人讨厌的，但我并不建议你把对他们的厌恶之情赤裸裸地表现出来。那样只会显得你很卑劣。但当你觉得他们提出的请求没有道理，或者你无法在一个合理的范畴内将它们实现的时候，请你不要羞于“礼貌地”拒绝他们。（当然，你应该总是保留将来改变主意的权力。）毫无疑问，被人拒绝是很伤心的，但被人忽略让人尤其心灰意冷。我非常非常坚定地相信，只要你对你的社区待之以诚，他们最终会因此而更加敬重你。

所有的关系都是基于诚实的。如果你不愿意诚实地对待你的社区，你凭什么要求他们来尊敬你呢？他们最终会离你而去……

4．倾听社区的声音，但别被他们牵着鼻子走

把“元”社区里的需求一股脑儿地吸收进你的软件或者网站中加以实现，这么做看起来很不错。“元”的出发点是倾听来自社区的声音，然后根据社区反馈采取相应的行动，对吗？遗憾的是，如果你过于直接地对社区反馈采取行动，那是非常危险的，它也是很多社区失败的原因。让我们一起来看看GitHub的联合创始人Tom Preston-Werner是怎么解释的吧：

我们来看一个这样的需求：“GitHub应该允许我用FTP的方式把我项目里的一个文档站点上传上去。”其实，这个客户真正想说的是：“我想要一个简单的方法来发布与我项目相关的内容。”只是他们早已经习惯了现有的东西，所以他们必然以他们熟悉的术语来表达他们的需求。我们本可以按照他们要求的那样，实现一个糟糕的基于FTP的解决方案。然而，经过我们深入研究之后，我们发现了问题的根本，最终的解决方案是：允许用户通过往账号里加一个Git仓库来实现内容发布。这种做法既满足了功能需求，又不失优雅，堪称完美。

译者注：Git是一个分布式的版本控制系统，最初由Linus Torvalds编写，用作Linux内核代码的管理。而GitHub可以托管各种Git库，并提供一个Web界面，使得操作更加简易。

社区反馈是美妙的，但它的作用绝不应该被夸大并滥用，它不能代替你去深刻反思你要做的东西以及你为什么要这样做。花点功夫去挖掘潜在的真正需求吧，然后制定出一个合理的产品路线图。

5．参与并支持你的社区

大概有一半的社区关系都不尽如人意，他们并不在恪守承诺地做着社区认为他们应该做的事情。即便这样，建议你还是要去积极参与社区，去倾听，去回应。当Stack Exchange的联合创始人回复你在“元”里的发帖时，即使他的回复不能完全达到你的期望，我希望你也能理解，他的行动足以证明了我们对社区的承诺，那就是我们始终跟社区在一起并肩作战。

不管你现在缺不缺钱用，你都应该热衷到“元”里的社区反馈或bug报告里挖掘出稀有的“宝石”。这些“宝石”能让你的网站或产品更加出色。你应该义无反顾地这么去做，以促成公众反馈的良性循环：“你所关心的就是我们所关注的，所有事情都在朝着一个好的方向持续得到改进。”

这就是社区的真谛！难道不是吗？