如果我去年沒怎么發(fā)博客的話，是因?yàn)槲覀円恢泵χ瓿晌艺劦竭^的“文明用語建設(shè)工具包(civilized discourse construction kit)”這件事。

[[112300]]

（是的，實(shí)際上這就是公司的名字。這就是你讓我來取名字的下場。彈珠機(jī)，人，有啥區(qū)別呢？我已經(jīng)跟Bill Budge道歉過啦）

所以如果你像我的投資人那樣，好奇為什么這個過程用了整整一年，我就應(yīng)該解釋一下我是怎么完成事情的，或者至少解釋下我們是怎么完成Stack Overflow，Stack Exchange和現(xiàn)在的Discourse的：

1. 對你所在領(lǐng)域中的每件事做足夠詳細(xì)的調(diào)研。成功的：他們現(xiàn)在做錯了什么？失敗的：他們有做對的地方嗎？沒有人應(yīng)該比你更了解你所在領(lǐng)域的歷史。你要有一個有道理的故事，你相信它，并且更重要的是，你能讓別人相信它。
2. 根據(jù)調(diào)研，組建一個團(tuán)隊并完成能做些有價值工作的最簡化可實(shí)行產(chǎn)品(minimum viable product, MVP) 。如果你需要創(chuàng)始資金，是去爭取的時候啦，所以我希望你很擅長***步中的工作， 再有些名氣，***還已經(jīng)很成功，否則你就完蛋了。
3. 讓你和你的團(tuán)隊開始沒日沒夜地使用最簡化可實(shí)行產(chǎn)品。這遠(yuǎn)大于單純的軟件開發(fā)：這就是你的生活。如果你不活在你開發(fā)的軟件中，每天，天天，一整天。。。事情就會不可避免地在每個參與者淚流滿面中收場。說實(shí)話，如果我還要給你解釋的話，你猜怎么著？你完蛋了。
4. 開展簡單的內(nèi)測，從你那些“特別的網(wǎng)絡(luò)朋友們”中收集對你已完成產(chǎn)品的反饋。我知道你是這樣想的：朋友！該死！我早知道這些家伙遲早會派上用場！不管這些反饋有多蠢，開明地聽取他們的意見。找出并修復(fù)每個出現(xiàn)的主要問題。你的產(chǎn)品會仍然很糟糕，但是會糟糕得少那么一丁點(diǎn)兒，你也會比不做這些工作完蛋得少那么一丁點(diǎn)兒。（這就是我們商務(wù)專家說的“競爭優(yōu)勢”。查查看。）
5. 迅速地公開發(fā)布。這很糟糕，但不管怎樣你都要交付它。不要搞砸了發(fā)布的組織工作。你知道我在說啥，因?yàn)槟阋娺^那些差的發(fā)布會。不要成為那些公司，不要成為那些團(tuán)隊。沒關(guān)系，下一步你有的是時間堂而皇之地搞砸所有事。
6. 嘿，記得那些依據(jù)***步痛苦詳細(xì)調(diào)研得到的好點(diǎn)子嗎？看樣子一旦你把它們放在現(xiàn)實(shí)中真實(shí)誠實(shí)的用戶的面前，結(jié)果它們?nèi)俊！Ｍ耆！ｅe了。接下來的一年你什么都不做，就修復(fù)你白癡般搞砸的事和愚蠢的錯誤吧。
7. ？？？
8. 利潤！

我從沒說過這是個開發(fā)軟件的好計劃，但是至少這是一個計劃。

[[112301]]

這些步驟中的每個都值得花一篇博客來說明，但是今天我只專注第六步，因?yàn)樵谖铱磥磉@是整個所謂“計劃”中最關(guān)鍵的部分。我把這個階段叫做“抱怨驅(qū)動的開發(fā)”:

• 盡你可能讓更多的用戶使用你的軟件。
• 聽取他們抱怨的所有事情。這……可能很多。
• 找出并修復(fù)人們一直不斷抱怨的前3項問題。
• 再來一遍。 

我們當(dāng)前有一點(diǎn)不公平的優(yōu)勢是因?yàn)镈iscourse是一個討論軟件。我們就在Discourse上主持討論關(guān)于Discourse的問題。但這也是我們最初為什么要開發(fā)一個開源的討論平臺–我深信，真正聽取你用的意見對你的業(yè)務(wù)至關(guān)重要。

