抱怨驅動開發
如果我去年沒怎么發博客的話，是因為我們一直忙著完成我談到過的“文明用語建設工具包(civilized discourse construction kit)”這件事。
（是的，實際上這就是公司的名字。這就是你讓我來取名字的下場。彈珠機，人，有啥區別呢？我已經跟Bill Budge道歉過啦）
所以如果你像我的投資人那樣，好奇為什么這個過程用了整整一年，我就應該解釋一下我是怎么完成事情的，或者至少解釋下我們是怎么完成Stack Overflow，Stack Exchange和現在的Discourse的：
對你所在領域中的每件事做足夠詳細的調研。成功的：他們現在做錯了什么？失敗的：他們有做對的地方嗎？沒有人應該比你更了解你所在領域的歷史。你要有一個有道理的故事，你相信它，并且更重要的是，你能讓別人相信它。
根據調研，組建一個團隊并完成能做些有價值工作的最簡化可實行產品(minimum viable product, MVP) 。如果你需要創始資金，是去爭取的時候啦，所以我希望你很擅長第一步中的工作， 再有些名氣，最好還已經很成功，否則你就完蛋了。
讓你和你的團隊開始沒日沒夜地使用最簡化可實行產品。這遠大于單純的軟件開發：這就是你的生活。如果你不活在你開發的軟件中，每天，天天，一整天。。。事情就會不可避免地在每個參與者淚流滿面中收場。說實話，如果我還要給你解釋的話，你猜怎么著？你完蛋了。
開展簡單的內測，從你那些“特別的網絡朋友們”中收集對你已完成產品的反饋。我知道你是這樣想的：朋友！該死！我早知道這些家伙遲早會派 上用場！ 不管這些反饋有多蠢，開明地聽取他們的意見。找出并修復每個出現的主要問題。你的產品會仍然很糟糕，但是會糟糕得少那么一丁點兒，你也會比不做這些工作完 蛋得少那么一丁點兒。（這就是我們商務專家說的“競爭優勢”。查查看。）
迅速地公開發布。這很糟糕，但不管怎樣你都要交付它。不要搞砸了發布的組織工作。你知道我在說啥，因為你見過那些差的發布會。不要成為那些公司，不要成為那些團隊。沒關系，下一步你有的是時間堂而皇之地搞砸所有事。
嘿，記得那些依據第一步痛苦詳細調研得到的好點子嗎？看樣子一旦你把它們放在現實中真實誠實的用戶的面前，結果它們全部。。完全。。錯了。接下來的一年你什么都不做，就修復你白癡般搞砸的事和愚蠢的錯誤吧。
？？？
利潤！
我從沒說過這是個開發軟件的好計劃，但是至少這是一個計劃。
這些步驟中的每個都值得花一篇博客來說明，但是今天我只專注第六步，因為在我看來這是整個所謂“計劃”中最關鍵的部分。我把這個階段叫做“抱怨驅動的開發”:
盡你可能讓更多的用戶使用你的軟件。
聽取他們抱怨的所有事情。這……可能很多。
找出并修復人們一直不斷抱怨的前3項問題。
再來一遍。
</ul>
</ul>
我們當前有一點不公平的優勢是因為Discourse是一個討論軟件。我們就在Discourse上主持討論關于Discourse的問題。但這也是我們最初為什么要開發一個開源的討論平臺–我深信，真正聽取你用的意見對你的業務至關重要。
假設你有辦法聽取你用戶的意見，抱怨驅動開發也沒那么困難。在你深入進展到一個多年計劃之前，你只要處理來用戶的相當明顯、很容易修復的抱怨。你只要面向他們傾聽就行。正如Steve Krug在《Don’t Make Me Think | 點石成金》中說的：
你沒必要找到所有問題，實際上你測試的任何東西，你永遠也找不到所有的問題。并且因為如下事實，即使你找到了也沒什么用：
你半天發現的問題，比你一個月修復的都多。
相對于你有資源去修復的問題，你總是能找到更多。所以重要的是你應該專注于修復最嚴重的問題。3個用戶就很可能遇到很多與你測試任務相關的最嚴重的問題。
舉個例子，我們發布Discourse的一個需求是所有標題和正文應該大于某個最小字符長度，因為我們認為特別短的帖子，特別是標題，不利于實際的交流。原則上講，對我們來說這是一個重要的默認設置，因為它與我們核心任務強烈相關：開發一個軟件提升因特網上有意義的交流。
不幸地是，用戶討厭它：
我覺得它特別的討厭，它沒有標志你必須輸入多少字符。你只有“回復”按鈕灰或不灰，并且不是所有用戶一開始都意識到它是灰的。即使這樣你點擊“回復”按鈕，如果你的帖子大多數是空白，它也可能彈回給你。它糟糕透了。
這是我們早期收到的反饋中持續最強的地方之一。因此發布后7天內，我們很快地在編輯器的右下角添加了一個實時字符數目。
我覺得這會有用。但不是，稱我們對標題和正文長度的默認限制為糟糕、極差、繁瑣的抱怨像潮水一樣。所以我們試驗用紅色的邊框或者在字段上添加紅色的背景，讓這些要求更清楚。
我們實施了上面的和更多的改動。抱怨一點也沒少。現在是配置的設置，如果你想在你的社區中讓標題和正文的最小長度為1的話，可以在瀏覽器中花大概15s來設置。坦白來說，我開始特別厭煩聽到關于這個設置的所有抱怨。
所以我們最后實施了“核”選項：當字段失去焦點的時候，立即彈出錯誤對話框。
自從這次改動，我再也沒聽到一個字抱怨我們正文和標題的默認字符長度限制的糟糕、復雜。一個字也沒有。
這就是在發布會后我們去年的每天、每周都一直在做的事情。我們用了整整一年的抱怨驅動的開發來讓軟件更有價值。即使我們現在謹慎地接收用戶，我們仍在每天進行抱怨驅動的開發，只不過也許對于付錢給我們的用戶的權重更大些。
從你的社區得到反饋確實是件麻煩的工作，并且你得到的90%的反饋會因為各種各樣的原因很糟糕。你很容易幻想一個英雄般的專家從天而降并且神奇地告訴你正確答案。好吧，希望你白日夢成真。我見過的唯一有用的辦法就是深入實踐，和你的用戶站在同一視角，和他們交流并且發展關系。這才是你找出那稀少10%精彩的、具有變革意義的社區反饋的辦法，這才是你構建一個關注你所做事情的社區的辦法 — 足夠認真地真正聽取他們的意見，并且改動他們關心的地方。
原文鏈接： Jeff Atwood 翻譯： 伯樂在線 - Five譯文鏈接： http://blog.jobbole.com/64630/