第一章 介紹
第一節 什么是 Getting Real ？###
想搭建一個成功的網絡應用？是回歸現實的時候了。 Getting Real 是用更小、更快、更好的方式來搭建軟件。
- Getting Real 是跳過所有象征真實的事物（圖表、曲線、方框、箭頭、線框等）來構建真實。
- Getting Real 是做減法。更輕，更少的軟件，更少的功能，更少的文檔，更少的無關緊要的事物（大部分你認為必要，實際卻不是的）。
- Getting Real 是維持小規模，保持敏捷。
- Getting Real 從界面開始，那個用戶會真正使用的屏幕。它從用戶的實際體驗開始，并從這里向后搭建。這讓你在軟件出錯之前獲得正確的用戶界面。
- Getting Real 是關于迭代和降低改變成本。Getting Real 是關于發布、調整，和持續改進的，使之成為一個構建網絡軟件的完美方法。
- Getting Real 只提供客戶需要的，擯棄他們不需要的。
Getting Real 的好處
Getting Real 逼迫你處理那些真正需要解決的問題，而不是你對于這些問題的想法，因此能夠提供更好的結果。它逼迫你面對現實。
Getting Real 傾向于構建真實的界面，擯棄功能規格書和其它的臨時文檔。功能規格書是虛假的，是達成一致的幻覺，而一個實際的網頁才是現實。這是你的用戶將要看到并使用的。這才是重要的。Getting Real 能讓你更快做到這點。這也意味著你是基于實際情況來做出決定，而非抽象的概念。
最后，Getting Real 是適用于網絡軟件的一個理想途徑。把軟件裝在盒子里售賣，每個一兩年發布一個更新，這種過時的模式已經逐漸淘汰。與需要安裝的軟件不同，網絡應用能夠以天為單位持續進化。Getting Real 利用這種優勢，充分發揮網絡應用的價值。
如何寫出有活力的軟件
有活力的編寫是簡潔的。一個句子不應包含無用的詞匯，一個段落也沒有無用的句子。同樣的原因，一幅畫不該有多余的線條，一臺機器不需要無用的零件。這不是要求作者將所有的句子縮短，或者只描述概要而忽略細節，而是要讓每個詞都擲地有聲。
—— from "The Elements of Style" by William Strunk Jr.
不再膨脹
老方法：冗長、官僚、人人都明哲保身的流程。典型的結果：膨脹，表現平庸、過目即忘的軟件。讓人惡心。
Getting Real 能夠避免 ...
- 長達數月甚至數年的時間表
- 不切實際的功能規格書
- 可擴展性的爭論
- 無休止的員工會議
- 雇傭大量員工的偽需求
- 毫無意義的版本號
- 想完美預測未來的藍圖
- 無盡的偏好設置選項
- 將技術支持外包
- 不現實的用戶測試
- 無用的文檔
- 至上而下的管理層級
要開發一個偉大的軟件，你不需要巨額的資金，龐大的團隊，或冗長的開發周期。這些只會產生緩慢、晦澀、單調的應用。Getting Real 采用完全相反的途徑。
**在本書中，我們將向你展示 ... **
- 經營哲學的重要性
- 為何小就是好
- 如何做減法
- 如何快速地從想法過渡到現實
- 如何配置團隊成員
- 為何應該由內而外地設計
- 為何寫作是至關重要的
- 為何要比競爭對手做的少
- 如何傳播信息，推廣你的應用
- 技術支持的秘密
- 在發布后繼續保持勢頭的技巧
- 以及更多的 ...
我們將關注于宏觀的概念。不會讓你陷入代碼的細節或是 CSS 的技巧。我們會圍繞于驅動 Getting Real 進程的主旨和哲學。
本書適合你嗎？
你是一個企業家，設計師，程序員，或市場營銷人員。
你意識到舊規則已不再適用。每年通過 CD 來發行你的軟件？2002 這個版本號怎么樣？將這些拋到窗外。你需要搭建、發布、調整，然后重復上述步驟。
或者你對敏捷開發和商業結構還不熟悉，但你渴望了解更多。
如果這些聽起來像你，這本書就是適合你的。
備注：雖然本書的重點是如何搭建網絡應用，但其中的許多觀點也適用于非軟件領域。無論你正在開展一項業務，寫書，設計網頁，錄制專輯，或從事其它的活動，書中關于小團隊、快速原型、期望迭代，以及許多其它的觀點都能給你一些指引。一旦你將 Getting Real 應用于生活中的某個方面，你就會發現這些概念能夠適用于廣泛的領域。
第二節 關于 37signals
我們做什么
37signals 是一個小團隊，我們創造簡單、專注的軟件。我們的產品幫助你更好地組織協作。超過 350,000 的個人和小企業使用我們的網絡應用來完成工作。華爾街日報的 Jeremy Wagstaff 寫道，“37signals 的產品簡潔、美麗、優雅、直觀，與之相比，Outlook 的界面看起來就像是一個審訊室。”我們的應用絕不會讓你受此折磨。
我們的行事方法
我們認為軟件太復雜了。太多的功能，太多的按鈕，太多需要學習的內容。我們有意地讓產品比競爭對手做的更少。我們的產品工作起來更智能，感覺更好，能讓你按自己的方式來做事，也更容易使用。
我們的產品
截至本書的發行，我們一共有五個商業產品和一個開源框架。
Basecamp 把項目管理作為首要功能。Basecamp 提供了 留言板，待辦事項，簡單的行程安排，協同寫作，文件分享，以此來取代甘特圖，華麗的曲線、沉重的電子表格。目前，成千上萬的人都認同這是一個更好的方式。Salon.com 的 Farhad Manjoo 說，“Basecamp 代表了網絡軟件的未來。”
Campfire 為商務場合提供簡單的群聊功能。企業知道持續穩定的實時群聊有多重要。傳統的即時通訊工具在應付快速的一對一聊天時是很好的，但面對三人以上的場景就很糟了。Campfire 解決了這個問題但不止于此。
Backpack 是一個個人信息管理工具，用于替代那些復雜且令人困惑，“用 25 個步驟管理人生”的軟件。在一個苦于維持現狀的類別里，Backpack 給頁面、筆記、待辦事項、基于電話/郵件的通知帶來了一種全新的理念。華爾街日報的 Thomas Weber 說這是該類別里最好的產品，紐約時報的 David Pogue 把它稱為一個 “非常酷”的組織工具。
Writeboard 讓你撰寫、分享、修訂，將文字與自己的或他人的作品進行比較。對于一個臃腫的文字處理軟件，95% 的功能對你的寫作是無用的，Writeboard 是一個新鮮的替代品。Daring Fireball 的 John Gruber 說，“Writeboard 可能是我見過的最清晰、最簡潔的網絡應用。” 網絡專家 Jeffrey Zeldman 說，“37signals 的天才們又一次做到了。”
Ta-da List 在線存儲并管理你的待辦列表。你可以自己保存列表，或分享給他人進行簡單的協作。沒有比它更簡單的方式來把事情搞定。迄今為止，已經創建了超過 100,000 的列表和將近 1,000,000的項目。
Ruby on Rails，對開發者來說，這是一個基于 Ruby 的全棧式的開源網絡框架，可以快速、方便地開發出真實的應用。Rails 幫你解決那些繁雜的工作，這樣你就可以專注于思考。O'Reilly 出版集團的 Nathan Torkington 說，“Ruby on Rails 令人震撼。使用它就像在看一部功夫電影，一群流氓框架想要痛打這個新人，卻被各種充滿想象力的方法修理了一頓。” 非常喜歡這個說法。
你可以在 www.37signals.com 上找到更多關于我們產品和公司的信息。
第三節 注意事項、免責聲明、及先發制人
為了提前掃清障礙，以下是我們經常遇到的一些抱怨：
這些技術不適合我
對我們來說，Getting Real 是一個工很好的系統。也就是說，書中的觀點不可能放之四海皆準。如果你在建造武器，核電站，應付百萬客戶的銀行系統，或其它關乎生命/財產的系統，我們的某些自由的處事態度對你是有害的。繼續前進，并采取一些額外的預防措施。
這不是一個非黑即白的命題。即使你無法完全接受 Getting Real 的方法，還是悄悄地使用其中一小部分觀點。
點子不是你發明的
我們沒有申明自己發明了這些技術。許多概念都以某種方式存在了很長的時間。如果書中的某些觀點是你很早之前就接觸過的，不要發怒，這完全可能。這些技術不是專屬于 37signals 的。我們只是將我們工作和成功的經驗告訴你。
你的許多觀點太絕對了
如果我們的語氣太自大了，請原諒。我們認為觀點應該大膽地說出來，而不是畏畏縮縮。如果這看起來驕傲自大，那就讓它去吧。我們愿意激進一些，而不是和稀泥，事事都要依情況而定。當然，這些規則有時需要擴展或打破，有些策略可能也不適用于你的情況。請運用你自己的判斷和想象力來決定。
這不適用于我們的公司
你認為你的公司太大了，不能回歸現實？即使微軟也可以做到（我們懷疑你會比微軟還大）。
即使你公司的發展是基于龐大的團隊和長期的規劃，還是有一些方法可以讓你回歸現實。第一步就是分散成小團隊。太多人參與會導致一事無成。更精簡一些，事情就能更好更快地完成。
當然，這需要一些推銷能力。讓你的公司進入 Getting Real 的流程。向他們展示這本書，展示你用更少的時間和更小的團隊所獲的的成就。
向人們解釋，Getting Real 是一個測試新概念的低風險，低投入的方法。
或者，如果你有膽量，可以采取秘密行動。Start.com 團隊就是用這種方法在微軟悄悄地執行 Getting Real 。“我們看過 Start.com 團隊的工作，他們沒有征求許可。” Robert Scoble 如是說，他是微軟的技術傳道者。“他們的老板提供空中支援，他們一次只吃一小口，然后執行，作出反饋。”
發布微軟的 Start.com
在大公司里，流程和會議是司空見慣的。人們花費數月的時間來討論功能和細節，期望所有人能夠達成一致，確定什么對用戶是“正確”的。
對于塑料包裝的軟件，這個方法可能是對的，但是網絡有驚人的優勢。只要發布就行。讓用戶來告訴你這是不是正確的，如果不是，你甚至可以在發布的當天就作出修正。用戶的話語是最重要的，抵制冗長的會議和討論。
知易行難，這意味著：
- 不需要長達數月的計劃
- 不需要在撰寫規格書上耗費幾個月的時間，應該在開發的過程中確定基礎，敲定細節。不要在開發前嘗試結束任何開放的問題，確定所有的細節。
- 發布高質的，少量的功能
- 你不需要一個包含眾多功能的大更新。慢慢來，讓用戶能夠消化。
- 如果有一些小 bug ，一旦確保核心功能是完好的就可以發布產品，之后通過網絡來修復 bug 。盡快獲得用戶的反饋。紙上談兵或許聽起來不錯，但實踐結果未必如此。對于根本問題，越快發現問題越好。
- 一旦你快速迭代，對客戶反饋作出回應，你就建立來客戶聯系。記住，你的目標是通過搭建客戶需要的東西來贏得客戶。