假設(shè)你有辦法聽取你用戶的意見，抱怨驅(qū)動開發(fā)也沒那么困難。在你深入進(jìn)展到一個多年計劃之前，你只要處理來用戶的相當(dāng)明顯、很容易修復(fù)的抱怨。你只要面向他們傾聽就行。正如Steve Krug在《Don’t Make Me Think | 點(diǎn)石成金》中說的：

你沒必要找到所有問題，實(shí)際上你測試的任何東西，你永遠(yuǎn)也找不到所有的問題。并且因?yàn)槿缦率聦?shí)，即使你找到了也沒什么用：

你半天發(fā)現(xiàn)的問題，比你一個月修復(fù)的都多。

相對于你有資源去修復(fù)的問題，你總是能找到更多。所以重要的是你應(yīng)該專注于修復(fù)最嚴(yán)重的問題。3個用戶就很可能遇到很多與你測試任務(wù)相關(guān)的最嚴(yán)重的問題。

舉個例子，我們發(fā)布Discourse的一個需求是所有標(biāo)題和正文應(yīng)該大于某個最小字符長度，因?yàn)槲覀冋J(rèn)為特別短的帖子，特別是標(biāo)題，不利于實(shí)際的交流。原則上講，對我們來說這是一個重要的默認(rèn)設(shè)置，因?yàn)樗c我們核心任務(wù)強(qiáng)烈相關(guān)：開發(fā)一個軟件提升因特網(wǎng)上有意義的交流。

不幸地是，用戶討厭它：

我覺得它特別的討厭，它沒有標(biāo)志你必須輸入多少字符。你只有“回復(fù)”按鈕灰或不灰，并且不是所有用戶一開始都意識到它是灰的。即使這樣你點(diǎn)擊“回復(fù)”按鈕，如果你的帖子大多數(shù)是空白，它也可能彈回給你。它糟糕透了。

這是我們早期收到的反饋中持續(xù)***的地方之一。因此發(fā)布后7天內(nèi)，我們很快地在編輯器的右下角添加了一個實(shí)時字符數(shù)目。

我覺得這會有用。但不是，稱我們對標(biāo)題和正文長度的默認(rèn)限制為糟糕、極差、繁瑣的抱怨像潮水一樣。所以我們試驗(yàn)用紅色的邊框或者在字段上添加紅色的背景，讓這些要求更清楚。

我們實(shí)施了上面的和更多的改動。抱怨一點(diǎn)也沒少。現(xiàn)在是配置的設(shè)置，如果你想在你的社區(qū)中讓標(biāo)題和正文的最小長度為1的話，可以在瀏覽器中花大概15s來設(shè)置。坦白來說，我開始特別厭煩聽到關(guān)于這個設(shè)置的所有抱怨。

所以我們***實(shí)施了“核”選項：當(dāng)字段失去焦點(diǎn)的時候，立即彈出錯誤對話框。

自從這次改動，我再也沒聽到一個字抱怨我們正文和標(biāo)題的默認(rèn)字符長度限制的糟糕、復(fù)雜。一個字也沒有。

這就是在發(fā)布會后我們?nèi)ツ甑拿刻臁⒚恐芏家恢痹谧龅氖虑椤Ｎ覀冇昧苏荒甑谋г跪?qū)動的開發(fā)來讓軟件更有價值。即使我們現(xiàn)在謹(jǐn)慎地接收用戶，我們?nèi)栽诿刻爝M(jìn)行抱怨驅(qū)動的開發(fā)，只不過也許對于付錢給我們的用戶的權(quán)重更大些。

從你的社區(qū)得到反饋確實(shí)是件麻煩的工作，并且你得到的90%的反饋會因?yàn)楦鞣N各樣的原因很糟糕。你很容易幻想一個英雄般的專家從天而降并且神奇地告訴你正確答案。好吧，希望你白日夢成真。我見過的唯一有用的辦法就是深入實(shí)踐，和你的用戶站在同一視角，和他們交流并且發(fā)展關(guān)系。這才是你找出那***10%精彩的、具有變革意義的社區(qū)反饋的辦法，這才是你構(gòu)建一個關(guān)注你所做事情的社區(qū)的辦法 — 足夠認(rèn)真地真正聽取他們的意見，并且改動他們關(guān)心的地方。

原文鏈接： Jeff Atwood   翻譯： 伯樂在線 - Five

譯文鏈接： http://blog.jobbole.com/64630/