第六章 過程
第一節(jié) 盡快拿出實(shí)物###
確定真實(shí)的產(chǎn)品，盡快實(shí)現(xiàn)
想要建立勢(shì)頭，集結(jié)團(tuán)隊(duì)，清除無用的點(diǎn)子，最好的方式就是把軟件運(yùn)行起來。從第一天起，這就應(yīng)該是你的首要任務(wù)。
如果能讓軟件更快地運(yùn)行起來，精簡內(nèi)容、略過細(xì)節(jié)等都是都是可以接受的。一旦你開始了，你會(huì)對(duì)如何繼續(xù)下去有更清晰的認(rèn)識(shí)。故事、線框圖、html 原型都只是假設(shè)。運(yùn)行起來才是真實(shí)的。
對(duì)于真正運(yùn)行起來的軟件，每個(gè)人都能更容易理解并達(dá)成一致。你避免了在無關(guān)緊要的草圖上浪費(fèi)時(shí)間。你會(huì)認(rèn)識(shí)到那些被你忽視的部分才是真正關(guān)鍵的。
真實(shí)的產(chǎn)品產(chǎn)生真實(shí)的反應(yīng)，這能讓你獲得真相。
真實(shí)帶來共識(shí)
如果有一個(gè)完整的、真實(shí)的模型，當(dāng)一群人聚在一起想要找到一個(gè)和諧一致的答案，他們的觀點(diǎn)會(huì)更容易趨同。如果只是在畫草圖，或隨意拋出觀點(diǎn)，他們是無法達(dá)成一致的。如果你拿出實(shí)物，共識(shí)就比較容易達(dá)成。
—— Christopher Alexander，建筑學(xué)教授 (from 對(duì)比建筑和諧的概念 )
盡快運(yùn)轉(zhuǎn)起來
我所參與過的所有大大小小的軟件項(xiàng)目，他們的成功，沒有一個(gè)是來自脫離并行開發(fā)，對(duì)計(jì)劃、成本、功能進(jìn)行長期的規(guī)劃討論而得來的。你太容易把時(shí)間浪費(fèi)在開發(fā)無用的功能上。
這個(gè)道理適用于軟件開發(fā)的所有層面，把軟件盡快運(yùn)行起來是一個(gè)分形的咒語。這不僅適用于項(xiàng)目整體，也適用于其中的任意一個(gè)開發(fā)組件。
當(dāng)一個(gè)重要的組件可用時(shí)，開發(fā)者想知道這個(gè)組件能否和自己的應(yīng)用配合，他們會(huì)盡快嘗試。即使組件的配置不完美或不完整，這種早期的合作會(huì)產(chǎn)生良好的界面和功能。
—— Matt Hamer, 開發(fā)者和產(chǎn)品經(jīng)理, Kinja
第二節(jié) 反反復(fù)復(fù)
用迭代的方式工作
不要期望第一次就把事情做對(duì)。讓軟件成長并與你對(duì)話。讓他變形、進(jìn)化。基于網(wǎng)絡(luò)的應(yīng)用，無需在發(fā)布時(shí)就做到完美。設(shè)計(jì)界面，使用他們，分析他們，周而復(fù)始。
迭代過程能讓你隨時(shí)做出有效的決策，而不是寄希望于預(yù)先做好一切。在需要引起注意的地方，你會(huì)獲得真實(shí)的反饋和引導(dǎo)。
迭代帶來自由
如果你知道有些事可以稍后再做，就不必在首次嘗試就追求完美。了解到將來你還要重新審視這些問題，這樣你就有巨大的動(dòng)力把想法盡快實(shí)現(xiàn)，看看是否可行。
或許你比我聰明
或許你比我聰明的多。
這完全可能。事實(shí)上，是非常有可能。如果你和大多數(shù)人一樣，也就是像我一樣，對(duì)無法感知的事物缺乏想象。
人類能對(duì)環(huán)境做出極好的回應(yīng)。一只老虎走進(jìn)房間我們會(huì)慌張，破壞性的洪水過后我們知道如何收拾。不幸的是，在預(yù)先制定計(jì)劃，理解行為帶來的后果，以及排定重要事項(xiàng)優(yōu)先級(jí)方面，我們很不擅長。
或許你是少數(shù)能把所有事情都裝在腦子里的人，但這不重要。
Web 2.0 ，我們假定世界上的所有人都在使用網(wǎng)絡(luò)，聰明的開發(fā)者能夠利用這種人性的弱點(diǎn)。怎么做？讓用戶把他們的想法告訴你，你還有時(shí)間進(jìn)行改進(jìn)。
最后一個(gè)句子解釋了你為何應(yīng)該用這種方式開發(fā)，以及如何推廣/發(fā)布你的產(chǎn)品。
把你的故事講清楚。確保它能工作。然后發(fā)布，修訂。沒人能比集體更有智慧。
—— Seth Godin, 作家/企業(yè)家
第三節(jié) 從想法到執(zhí)行
頭腦風(fēng)暴 > 草圖 > HTML > 代碼
這是我們回歸現(xiàn)實(shí)的過程：
頭腦風(fēng)暴
提出想法。這個(gè)產(chǎn)品要做什么？對(duì)于 Basecmap ，看看我們的需求。我們希望公布項(xiàng)目更新，希望用戶參與。我們知道項(xiàng)目有時(shí)間表。我們想把歸檔集中，這樣用戶能夠很容易地查看舊文檔。我們希望能有一個(gè)鳥瞰視圖來查看所有項(xiàng)目的進(jìn)展。以上這些，大致組成了我們的基礎(chǔ)。
這個(gè)階段不考慮細(xì)枝末節(jié)，而是考慮大的框架問題。這個(gè)應(yīng)用要解決什么需求？我們何時(shí)能知道這是有效的？我們究竟要做什么？這些都是戰(zhàn)略層的問題，而不是像素級(jí)別的討論。這個(gè)階段，任何的細(xì)節(jié)都是沒有意義的。
草圖
草圖應(yīng)該是快速、潦草、廉價(jià)的，是關(guān)于你想怎么開始的問題。框架、線條、圖形，寥寥幾畫，勾勒出你腦袋中的想法。這個(gè)階段，應(yīng)該是把概念性的東西轉(zhuǎn)化成粗略的界面設(shè)計(jì)。這是一個(gè)試驗(yàn)階段，沒有什么答案是錯(cuò)的。
創(chuàng)建 HTML 界面
創(chuàng)建一個(gè) HTML 版本的功能模型，放上一些真實(shí)的內(nèi)容，讓每個(gè)人都知道在屏幕上是如何展現(xiàn)的。
對(duì)于 Basecamp ，我們先做了“發(fā)送一條信息”的界面，然后是 “編輯信息”的界面，一切都從這開始。
不要在這個(gè)階段編寫任何的代碼。只用 html 和 css 創(chuàng)建一個(gè)模型。稍后再考慮執(zhí)行。
寫代碼
當(dāng)原型看起來不錯(cuò)了，演示了足夠的必備功能，就可以開始寫代碼了。
在這個(gè)過程中，記得要保持靈活，并進(jìn)行幾次迭代。如果有任何不好的結(jié)果，不要猶豫，重新來過就好。經(jīng)歷幾次的迭代循環(huán)是很正常的。
第四節(jié) 避免偏好設(shè)置
不要將小細(xì)節(jié)留給用戶來選擇
你面臨一個(gè)艱難的決定：在每個(gè)頁面里應(yīng)該包含幾條信息？你的第一反應(yīng)也許是，“只要設(shè)定一個(gè)選項(xiàng)，讓用戶去選擇25，50，或是100。”雖然這是個(gè)簡單的辦法，但是你要做出決定。
偏好設(shè)置是避免做出艱難決定的一個(gè)方法
你把問題留給用戶，而不是利用你的專業(yè)知識(shí)來選擇最好的途徑。看起來你是幫了客戶一個(gè)忙，但你只是把工作留給了他們（而很可能他們已經(jīng)夠忙了）。對(duì)于客戶來說，偏好設(shè)置里無窮無盡的選項(xiàng)是很頭疼的，絕不是一件好事。客戶不應(yīng)該替你考慮這些細(xì)節(jié)，不要把這些負(fù)擔(dān)轉(zhuǎn)移給客戶，這是你的職責(zé)。
偏好設(shè)置是魔鬼，因?yàn)樗麄儎?chuàng)造了更多的軟件。更多的選項(xiàng)需要更多的代碼，也意味著你需要完成額外的測(cè)試和設(shè)計(jì)工作。你還得解決你永遠(yuǎn)都看不見的偏好設(shè)置選項(xiàng)排列和屏幕界面。這意味著你不了解的 bug ：破碎的布局，崩潰的表格，奇怪的頁碼問題，等等。
做出選擇
代替你的客戶來做這些簡單的決定。我們?cè)?Basecamp 中就是這么做的。每頁的信息數(shù)量是 25 條。在概述頁面，只顯示最后的 25 個(gè)項(xiàng)目。信息按從新到舊的日期排列。最新的 5 個(gè)項(xiàng)目顯示在儀表盤上。沒有任何選項(xiàng)，這就是它應(yīng)該有的處理方法。
是的，你可能做了一個(gè)錯(cuò)誤的決定，但那又怎樣？如果你做了，人們會(huì)抱怨，然后告訴你。你永遠(yuǎn)都可以作出調(diào)整。回歸現(xiàn)實(shí)就是為了能夠隨時(shí)作出改變。
偏好設(shè)置是有成本的
有些偏好設(shè)置能帶來重要的好處，也可能是重要的界面要素。但每個(gè)都是有成本的，你必須仔細(xì)衡量它的價(jià)值。很多用戶和開發(fā)者不知道這個(gè)，結(jié)果在一些價(jià)值不大的選項(xiàng)上浪費(fèi)了大量的時(shí)間和金錢。
第五節(jié) 搞定！
決定是暫時(shí)的，迅速作出，繼續(xù)前進(jìn)
搞定。把它想像成是一個(gè)神奇的詞匯。當(dāng)你搞定了某個(gè)事，意味著有什么事情你已經(jīng)完成了。一個(gè)決定已經(jīng)作出了，你可以繼續(xù)前進(jìn)。搞定意味著你已經(jīng)建立起了勢(shì)頭。
但請(qǐng)稍等，如果你搞砸了并作出了一個(gè)錯(cuò)誤的決斷呢？沒關(guān)系。這不是腦外科手術(shù)，只是個(gè)網(wǎng)頁應(yīng)用。如我們一直所說的，在開發(fā)過程中，你可能要要對(duì)功能和想法進(jìn)行好幾次的重新審視。無論作出多么詳盡的計(jì)劃，還是有大半的可能出錯(cuò)。
重視前進(jìn)的重要性。進(jìn)入決策的正確節(jié)奏。作出快速、簡單的決策，如果不行，快速返回修改。
接受“決策是暫時(shí)的”這個(gè)概念。接受錯(cuò)誤是會(huì)發(fā)生的，別把錯(cuò)誤太當(dāng)回事因?yàn)槟憧梢钥焖傩拚麄儭?zhí)行、建立勢(shì)頭、前進(jìn)。
成為一個(gè)劊子手
想法只有被執(zhí)行出來才有意義。他們只是一個(gè)乘法器，執(zhí)行才是關(guān)鍵。
解釋：
糟糕的想法 = -1
平庸的想法 = 1
一般的想法 = 5
不錯(cuò)的想法 = 10
很棒的想法 = 15
非凡的想法 = 20
沒有執(zhí)行力 = $1
弱執(zhí)行力 = $1000
一半的執(zhí)行力 = $10,000
好的執(zhí)行力 = $100,000
一流的執(zhí)行力 = $1,000,000
非凡的執(zhí)行力 = $10,000,000
要做成事，你需要把二者相乘。
最非凡的想法，如果沒有執(zhí)行力，只值$20。非凡的執(zhí)行力乘以很棒的想法，可以價(jià)值$20，000，000
這就是為什么我不想聽到人們的想法。除非我看到他們的執(zhí)行，否則我沒有興趣。
—— Derek Sivers, 董事長/程序員，CD Baby and HostBaby
第六節(jié) 在自然環(huán)境下測(cè)試
在真實(shí)的使用場(chǎng)景下測(cè)試你的應(yīng)用
沒有什么能替代真實(shí)用戶在實(shí)際場(chǎng)景下使用你的 app。獲取真實(shí)的數(shù)據(jù)。獲取真實(shí)的反饋。然后基于這些信息來改進(jìn)。
正式的可用性測(cè)試太生硬了。實(shí)驗(yàn)室無法反映真實(shí)的情況。如果你監(jiān)視用戶的行為可以獲得一些信息，但用戶在鏡頭前通常表現(xiàn)地不夠自然。有人在一旁觀察的時(shí)候，人們會(huì)格外小心不犯錯(cuò)誤，但錯(cuò)誤正是你所尋找的東西。
取而代之的，在實(shí)際應(yīng)用中添加一些 beta 功能，向經(jīng)過篩選的小部分用戶發(fā)放。這會(huì)揭示用戶的真實(shí)使用數(shù)據(jù)和工作流。你會(huì)從中獲取真實(shí)的結(jié)果。
此外，不要區(qū)分發(fā)行版本和 beta 版本，他們應(yīng)該始終是同一個(gè)東西。一個(gè)獨(dú)立的 beta 版本只能觸及表明，在正式版本中加入 beta 功能，才能得到全貌。
Beta 書
如果開發(fā)者對(duì)發(fā)布代碼感到緊張，那出版商或作家豈不是要被出書這件事嚇壞了。書籍一旦付諸印刷，想改變就不太可能了。（實(shí)際上并非如此，但對(duì)舊技術(shù)的感知和記憶仍然徘徊在行業(yè)里。）所以，出版者在出版前會(huì)耗費(fèi)大量的精力把事情做對(duì)。
當(dāng)我寫《基于 Rails 的敏捷開發(fā)》這本書時(shí)，開發(fā)者們有巨大的潛在需求：我們現(xiàn)在就需要這本書，我們想學(xué)習(xí) Rails 。如果我站在出版商的角度考慮，我會(huì)說，“它還沒準(zhǔn)備好。”但來自社區(qū)的壓力和 Heinemeier Hansson 的慫恿改變了我的想法。我在書籍完稿前的兩個(gè)月發(fā)布了 pdf 版本，結(jié)果很驚人。我們不僅賣出了許多書，還得到了反饋 —— 大量的反饋。我設(shè)置了一個(gè)系統(tǒng)來自動(dòng)捕獲讀者的評(píng)論，最終我們獲得了大約 850 條關(guān)于字體或技術(shù)錯(cuò)誤的報(bào)告，以及對(duì)新內(nèi)容的建議。幾乎所有這些報(bào)告和建議都以不同的方式融合進(jìn)最后的成書。
這是一個(gè)雙贏：我發(fā)布了一本更完善的紙質(zhì)書，社區(qū)也更早地接觸到了他們想要的東西。如果你處于一場(chǎng)競賽，盡早拿出些東西可以讓人們擁護(hù)你，而不是你的競爭對(duì)手。
—— Dave Thomas, 實(shí)用主義的程序員
快速行動(dòng)
- 判斷一個(gè)事情是否值得做
- 盡快實(shí)施——不求完美。只管做。
- 保持，上傳，發(fā)布。
- 看看人們是怎么想的。
雖然我并不樂于給產(chǎn)品添加新功能，可是一旦發(fā)現(xiàn)某個(gè)事情是值得做的，我通常在幾個(gè)小時(shí)后就會(huì)讓它上線，雖有瑕疵但不影響發(fā)布，讓反饋來引導(dǎo)未來的修正工作。
—— Derek Sivers, 董事長/程序員，CD Baby and HostBaby
第七節(jié) 壓縮你的時(shí)間
分解
要估計(jì)未來幾個(gè)星期或幾個(gè)月的工作是妄想，你根本無法預(yù)知接下來會(huì)發(fā)生什么。
所以，壓縮你的時(shí)間。把時(shí)間表分解成小塊。把項(xiàng)目看成是 12 個(gè)持續(xù)一周的小項(xiàng)目，而不是一個(gè) 12 周的大項(xiàng)目。把任務(wù)分解成 6-10 小時(shí)的小任務(wù)，而不是自己瞎猜的超過 30 個(gè)小時(shí)的任務(wù)。然后一步一個(gè)腳印。
相同的理論也適用于其它問題。你是否被一個(gè)巨大的問題纏繞著找不到出路？把它分解。持續(xù)地把問題分解成更小的部分直到你能夠消化他們。
更小的任務(wù)和更短的時(shí)間線
軟件開發(fā)者是一類特別的樂觀主義者：當(dāng)拿到一個(gè)編程任務(wù)時(shí)，他們會(huì)想，“這很容易，不會(huì)花費(fèi)太多的時(shí)間。”
給一個(gè)程序員三周的時(shí)間完成一個(gè)巨大的任務(wù)，他會(huì)拖延兩周半，然后用一周的時(shí)間來寫程序。偏離進(jìn)度通常伴隨著錯(cuò)誤的需求，任務(wù)通常比想象中更復(fù)雜。此外，誰能記住三周前達(dá)成的共識(shí)呢？
給一個(gè)程序員一下午的時(shí)間去完成一小段特定模塊的代碼，他能迅速完成并進(jìn)入下一階段。
更小的任務(wù)和更短的時(shí)間線是更可控的，降低需求誤解的可能性，減少改變和返工的成本。更短的時(shí)間線讓開發(fā)者更容易體會(huì)到完成任務(wù)的快感，避免他們有這樣的想法，“我還有大把時(shí)間來做這件事，現(xiàn)在，還是讓我先給 iTubes 的歌曲評(píng)分吧。”
—— Gina Trapani, 網(wǎng)頁開發(fā)者/ Lifehacker（效率和軟件指南） 編輯
主要因素
下次有人向你就一些不可知的問題尋求一個(gè)確切答案時(shí)，無論是截止日期，最終成本或是需要多少牛奶才能填滿大峽谷之類的，你只需回答：“我不知道。”
這并不會(huì)傷害你的信譽(yù)，這表明你對(duì)于決策是小心謹(jǐn)慎的。你不會(huì)隨便說個(gè)詞來表現(xiàn)自己的聰明。也能把問題轉(zhuǎn)變?yōu)橐粋€(gè)合作性的對(duì)話。通過學(xué)習(xí)如何評(píng)估你的需求，你們可以對(duì)數(shù)字背后的真相達(dá)成共識(shí)。
—— Merlin Mann, 43folders.com 的創(chuàng)建者和編輯
解決近在眼前的那個(gè)問題
近年來我最喜歡的一件事就是 "nofollow" 屬性（一個(gè) HTML 屬性）的發(fā)布和采用。沒人事先討論過它。沒有一大堆的會(huì)議或委員會(huì)來討論它的語義或語法屬性。沒有復(fù)雜的注解把一個(gè)簡單的想法轉(zhuǎn)變成繁雜的文檔，以至于我要通篇閱讀才知道如何使用，但最終卻因?yàn)椴磺宄摬捎?.3 或 3.3b 格式而選擇放棄。
它簡單有效，為需要的人提供了一個(gè)選項(xiàng)，對(duì)于不關(guān)心技術(shù)規(guī)格條條框框的人來說，這尤其重要。
有時(shí)，解決近在眼前的問題是更有用的，勝于解決未來的 20 個(gè)問題。他不是針對(duì)垃圾郵件的一個(gè)小勝利，對(duì)以簡潔、優(yōu)雅為己任的開發(fā)者而言，這是一個(gè)大勝利。
—— Andre Torrez, Federated Media Publishing 程序員/副總裁
