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