如果我去年沒怎麼發部落格的話，是因為我們一直忙著完成我談到過的“文明用語建設工具包(civilized discourse construction kit)”這件事。
（是的，實際上這就是公司的名字。這就是你讓我來取名字的下場。彈珠機，人，有啥區別呢？我已經跟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天內，我們很快地在編輯器的右下角新增了一個實時字元數目。
我覺得這會有用。但不是，稱我們對標題和正文長度的預設限制為糟糕、極差、繁瑣的抱怨像潮水一樣。所以我們試驗用紅色的邊框或者在欄位上新增紅色的背景，讓這些要求更清楚。
我們實施了上面的和更多的改動。抱怨一點也沒少。現在是配置的設定，如果你想在你的社群中讓標題和正文的最小長度為1的話，可以在瀏覽器中花大概15s來設定。坦白來說，我開始特別厭煩聽到關於這個設定的所有抱怨。
所以我們最後實施了“核”選項：當欄位失去焦點的時候，立即彈出錯誤對話方塊。
自從這次改動，我再也沒聽到一個字抱怨我們正文和標題的預設字元長度限制的糟糕、複雜。一個字也沒有。
這就是在釋出會後我們去年的每天、每週都一直在做的事情。我們用了整整一年的抱怨驅動的開發來讓軟體更有價值。即使我們現在謹慎地接收使用者，我們仍在每天進行抱怨驅動的開發，只不過也許對於付錢給我們的使用者的權重更大些。
從你的社群得到反饋確實是件麻煩的工作，並且你得到的90%的反饋會因為各種各樣的原因很糟糕。你很容易幻想一個英雄般的專家從天而降並且神奇地告訴你正確答案。好吧，希望你白日夢成真。我見過的唯一有用的辦法就是深入實踐，和你的使用者站在同一視角，和他們交流並且發展關係。這才是你找出那稀少10%精彩的、具有變革意義的社群反饋的辦法，這才是你構建一個關注你所做事情的社群的辦法 — 足夠認真地真正聽取他們的意見，並且改動他們關心的地方。