37signals logo Getting Real Overview

購買本書

購買 Getting Real (英文版) PDF電子版或印刷版本。

翻譯修訂中

基於簡體中文版翻譯修訂而成。持續修訂中。

Getting Real

中文版最後修訂： 2012年2月27日， VampireNeo



引言 第一章

什麼是 Getting Real?

想構建一個成功的Web應用麼? 那麼正是時候Getting Real. Getting Real 是一種更小規模，更快速，更高質量的軟件構建方法。

Getting Real的優點

Getting Real能夠交付更好的結果，是因為它強迫你處理真正要解決的問題，而不是關於那些問題的空想。它迫使你面對當下。

Getting Real更注重實際的用戶界面，而不是功能規格說明書和其他曇花一現的文檔。只有當一個真實的網頁呈現出來，相關的功能規格才是可信的，被證明是可接受的。那才是是我們的客戶將要看到和使用的。那才是需要關心的。Getting Real幫助你更快達到這個目的。並且那意味著你正在基於真實需求，而不是異想天開來構建軟件。

最後，Getting Real是適合於Web軟件的理想途徑。那種把軟件包裝在盒子裡，再等一年到兩年才發佈一個更新的學院派方法已經過時了。不像需要安裝的軟件，Web應用能夠以天為單位持續改進。Getting Real利用了這種優勢來提升Web應用的價值。

如何編寫健壯的軟件 How To Write Vigorous Software

健壯的著作是簡明的。句子無廢詞，段落無廢句子。同樣的原因，畫應無多餘的線條，機器應無多餘的零件。這不是要作者刻意縮句來逃避細節，從而提綱挈領，而是要作者字字珠璣。

—來自 "The Elements of Style" by William Strunk Jr.


不再發胖

舊方式：冗長，官僚主義的，「我們正在這麼做來控制這些蠢驢」 的流程。典型後果是：臃腫，過目即忘，平庸得掉渣的軟件。Blech。

Getting Real 除掉...

你不需要成噸的鈔票或者龐大的團隊或者漫長的開發週期來構建偉大的軟件。那些正是緩慢，晦澀，變化成本高昂的應用程序的幫兇。Getting real反其道而行之。

這本書將帶給你...

本書關注於理論高度。我們不會使你陷入代碼片段細節，或者是CSS竅門。我們會堅守在驅動Getting Real過程的主要思想和價值觀上。

本書適合你麼？

你是管理者，設計師，程序員，或者市場人員。

你意識到舊規則不再管用了。每年通過光碟分發你的軟件？2002這個版本號怎麼樣？

或者你對敏捷開發和企業組織結構略懂皮毛，但是熱切的想多瞭解一些。

如果聽起來你是其中之一，那麼這本書就是為你準備的。

注意：雖然這本書著重在構建Web應用上，很多理念也可以應用到非軟件活動。關於小型團隊，快速原型，期望迭代，和許多提到的其他經驗能夠為你引路。無論你正在開始一項業務，寫一本書，設計一個網站,記錄簽名冊，還是其他各種各樣的活動。一旦你在你生活中的某一領域開始Getting Real，你就或發現這些概念能適用的非常廣泛。


關於 37signals

我們做什麼

37signals是一個創造簡單的，專一的軟件的小團隊。我們的產品幫助你協同工作，組織團隊。超過35000個人和企業使用我們的Web應用來搞定他們的業務。來自華爾街雜誌的Jeremy Wagstaff寫到 「37signals 的產品是超簡單，精緻，直接了當的工具，這些工具讓微軟的Outlook軟件使用起來像受刑 。」我們的軟件不會把你推到這種境地。

我們的習慣做法

我們相信軟件太複雜了。太多的功能，太多的按鈕，需要學習太多東西。 我們的產品比對手做的少 — 故意地. 我們構建的產品運行靈巧，感覺舒適，允許你以自己的方式做事，並且容易使用。

我們的產品

當這本書出版之即，我們有5個商業產品和一個開源框架。

Basecamp把項目管理作為首要問題。Basecamp提供了消息板，待辦事宜，簡單調度，協同寫作，文件共享。而不是甘特圖，炫麗的曲線圖，和繁重的電子錶格。目前，成千上萬的人同意這是一種更好的方式。來自Salon.com的Farhad anjoo說：「Basecamp代表了Web軟件的未來。」

Campfire 提供了業務模式下的簡單群聊方式。實時持久的群聊對於業務來說非常重要。傳統的實時聊天對於快速的一對一模式很有效。但是對於3個或者更多的人同時聊天來說異常痛苦。Campfire解決了此問題和其他相關問題。

Backpack 是一種替代那些玄乎，複雜，「通過25個步驟管理人生」之類的個人信息管理系統的產品。Backpack在頁面，筆記，待辦事宜，電話和電子郵件通知上的簡單嘗試，在受「statis-quo-itie」折磨的一類產品中，是一個獨具匠心的創意。Wall Street Journal的Thomas Weber說它是同類產品中最出眾的。 New York Times 的 David Pogue說它是一個「非常酷」的組織工具。

Writeboard 使你能夠撰寫，分享，修訂，和比較自己或者他人的文章。臃腫的文本處理工具，對於你95%的文字是功能過剩的，而Writeboard是一個全新的替代品。Web-guru Jeffrey Zeldman說：「37signals 的天才思想王者歸來。」

Ta-da List 維護聚合你的所有待辦清單，並且以在線方式組織。為你自己維護待辦清單，或者通過和其他人分享來協作。沒有更好的方式來搞定這些了。迄今為止，其創建了超過100，000個清單和1，000，000項行動。

Ruby on Rails, 對於開發者來說，是一個用Ruby編寫的全棧式的開源Web框架。其使得開發真是應用快速而簡單。你可以關注在你的思想上面，而由Rails操心雜事。O'Reilly的Nathan Torkington說：「Ruby on Rails太令人震撼了。使用它像是觀賞一個功夫片，片中一堆流氓框架準備痛扁這個小新人，沒想到卻被各種充滿想像力的方式揪住了屁股。」Gotta喜歡這段話。

你可以從www.37signals.com找到更多關於我們產品和我們的公司的信息.


告誡，免責，和其他醜話說在前頭

為了掃清障礙，下面是我們對於一些不時聽到的抱怨的答覆。:

"這些技術不適合我"

Getting real 是一套對我們來說效果非凡的系統。但是本書的思想並不是放之四海皆准。如果你正在構建一套武器系統，一個導彈控制設備，一個為數以百萬用戶服務的銀行系統，或者其他對生命、財產至關重要的系統，你將會迴避一些我們的放縱主義態度。請繼續前行並且採取一些其他的防範措施。

而且不必全部採納或者全盤否定我們的主張。即使你沒能力完全Getting Real，一定有少許觀點你能夠偷偷摸摸避開當權者而實行。

"這些思想不是你們發明的"

我們沒有聲明我們發明了這些技術。許多概念已經以各種形式伴隨我們很久了。當你讀到一些我們的建議，並且它提醒你讀到的一些東西已經在一些人的日記或者一些已經出版了20年的書裡面了。這是完全可能的。這些技術並不是37signals的獨創。我們只是告訴你我們怎樣工作和是什麼帶給我們成功的。

"你們的觀點過於絕對"

如果我們的口吻看起來好像無所不知，目中無人，請寬容我們。我們認為果敢地提出觀點要比唯唯諾諾，模稜兩可要好得多。如果這是驕傲自大的形象，它就是。我們寧願具有煽動性，也不願意用「那要看…」這樣的話來和稀泥。當然這些規則需要時間來完善或者打破。而且一些策略可能不適合你的場合。請運用你的判斷力和想像力。

"我們公司內部不適用."

覺得你的公司太大以至於難以Get Real？連微軟也Getting Real（而且我懷疑你的公司更大）。

即使你的公司典型地執行長期，大型團隊的調度計劃，仍有方式Get real。第一步是分解成更小的團隊。當太多的人牽扯進來，什麼事都搞不定。你越輕裝上陣，事情就做的越快越好。

沒錯，這需要一些推銷潛質。讓你們的公司投身於Getting Real過程中。給他們出示這本書。向他們炫耀你用更少時間和更小團隊所得到的真實成就。

解釋Getting Real是一種嘗試新概念的低風險，低投入的方式。

如果你有勇氣的話，秘密行動。在雷達下面飛行來證明真實結果。這正是Start.com團隊在微軟運用Getting Real的方式。「我觀察過Start.com團隊的工作方式，而他們沒有經過許可」，微軟的技術傳播者Robert Scoble說。「他們有一個老闆作為空中掩護。他們每次只接受一點功能，實現他們，並且響應反饋。」

推進微軟的 Start.com

在大公司中，流程和會議是非常平常的。數月的時間被浪費在規劃功能，爭論細節，力求達到每個人在什麼是對於客戶來說是「正確」的東西上達成一致。

這可能是塑料包裝軟件的正確途徑，但是基於Web的軟件有難以置信的優勢。立刻發佈！讓用戶告訴你這是不是正確的東西。如果你願意，你可以當天修正它然後發佈最新版。沒有什麼話比客戶的意見更有用 — 拒絕舉行囉嗦的會議和爭論。僅僅發佈產品，並且證明這個觀點。

知易行難 — 這說明：

數月的規劃沒有必要。
花費數月來寫規格說明根本沒必要 — 規格說明應該在開發過程中理清框架，描述並且精化細節。不要試圖在開發開始之前解決所有選而懸而未決的問題，並且敲定所有細節。

發佈更少，但高質量的功能.
你不需要一道電閃雷鳴伴隨著全新的發佈和一捆新功能。一小塊一小塊地喂用戶，讓他們能夠消化。

如果發現了細微的bug，先發佈敲定的核心功能，然後發佈補丁。動作越快用戶反饋越好。紙上談兵聽起來不錯，但是實踐中往往不理想。你越快發現觀點的關鍵錯誤越好。

一旦你快速迭代，並且響應用戶反饋，你就和用戶建立了一種關係。記住目標是通過構建用戶所想來贏得客戶。

—Sanaz Ahari, Start.com, Microsoft 的程序經理

起跑線 第二章

建構從簡

做得比竟爭對手少

常規的思維方式告訴我們，不管競爭對手做什麼你總是要比他們加多一些。如果他們有4個特色功能，你就需要做出5個（或15個，或25個）。如果他們花了x，你就該花xx。如果他們有20，你就得有30。

這種強調更多一層的冷戰競爭思維是行不通的死胡同。如此創造產品的方式是昂貴的，過分防禦的，並且有點偏執不正常的。防禦性的偏執的公司是做不到前瞻性思維的，他們只能做事後思維。他們不可能領導，只能跟從。

如果你只想創建一個隨大流的公司，那麼你現在就可以放下這本書，無需繼續讀下去了。

那怎樣才是有效的方法呢？答案是：做少。靠做得比對方少來打敗他。解決簡單的問題，把繁複困難棘手的問題留給大眾。不做更多，相反的我們做的更少。不趕超，相反的我們試著退一步，守後。

我們將會將貫穿全書論述「少做」的概念，現在先簡要介紹「少做」的含義作為熱身：


是什麼問題一直困擾你？

為自己而做這個軟件

一個很好的做軟件的方式就是一開始用它來解決你自己的問題。由於你自己變成了軟件的目標受眾因此你會知道什麼是重要的什麼不是。這樣做下去將會是推出一個突破性產品的偉大起始點。

關鍵是你要瞭解你並不孤單。如果你有一個困擾你的問題那麼非常有可能成百上千的其他人業有同樣的煩惱。這，就是你產品的市場。看，不難找到吧？

Basecamp這個產品來自於一個困擾我們的難題：做為一個設計公司，我們需要有一個很簡單的方式來和客戶做項目溝通。一開始，我們建了一個外部網，通過不斷更新其內容來連線客戶。但每次一個項目需要更新我們就得手動更改HTML，這實在不是一個解決方案。這些項目網站總是看起來不錯但最終總是被放棄了。這是很令人惱火的，因為它使我們變得很沒有組織性，也讓客戶感到無所適從。

於是我們開始尋找其他解決方案。但每樣我們找到的工具都是 1)並不能做我們想做的 或 2)充斥著我們所不需要的功能 — 比如象賬單，登錄權限控件，圖表，等等。我們覺得一定會有更好的方案，最終我們選擇了自己來做這個軟件

當你在做軟件解決你自己問題的時候，你創造的工具是你對之有激情的。那激情就是關鍵所在。激情意味著你真正去用這個軟件，去關心這個軟件。這是能感動他人並一起為之所動的最好的方式。

自助（自撓其背而止癢）

這是很長一段時間以來被開源領域奉為箴言的 — 他們叫它做「自撓其背而止癢」。對開源軟件開發者來說，這意味著他們將自己去組織必需的工具，用自己的方式來推出產品。不僅於此，這樣做的有著更深遠的裨益。

作為一個新軟件的網頁設計師和程序開發者，每天你要面對上百個細小的決策：是要藍色的還是綠色的？用一個表格還是兩個？靜態的或是動態的頁面？放棄重新來過還是修復？一般我們是怎樣來做這些決定的呢？如果那是我們認為很重要的我們也許會提出來討論。其餘的我們就靠猜想。最終所有那些猜想的部分將積累成軟件的一種債務 — 一堆互相交織著的錯綜複雜的充滿不確定因素的網。

作為一個開發者，我厭惡這種現象。想到有那麼多的小型定時炸彈分佈在這個軟件中，給我帶來了很大的壓力。自己幫助自己的開源軟件開發者不會有這樣的困擾。因為他們就是用戶本身，90％的情況下他們瞭解他們應該做什麼決定。我想這是為什麼這些人能夠在一天辛苦的工作回家後還能繼續編寫開源程序的眾多原因之一，因為它反而是一種放鬆。

—Dave Thomas, 《程序員修煉之道》

一切源於必要性

Campaign Monitor公司的成立事實上是來源於必要性。多年來各種email市場營銷工具的低劣品質一直困擾著我們。一個工具可以做到x和y卻總也做不到z，另一個能搞定y和z卻總也做不好x。老是這麼下去我們將無法成就贏家。

我們於是決定整頓我們的時間表，著手開發我們理想中的email市場營銷工具。我們很清醒地決定不看其他人在做什麼而是專心做一個能讓我們自己和客戶都活得自在一些的產品出來。

事實證明，我們並不是惟一對現狀感到不滿的人。我們對軟件成品做了一些改動，這麼一來所有的設計公司（不僅我們自己）都能使用它並且開始幫我們推廣。不到6個月，數以千計的設計師開始用Campaign Monitor來發佈他們自己和客戶的email推廣信了。

—David Greiner, 創始人, Campaign Monitor

你必須在乎這個東西

當你在寫一本書，你必須要有一個以上的有趣故事可講。你必須有強烈地要講敘這個故事的慾望。你必須要以某種方式把自己投入到故事中去。如果你要和一件事業共存兩年，三年或你地一生，你必須要真正在乎它

—Malcolm Gladwell, 作者 (from 雜看Malcolm Gladwell)

找自己募資

外部資金只是第二條路(plan B)

很多創業者的首要任務就是找投資者募集資金。但必須記住，當你尋求外部資金的時候就意味著你不得不向別人匯報。於是別人對你的期望值將提升。投資者無不希望他們能夠收回資金 — 並且是以最快的速度收回。導致一個不幸的事實就是往往搶錢優先過做一個優質的產品。

現時創業並不需要太多的啟動資金。硬件便宜了，大量的優秀框架軟件也都開源免費了。而且創業的激情是不需要標價的。

因此手頭有多少錢就先動起來做多少事。用心想想決定什麼是你最基本需要的，什麼是可以先捨棄不做的。什麼事是你可以三個人就搞定而不必用到十個人？什麼是兩萬塊而不用十萬塊就能辦到的？什麼樣的軟件你可以一邊白天打工用業餘時間做出來的？

資源拮据往往能激發想像力

當在有限的資源平台上運作，你往往會被迫更早的更緊迫的認識到這種壓力。那是一件好事。有壓力才會促使創新。

拮据也能迫你更早地將你的點子推出來—這是另一件好事。這麼跨出去一兩個月後你就會比較清楚的瞭解這個點子是否有戲。這樣一來，你就會在短時間內樹立起自信心，不再那麼急切尋求外部資金了。如果你的點子行不通，是虛的（酸檸檬），那麼就是重新來過的時候了。壞消息至少你現在知道比幾個月後或幾年後知道好。至少你比較容易退出。當有投資者涉入的時候退出方案要複雜的多了。

如果你做軟件只是想搞一度快錢，那麼事實是瞞不住的。想很快的回本實踐中是不大可能的。所以，專心做一個優質的軟件，做出一個你和你的客戶都能長久依賴的工具才是正道。

兩條路

[Jake Walker擁有的一家公司是用投資者的錢創立的 (Disclive) 另有一家不是 (The Show)。 在這裡他探討了這兩條路的不同風景。]

所有問題的根本並不是籌募資金本身，而是隨之而來的一系列事情。基本上就是更高的期望值。人們於是開始領工資，然後動力就成了做一個軟件然後把它賣了，或想辦法把種子基金給還了。就我前面的第一家公司（Disclive)，出於必要性我們起步得比我們原先設想的高很多 —

[關於第二家公司The Show] 我們發現我們可以推出一個花更少的錢卻可以做得更好得產品，只不過要多花些時間。我們把很多自己的錢賭到一個人們願意犧牲一點時間來換取品質的產品上面。但公司一直保持著小規模（也預計會一直這麼走下去）。從那以後，我們就全部是內部募資。通過採取一些靈活的交易方式和我們的供應商合作，我們從不需要投入自己很多的資金。並且我們並不是做大後賣了，而是隨需要而發展，走持續的可盈利道路。

—評論來自於 Signal vs. Noise

固定時間和預算，但靈活控制產品外延

準時地在預算內推出

一個簡單方法讓你能準時地在預算範圍內推出產品：定額定量。絕對不要在一個難題上多投時間和金錢。要麼縮小規模，要麼縮小範圍。

總會有一個這樣誤區：我們能做到準時地，在預算內發佈一個規模完整的產品。這可以說完全不可能的，如果真是這樣的話一定是以質量做為代價的。

如果你不能在預定的時間和預算內完成所有的東西的話，就不要拉長時間和增加預算。相反的，把產品的外延縮小些。下一步總是有時間可以加東西進去 — 過後有的是時間，當下卻是稍縱即逝的。

做一個比預計要小巧些的好東西比做一個龐大平庸而又漏洞百出的東西要現實的多，因為你要象魔術師一樣巧妙的照顧到時間，預算和產品內容的方方面面。變魔術就交給Houdini（魔術大師）。你所做的可是在運作一個真正的事業，在推出一個真實的產品。

以下是一些固定時間和預算，靈活控制產品外延的好處:

我們建議：範圍縮小些。做半個產品比做半拉子的產品好（後面將進一步論述這點）。

一天，兩天，三天...

知道一個項目是怎樣拖到最後比預計遲一整年的嗎？就是這麼一天一天拖出來的。

—Fred Brooks, 軟件工程師，電腦科學者

找個敵人

挑選一場戰鬥

有時瞭解你的應用程序應該做成什麼樣子的最佳方式就是，認識到它不應該成為什麼。搞清楚你的軟件的對手是誰，就像點一盞燈，能照亮你前行的道路。

當我們決定開發項目管理軟件的時候，我們清楚的知道微軟項目軟件（Microsoft Project)是這個小舞台上的一個龐然大物，大猩猩。我們不是去害怕這個大傢伙，相反的我們把它做為一個刺激我們前進的引擎。我們決定Basecamp將做成一個完全不同的項目管理軟件，就是反Microsoft Project而行。

我們意識到項目管理並非就是有關圖表，報告和統計數據 — 它更重要的是溝通。它並不是要一個項目經理坐得高高在上去傳達一個項目計劃。它應該是每個人都參與的，一起擔起責任來使項目付諸實現。

我們的敵人就是項目的獨裁者和他們用來指手畫腳的工具。我們要把項目管理民主化 — 讓每個人都能成為它的一份子（包括客戶）。只有每個人都承擔負責流程的一部分，這樣整合起來項目才能做得更好。

說說Writeboard這個協同文字編輯軟件，我們知道有很多的競爭對手的產品內建了許多複雜玄妙的功能。正因為如此，我們決定著重從「不花哨」入手。我們開發了這個程序僅僅來讓人們共享和協作，而不用一些非必要的功能來使他們舉步維艱。只要是不必要的我們就不做。推出後僅3個月的時間，已經超過10萬個用戶在使用Writeboards。

當我們開始著手Backpack這個資訊管理軟件的時候，我們的敵人就是嚴格的組織框架和規章制度。人們應該要能夠用他們自己的方式來管理他們的信息 — 而不是在一堆預先規定好的格式和眾多的表格中填空。

你能從敵人那裡得到的一個好處就是：一個非常清晰的營銷理念。人們很容易被衝突對立挑動。並且通過把一個產品和另一個作比較能更多地瞭解這個產品。選中了這麼一個敵人，你給人們灌輸了他們想要知道的對立的信息。這樣一來，他們不僅能更好更快地認識你的產品，也會站到你的這邊。這是一個吸引注意力和引發產品傾向性的一個萬無一失的方法。

說了這麼多，必須指出的是，也不要太過著迷於競爭。過分地去分析其他產品會慢慢限制你的思維想像力。很快地看一下他們在做什麼，然後就要回到你自己地理念和理想上來。

別老跟著領頭羊

營銷人員 (和幾乎所有人) 都被培訓要跟從領導者。自然的本能都是在思考競爭對手做對了什麼，然後你在那個基礎上做得更超過。 — 如果你的對手在競價你就一定要比他更便宜，如果他在競速你就要比他做得更快。這麼一來出現的問題是萬一消費者聽信了別人的故事（或謊言），你再要把他說轉回來就會像要說服他承認他是錯的一樣。沒人喜歡承認他是錯的。

於是你應該創造一個不同的故事來說服聽眾，告訴他們你的故事要比他們在其他地方聽到的更重要。如果你的競爭對手是在競速，那麼你就必須轉到競價上來。如果他們強調的是健康，那麼你就必須推銷方便性。並不是簡單地在x/y軸圖表上標出「我們比較便宜」的聲明，而是實實在在地用真實的完全不同於他人正在推銷的故事。

—Seth Godin, 作家/企業家(from 做個更好的騙子)

問題的關鍵是什麼?

老是看你的競爭對手在做什麼是你給自己找麻煩的最快的方式之一。對於我們建造BlinkList這個平台來說尤其確實。從我們推出以來已經有其他10個類似的社交關係網軟件相繼出現。有些人已經開始在網上用並排圖表來做不同軟件之間功能特色的詳細比較。

這是很容易誤導的。我們不隨大流，相反的，我們只看大方向，時時提醒自己什麼是我們想要解決的問題關鍵，怎樣去解決它。

—Michael Reining, 共同創立人, MindValley 和 Blinklist

它不該成為一種交易

你的激情 — 或者冷漠 — 會起作用的

如果你越不把軟件當作一種交易去做，你就越能做得好。把它控制在一個你能把握的小範圍內，你就有可能真正地享受過程。

如果你做這個軟件一點不興奮，那就是什麼地方出了問題了。如果你只為了趕緊搶點錢做掉它，那這種影響會出現在最終產品上。同樣地，如果你滿懷熱情地去做它，結果也會反映在產品上。人們是能夠分辨出箇中的區別的。

激情的體現

在設計這個高度主觀，具爭議性且難以界定的領域裡，沒有什麼是能做到比表達激情更直接清晰的了。一個產品會使你歡欣或讓你無動於衷是很顯而易見的; 不管是前者或後者，要人們不發現軟件背後那些創造者的感情投入是很困難的。

熱情是很容易凸顯出來的，漠然也是同樣難以掩飾的。如果你並非帶著一種誠摯的心去對待手頭上的產品，那麼它留下的漠然與空白是幾乎不可能掩飾的，不管一個設計作品表面看來多麼精細吸引人。

—Khoi Vinh, Subtraction.com

烘培師

在美國，在這個時代生意經往往是提出一個構想，讓它能盈利，在還能盈利的時候把它賣了，然後改行或不幹了。這往往是一個能否挺下去的問題。對我而言: 去熱愛烘培，賣你自己做的麵包，人們如果喜歡它我就賣多些。我就這麼把烘培事業做下去，因為我知道我在做好吃的人們愛吃的東西。

—Ian MacKaye, Fugazi的會員， Dischord Records的合夥人
(from Salon.com People | Ian MacKaye)

保持精益 第三章

更小的質量

你越做到精益，改變越容易

一個物體的質量越大，改變方向需要的能量越多。物理世界的這個真理同樣適用於商業世界。

當真理應用到Web技術的時候，改變必須是簡易和低廉的。如果你不能如飛一樣的改變，你就會敗給能夠做到的競爭者。這就是你需要追求更小質量的原因。

質量會由於以下因素增加

質量會由於以下因素減少

更小的質量使你快速的改變方向。你可以隨機應變和演進。你可以集中於好的主意，擯棄壞的。你可以傾聽並尊重你的客戶。你可以集成新技術現在而不是以後。你駕駛的是蒸汽船而不是飛機貨艙。為這個事實驕傲吧。

舉例來說，想像一個精益，小質量的公司，用更少的軟件，更少的特徵製造了一個產品。另一方面是一個更大質量的公司擁有一個帶有明顯更多軟件和特徵的產品。那麼試想一下，隨著新技術，比如Ajax，或者新概念，比如標籤的出現，誰會更快的調整他的產品？擁有更多軟件更多特徵還帶著12個月路線圖的團隊，還是另一個團隊，擁有更少軟件更少特徵和一個更有機的流程——「讓我們集中於我們當下應該集中精力的地方吧」。

很明顯，更小質量的公司在適應市場真實需要的方面處於更有利的位置。當小質量公司已經完成轉換很久以後，更大質量的公司有可能仍然在爭論變化或者將他們推入官僚主義的流程中。小質量公司會領先兩步於仍然在爭論如何走的大質量公司。

反應快，敏捷，小質量的公司可以快速的改變他們整個業務模型，產品，特徵集和營銷信息。他們可以犯錯並快速的修復。他們可以改變他們的優先級，產品組合和重點。還有最重要的，他們可以改變他們的想法 。


減少改變的成本

通過減少改變的阻礙保持靈活

改變是你最好的朋友，改變的代價越大，你越不可能做出改變。如果你的競爭對手可以比你更快的改變，你會處於一個很大的劣勢。如果改變變得過於昂貴，你已經死了。

這就是保持精益真正幫助你的地方。很短時間內改變的能力是小團隊與生俱來而大團隊永遠不會有的。這是大傢伙嫉妒小傢伙的地方。讓巨大組織裡的大團隊花費數周才能改變的，對於小團隊可能只需要1天。這個優勢是無價的。低廉和迅速的改變是小團隊的秘密武器。

請記住：所有的現金，所有的營銷策略，所有的世界上的優秀人物，都買不到小帶來的敏捷。

順其自然

順其自然是敏捷的根本原則之一，也是最接近純正魔術的一個。順其自然的特性不是設計的或內建的，它自然的發生，就如系統其餘部分的動態結果。「順其自然」來自於17世紀中期的拉丁文，意思是「無法預見的出現」。你不可能為它做計劃，或者做時間表，但是你可以為它營造一個環境，讓它發生並受益於它。

順其自然一個經典的例子是鳥群的遷徙行為。計算機模擬只需要少至三個原則（按照「不要撞到一起」），你會一下子得到非常複雜的行為來描述鳥群在天空中優雅的飛行和滑翔，重組隊形繞開障礙，等等。沒有一個高級行為（比如躲開障礙重組形成的相同形狀）是被規則規定的；都是由系統動態衍生的。

簡單的規則，就像鳥群的模擬一樣，導致複雜的行為。複雜的規則，就像許多國家的稅法一樣，導致愚蠢的行為。

許多常見的軟件開發實踐帶來了令人遺憾的邊際效應，他們消除了順其自然行為的發生機會。大多數優化的嘗試——直率的敲下一些代碼——減少了互動和關聯的寬度和範圍，而這些正是順其自然的來源。在鳥群遷徙的例子中，正如一個設計良好的系統，正是互動和關聯創造了有趣的行為。

我們把事物綁的越緊，留給創新的、順其自然的解決方式的空間就越少。不管是在需求被完全理解前就鎖定了需求，還是不成熟地優化代碼，讓終端用戶使用系統前引進了複雜的導航和工作流場景，結果都是一樣的，一個過分複雜、愚蠢的系統，而不是順其自然帶來的清潔和優雅的系統。

保持小，保持簡單，順其自然。

—安德魯·亨特(Andrew Hunt)， 實效程序員網站(The Pragmatic Programmers )

三個火槍手

用三人小組構建1.0版本

對於產品的1.0版本，請從只有三個人開始。三是一個魔力數字，提供足夠人力的同時允許你保持流暢和敏捷。從一個開發者，一個設計者，和一個清道夫（一個可以在開發和設計中隨意切換的人）開始。

現在顯而易見的是用很少的人建造一項應用是一個挑戰。但是如果你有一個正確的團隊，挑戰是值得的。有才能的人不會需要無盡的資源。他們會在約束限制下的工作和利用創造力解決問題的挑戰中成功。缺少人力意味著你會被迫更早的應對權衡——那是沒問題的。這種情況會讓你更早而不是更晚的指出你的重點。你也能夠與人交流，不用經常地擔心他們不瞭解前因後果。

如果你不能夠用三個人建造第一個版本，那麼你或者需要更改人數或者需要縮減初始的版本。記住，保持你的第一個版本小而緊湊是沒有問題的。你會快速的發現你的想法是否快速的進展，如果是，你會擁有一個清潔的簡單的基礎可以繼續建造。

梅特卡夫定律(Metcalfe's Law)和項目團隊

保持團隊盡可能的小。梅特卡夫定律(Metcalfe's Law)，「網路的價值，為使用者的平方」，應用到項目團隊的時候得到一個推論：團隊的效率和團隊人數的平方成反比。我開始覺得三個人對於1.0產品發佈是最優的...從減少你計劃添加到團隊的人數開始，接著減少更多。

—Marc Hedlund, 奧萊利媒體（O'Reilly Media）入住企業家(entrepreneur-in-residence)

通信流

通信在小團隊比在大團隊中更容易流動。如果你是項目中唯一的一人，通信是簡單的。唯一的通信通路是你和客戶之間。但是，隨著項目人員數目的增長，通信通路的數量也隨之增長。它並不是加法形式的增長，隨著人員數目的增長，它是乘法形式的增長，正比於人員數目的平方。

—史蒂夫·麥克科耐爾(Steve McConnell）, Construx軟件公司（Construx Software Builders Inc.）首席軟件工程師。
(摘自 《少即是多——小團隊的第一生產力》，Less is More: Jumpstarting Productivity with Small Teams)

擁抱約束

讓限制帶領你到創新的解決方法

總是有不充足無法滿足所有需要。不充足的實踐。不充足的金錢。不充足的人。

這是一件好事情

不要被這些約束逼得發瘋，擁抱他們。讓他們指導你。約束驅動創新並強迫集中精力。不要試著移除它們，使用它們帶來你的優勢。

當37signals構建Basecamp的時候，我們有非常多的限制。我們有：

我們感受到了「不充足「的憂傷。所以我們讓我們的盤子保持小。那時我們只能夠往上方這麼多。我們選取大任務，把它們分解成我們一時間能夠處理的小任務。我們一步一步的行動並在前進的過程中分清主次。

」不充足「強迫我們使用創新的方法解決。我們通過始終構建更少的軟件減少改變的成本。我們給人們僅僅足夠的特色讓它們以自己的方式來解決自己獨特的問題 — 於是我們便不再是障礙。時差和空間上的距離讓我們在交流中更加有效。不是人參加會議，我們的交流幾乎毫無例外通過及時通訊軟件和電子郵件，它們強迫我們快速的到達重點。

約束經常是偽裝的優勢。忘掉風險投資，長發佈週期和快速招聘。代替的是，和你目前擁有的合作。

與枯萎作鬥爭

曾經被稱作「緩慢增長的優雅」可以被更恰當的叫做「特徵枯萎病」，就像植物上的真菌一樣，它節外生枝，模糊了產品的輪廓並吸乾了它的汁液。特徵枯萎病的解藥是，當然是，「限死的最後期限」。這導致特徵被按照實現所需時間的比例被拋棄。經常出現的情況是最有用的特徵需要最長的時間。於是枯萎和最後期限的結合產生了許多我們知道和喜愛的軟件，包含了充足的沒有用的特徵。

—Jef Raskin, 作者 (摘自 "為什麼軟件是它的方式")

做你自己

通過親切友善和人性化來把自己和大公司區分開來

大量的小公司犯了試著裝作大公司的錯誤。就好像他們意識到他們的規模是一個缺點，需要隱藏。太糟糕了。小型實際上可以是一個巨大的優勢，尤其是在通訊方面。

小公司享受著更少的形式主義，更少的官僚主義，和更多的自由。小公司天生和顧客更親近。 那意味著他們可以以一種更加直接和人性化的方式和顧客溝通。如果你是小公司，你可以用熟悉的語言而不是晦澀的行話。你的網站和產品可以用一種人類的聲音，而不是操著公司的腔調。小型意味著你可以和你的顧客在一起談話，而不是居高臨下的方式。

小公司在內部的交流生同樣有優勢。你可以擯棄形式主義。所有事情都不再需要繁雜的流程和多重的簽字確認。參與流程的人都可以開放和誠實的發言。這個沒有被束縛的思想流是保持小型的巨大優勢。

驕傲地、無所畏懼地做到真實

雖然你可能認為，顧客可以被誇大員工數字或者你的支付能力欺騙，但是精明的，你真正希望的顧客，永遠會知道真相 — 無論通過直覺還是推理。尷尬的是，我曾經參與過這樣的善意謊言，所有謊言都沒有帶來對商業最重要的東西：和真正需要你的服務的顧客建立的有意義的、持久的和互利互惠的關係。更好的應對應該是驕傲地、無所畏懼地對公司的實際規模和寬度做到真實。

—Khoi Vinh, Subtraction.com

不論何時

不管你在哪個行業，良好的顧客服務應該是所有客戶最大的要求。我們自已對於服務是這樣要求的，我們的客戶又怎麼會有區別？從一開始，我們就做到讓客戶和我們的接觸容易和明晰，不管他們有多少、甚至沒有問題。在我們的網站上，我們列出了一個免費號碼會轉接到我們的手機；在我們的名片上，每個人都列出了手機號碼。我們向顧客強調，不管他們有什麼問題，他們隨時可以聯繫到我們。我們的顧客感謝我們這樣的信任，沒有人濫用過我們的服務。

—Edward Knittel, 銷售和市場總監, KennelSource

首要任務 第四章

什麼理念才是偉大的

明確定義產品的閃光點

竭盡全力將你的軟件定位在一個點上。你的軟件代表的是什麼？它到底是有關什麼的？在你開始設計或寫任何代碼之前你必須清楚地知道你做這個產品的目的 — 它的前景。把理想放大些。為什麼要有它？它和其他類似產品不同的地方在哪裡？

這個理念會引導你的每個決定，指引你不偏離航線。任何時候有比較出格的舉動時，問自己，「我們是不是還在堅守著自己的理念做事？」

你的理念必須是簡潔的。應該一句話就能把想法傳達到。以下是我們每個產品的理念：

舉個例，我們Basecamp軟件的理念是，「項目管理即是溝通」。我們強烈的感覺到對一個項目的有效溝通是引導一系列責任，參與，投資和能量的關鍵。它把大家統到同一個目標上來增強共識。我們清楚地知道如果Basecamp能做到這點，那麼其他事情也就會一一水到渠成。

這個理念引導著我們盡可能地保持Basecamp的透明性和開發性。我們不把溝通局限在公司內部，相反我們向客戶敞開。我們不考慮太多權限地問題，相反我們更鼓勵各方的參與。就是這個理念使我們放棄了圖表，表單，報告，狀態分析和電子錶格的功能，相反的我們專注在優先問題的溝通上，如果每日新信息，評論，該日備忘項目和文件的共享。把有關你理念的重大決定做在前面，將來其他小的決定就會變得容易多了。

白板上的哲理

有一次Andy Hunt和我編寫一個借記卡的交易開關。有一個要點就是同一個交易不許向用戶的借記卡二次收費。也就是說，不管操作過程中怎樣出錯，錯誤都只能發生在交易最終產生前，不能允許出現重複的交易。

因此，我們在共享信息的白板上用大字寫下：要從客戶角度出發，容許客戶犯錯誤的可能。

還有其他大約半打多類似這樣的信條，在我們創建一些複雜的產品，需要下有技巧性的決定時，這些信條給我們指引了方向。它們使我們的軟件有強大的內部凝聚力和外部的統一性。

—Dave Thomas, 一個實用編程者

編寫座右銘

組織需要指導原則。需要有一個綱要; 員工每天醒來時應該要知道他們為什麼而工作。這個綱要最好言簡意賅，富有激情：為什麼你會在這裡？是什麼激勵了你？我把這看做是座右銘 — 一段三或四個字的描述你存在的意義。

—Guy Kawasaki, 作者 (摘自 編寫座右銘)

在初期時忽略細節

先粗後細

我們太過癡迷於細節。

成功和滿意來自於細節

然而，細節中並不只有成功。細節中你還會遇到停滯不前，意見不合，無數的會議和延遲。這些東西會掩煞你的信念，降低你成功的幾率。

你可有常常一整天被困死在一個設計原素或一個程序代碼上？可有不時覺得你今天的進展實在算不上什麼真正進展？過早專注於細節就會導致這些結果。要做完美主義者有的是時間。但不是現在。

別在第一周就擔心標題字體的大小。不需要在第二周就搞定什麼是最佳的綠色的色調。更不用在第三周就要把「提交」按鈕向右移動三個像素。先把該放的東西放上去。然後去用它。保證它是可用的。最後才去把它調整到完美。

細節是在你使用的過程中才會顯露出來的。只有在使用中你才能看到什麼需要進一步關注。在使用中你才會感到缺了些什麼。常常走路絆倒腳你才會清楚地上什麼坑窪是需要填補的。那些是當你被迫要留意的時候才需要的細節，不是一想到細節就去搞定它。

魔鬼隱藏在細節中

在選修了幾堂繪畫課後，我徹底擺脫了「馬上投入到細節中」的態度...如果你一開始就畫細節十有八九出來的畫作會不怎麼樣。事實上，從你一開始那麼做就完全錯了。

你必須一開始把全局的比例分配搞對。你要從最大的一塊著手，慢慢過渡到最小的。草稿必須體現模糊的主題。然後你著手潤色，使整體畫作具有生命力。著色先從淺，中，深三個色調下手。這麼一來你的草稿就會有明暗了。接下來，在你畫作的其他部分都要秉持三個色調的應用原則。如此反覆直到整體成型...

永遠，都要從大到小去做。

—Patrick Lafleur, Creation Objet Inc. (摘自 Signal vs. Noise)

當問題成為問題的時候才去擔心

不要把時間浪費在還未成為問題的問題

你真的的需要考慮當用戶到達10萬以上的時候會出現的問題嗎？它可能已經是兩年以後的事了。

如果你現在只需要三個程序員你真的有必要雇八個嗎？

你難道真的馬上需要12台高端服務器即使兩台就足以讓你頂一年？

就先掠過吧

人們總是預先花很多時間在還不知道會不會發生的問題上。靠，我們推出Basecamp的時候還不知道如何向客戶收費！因為產品是月付費的，我們知道還有30天的時間來搞定付費方式。我們把預先省下的時間用在解決更緊急的問題，直到產品推出後，我們才著手付費問題。結果很順利（它迫使我們用最簡單的解決方案，沒什麼花哨的東西）。

別整天操心還沒成型的麻煩。別過度開發一個產品。到適當的時候再添加硬件和系統軟件。如果進度推遲了一兩個星期，別擔心，還沒到世界末日。只要誠實: 解釋給你的客戶聽，說你們正經歷著成長的煩惱。他們也許不會因此無比感動，但他們起碼會贊同你的坦誠。

關鍵是: 如果你已經掌握了你需要的信息就及時做決定。這樣你就能把注意力集中到需要馬上解決的問題上來。


去網羅對味的顧客

找到你產品的核心市場然後就專注進去

顧客並不總是對的。現實中你要能分辨出誰是你該針對的顧客，誰是你該放棄的。慶幸的是，互聯網使得發掘有共識的顧客的過程變得無比容易。

如果你想討好每個人那麼你什麼人也討好不了。

當我們做Basecamp的時候，我們把市場營銷集中在設計公司這塊上。如此縮小市場範圍，我們就更有可能吸引一些有心的顧客來成為產品的追隨者。要清楚地知道你的產品是為誰推出的，集中精力去討好這部分人。

我們最成功的一步棋

把Campaign Monitor（市場策略觀察）這個產品嚴格地定位在網頁設計這塊市場是我們走得最好得一步棋。它使我們能很容易地分辨出什麼產品特色才是真正有用，更重要地是，什麼特色是該捨棄地。這樣一來，我們不僅能靠瞄準一個比較小地目標市場來爭取更多地客人，也因這些客人都有相近的需求使得我們的開發工作更容易些。在Campaign Monitor中有大量的功能對其他人是毫無用處的完全針對網頁設計者做的。

關注在一個核心市場也便於產品的宣傳。我們有了這麼一個定位精準的用戶群，就能知道要在他們網上經常出沒的地方做廣告，發佈他們可能會感興趣的文章，然後逐步建立一個產品的用戶社區。

—David Greiner, 創始人, Campaign Monitor

過後才去做規模調適

你還沒有必要現在就做調整

"我的應用程序能否適應萬人的使用規模?"

等那真發生了再說，明白嗎？如果用戶的數量大大超過你的系統負荷那麼恭喜！太喜歡這種麻煩事了。但在現實世界中，超大多數的網絡應用程序從來都沒有到達那一步。即使你真的開始超負荷了，也不會到馬上就掛了的地步。你將會有時間反應和調適。還有一點就是，只有推出產品後你才有機會採集真實的數據指標，然後你才能用它們來推斷哪些領域需要改進。

舉例說明，推出的第一年我們的Basecamp只是在一台服務器上運作。因為這樣的一個簡易設置，整個實施只花了我們一周。我們並沒有一開始就搞個15台服務器的集群或是花好幾個月的時間擔心規模調適的問題。

我們這麼做有碰到什麼問題嗎? 有一些。但我們也發現大多數我們害怕的問題，比如短暫的系統滯緩，對用戶來說並不是什麼不得了的事。只要你及時和用戶溝通，誠實地面對問題，他們是會諒解的。回頭看，我們真的非常高興當時並沒有為了」完美的呈現「而把產品的發佈推後數月。

開始階段，要把建造強有力的核心產品做為首要任務，不要過分執迷於需不需要服務器組和是否有能力調整規模應變。 先把一個偉大的產品推出，然後才去擔心它無比成功了以後該怎麼辦的問題。 否則你可能只是把精力，時間和金錢花在一個永遠不會發生的預期上。

信不信由你，最大的問題不是規模調適，而是怎樣達到你不得不需要去調適的那一刻。沒有第一個麻煩哪來下一個麻煩。

反正你怎麼也得回頭重新審視

事實上，每個人都會有規模調整的問題，當服務人群從零到幾百萬的時候，所有人都必須回過頭去重新審視產品設計架構的方方面面。

—Dare Obasanjo, 微軟 (摘自 規模調適和創業公司)

軟件要有自己的主張

你的軟件應該要有傾向

一些人在論證軟件應該保持中立的問題。他們說開發者限制或忽視大眾訴求的軟件功能是一種傲慢的表現。他們說軟件應該總是能隨機應變的。

我們認為那都是扯淡。偉大的軟件必須要有自己的理想。偉大的軟件必定是有傾向的。當人們使用軟件的時候他們不只是在看功能，同時他們也在尋找一個解決方案，一種理想。決定你的理想而後追求不懈。

同時謹記，如果他們不認同你的理念的話還有無數的其他理念可供選擇。沒有必要總追逐你永遠無法討好的人。

一個著名的例子就是wiki的最初設計過程。Ward Cunningham和他的朋友們有意把傳統上認為協作文章不可或缺的許多功能都捨棄不用。他們不把每次文章的修改歸功於特定哪個人，而把所有權標識都去除了。這麼一來，內容就不再自我，而成為永恆。因為他們相信重要的不是誰或什麼時候寫的文章。這個理念改變了一切。這個決定孕育了一個以共享己任的社區，成為Wikipedia（維基百科）日後的主旋律。

我們的軟件走的是一條類似的路。我們的軟件並不追求成為所有人的寵兒。我們的軟件是有自己的性格的。他們找尋的是志同道合的用戶夥伴。他們是在和有著同樣理想的用戶對話。你要麼上來一起，要麼下車。


挑選功能 第五章

部分，而不是殘缺不全

構建一半產品，而非產品有一半缺陷

小心「所有東西除了廚房水池」的Web應用開發途徑。投身於出現的每一個合適的點子上，你將會終結在產品的一個半傻不隉的版本上。你真正想要做的是構建一個把愚蠢一腳踢開的產品。

專注於真正必須的。好點子可以盡量坦白。擺出產品應該成為什麼樣的任何點子，然後砍掉一半。減少功能直到只剩下最必要的功能。週而復始。

對於Basecamp，我們從Message開始。我們知道它是這個應用的靈魂，所以我們暫時忽略了Milestone，Todo-list，以及其他功能。這讓我們基於真實的使用情況來決定下一步怎麼走，而不是憑空猜測。

從一個精簡，聰明的應用開始，然後讓它得到關注。就能開始在你構建的堅實基礎上添磚加瓦。


無所謂

只留精髓

對於「為什麼你們做這個而不做那個？」這種問題，我們青睞的回答總是「因為無所謂。」這個陳述表達了是什麼讓產品變得偉大。找出緊要的，略去其他。

當我們發佈Campfire時，我們從第一次嘗試此產品的人中聽到下面一些問題：

「為什麼只有每五分鐘才有時間戳？為什麼不是每一行聊天都有？ 回答：無所謂。有多少次你需要每秒或者每分鐘記錄談話內容？當然不是95%的情況下，5分鐘時間戳足夠了，因為任何更多的細節都不重要。

「為什麼你不允許粗體，斜體或者有色字體格式在聊天中出現？」回答：無所謂。如果你希望強調某事，使用可信賴的caps lock鍵，或者在詞語或者段落周圍投放幾個 * 字符。那些方法不需要額外的軟件，技術支援，處理能量，或者學習曲線。除此之外，在簡單的基於文本的聊天中重量級的格式無關緊要。

「為什麼你不顯示當前時間房間裡的總人數？」回答：無所謂。每個人的名字被列出來，所以你知道誰在那兒，但是12個還是16個人有什麼區別？如果它不改變你的行為，那麼無所謂。

這些功能如果有就更好麼？當然。但是他們是不可或缺的麼？他們真的重要麼？不是。這就是為什麼我們把他們刨除在外。最好的設計師和最好的程序員不是技能最好的，或者手指最敏捷的，或者用Photoshop用的神乎其神的人。他們是能夠決定什麼不重要的人。真正的收穫源自於此。

你的大部分時間浪費在無關緊要的東西上。如果你能拋棄不重要的工作和思考，你將會獲得不可思議的生產力。


從說「不」開始

不輕易實現功能

構建部分而不是殘缺不全的秘訣是說不

每一次你對一個功能說yes時，你正在收養一個小孩。你必須帶著你的孩子通過一連串事件（例如設計，實現，測試等）。一旦這個功能出現了，你就被拖住了後腿。盡量為客戶少發佈一個功能，再看客戶是否憤怒地離開。

不要成為 yes-man

不要輕易實現每個功能。而要讓每個功能證明自己，並且表明自己是倖存者。這就像加入搏擊會一樣（參考電影 Fight Club）。你應該只考慮那些好像為了能加入進來而站在走廊苦候了三天的功能。

這就是為什麼你從說「不」開始。每一個向我們提出的 — 或者我們自己提出的 — 新功能需求都遇到一個 NO。我們傾聽但是不採取行動。最初的回應是「不是現在」，如果一個需求或者功能不停的過來，我們知道這才是時候對它進一步觀察。然後，只在那時，我們才開始考慮實現這個功能。

當你不採納他們的功能建議時，你如何回復他們的抱怨呢？首當其衝的是，你要提醒他們為什麼他們喜歡這個應用。「你喜歡它因為我們說NO。你喜歡它因為它沒有做其他100件無關緊要的事情。你喜歡它因為它不試圖始終討好所有人。」

「我們不想要一千個功能」

關於iTunes音樂商店，Steve Jobs 私下為獨立唱片製作人做了一個小型的演講。我喜歡的瞬間是，當觀眾不停地舉手說：「可以做[x]麼？」，「你計劃添加[y]麼？」。最終Ｊｏｂｓ回答：「等等 — 放下你們的手。聽著：我知道關於iTunes應該具有很酷的特性你有一千個主意。我們也是。但是我們不想要一千個功能。那樣做很噁心。創新不是關於對每件事說yes。而是對每一件事說NO，除了至關重要的特性。」

—-Derek Sivers, president and programmer, CD Baby and HostBaby
(from Say NO by default)

隱藏的成本

看清功能的成本

即使一個新功能通過了對其說不的階段，你還需要去發現它隱藏的成本。

比如，我們應該注意到功能循環（帶來更多功能的功能）這種現象。我們曾經有一個需求是在Basecamp裡加上一個「會議標籤」。如果不仔細權衡這看上去好像很簡單。但是想想「會議標籤」需要的不同元素：地點、時間、房間號、人員、郵件邀請、日曆的整合、支持文檔等等。這還不包括修改推廣活動中的截圖、用戶預覽頁、常見問題及幫助頁、服務條款以及更多。在你還沒搞清楚它是怎麼回事之前，一個簡單的想法就像滾雪球一樣弄得你大傷腦筋。

對於每一個新功能你需要……


你能把握住它麼?

構建你有把握的

如果你發佈一個會員程序，你的系統能夠處理帳戶和支付問題麼？可能你應該只讓用戶根據會員身份通過信用卡支付，而不是讓他每個月撰寫，簽名，並且郵寄一張支票。

你能承受得起1G的免費空間麼？還是僅僅因為Google這麼作了？可能你應該從100M開始，或者只給付費用戶提供空間。

底線：構建你能夠掌握的產品和服務。許諾容易遵守難。確保你所作所為是在承擔範圍內 — 從組織，戰略和財政上


人本主義

為一般概念構建軟件，並且鼓勵人們創建自己的解決方案。

不要約束人的習慣。而是令軟件寬容的接納每個人自己的解決方案。給人們足以通過自己的方式解決他們自己的問題的能力。然後解決之。

當我們構建 Ta-da List的時候我們故意忽略掉了一堆東西。不能分配某人一個to-do，不能標記時間範圍，條目不能分類，等等。.

我們保持工具乾淨整潔,讓人們富有創造性。人們自己琢磨出了如何解決問題。 如果想要添加一個日期到代辦事宜項目,他們可以在該項目前添加 (至: 2006年4月7日) 。 如果想要添加分類,也可以在該項目前添加[圖書]。 理想嗎? 不 。 無限彈性? 是的。

如果我們試圖寫軟件專門處理這些情景, 我們就會使它在這些擔憂並不適用時的所有情況下，變得不怎麼有用。

把問題的根盡力處理好，然後走開。人們將會在你的總框架內找到自己的解決方案和約定。


忘掉功能需求

讓你的顧客提醒你什麼是最重要的

顧客想要一切在陽光下。 他們會用雪崩似的功能和特性要求淹沒你。看看我們的產品論壇，功能類別的要求總是蓋過其它要求一大截。

我們會聽到："這一點點額外的特徵" ，或 "這不難辦到"或"加入這個不是很簡單麼？"或"僅用短短幾秒鐘就可以把這個加進去" ,或 "如果你加上這個，我付兩倍的錢" ,等等。

當然,我們並沒責怪人們提出要求。我們鼓勵這樣,並想聽聽他們怎麼說。我們加入產品的幾乎一切,起初都是作為客戶的一個要求提出來的。但是,正如我們前面提到的,你的第一反應應該是一個No 。 所以,你究竟應該怎樣對待這些紛至沓來的要求呢? 你怎樣儲存它們?你如何管理它們? 你不需要，看完之後，把它們扔掉。

是啊,看完之後，扔掉,並且忘記它們。 聽起來像褻瀆了用戶,但其中真正重要的會不時冒泡，提醒你。 這些都是你唯一要記住的。 這些才是根本必要的。 不必為跟蹤和保留進來的每一請求而操心,讓你的客戶成為你的記憶倉庫. 如果它真的值得一記,他們就會提醒你,直到你不能忘記。

我們是如何得出這個結論的? 當我們第一次啟動 Basecamp 時，我們在Basecamp 的一個代辦事宜列表中跟蹤每一個主要功能的要求 。 當一個需求被某人重複提出後,我們就用一個額外的記號更新名單上的項目(II或III或IIII等) 。 我們計劃有一天我們要檢閱這份名單，並從被請求最多的功能開始依次實現之。

但事實是,我們從來沒有再去看它一遍。 我們已經知道下一步需要做什麼,因為我們的客戶在通過重複同樣的需求不斷提醒我們。 沒有必要留一份名單或進行太多分析,因為這一切都在實時發生。 當每天都被不停地提醒時， 你不可能忘記什麼是最重要的。

另外一件事要注意:不能因為有 X 人提出需要什麼,就把它列入你的產品功能。 有時不如只說不,並維持你心目中的產品。


抓住核心

問人們不想要什麼

大多數的軟件調查和研究都是圍繞人們想要的產品 。"你認為有還缺失什麼特徵？" ， "如果你可以加入一個功能,那會是多少?" ， "如何使這個產品對你更有用" ?

硬幣的另一面會是怎麼樣呢? 為什麼不問人們，不想要什麼? "如果你可以去掉其中一個功能,那會是哪個呢? " ，"你為啥不用? " ， "什麼讓你覺得最礙事？" 。

答案並不是「更多」。有時你對用戶最大的優惠就是把一些東西去掉，拿出來。

創新來自說不

[創新]來自說不,否定一千件事情,以確保我們不步入歧途或是試圖做得太多。我們總是在考慮進入新的市場,但是通過說不，可以讓我們集中精力做那些真正很重要的事情。

—史蒂夫.喬布斯, CEO, Apple (摘自： 蘋果創新的種子)

操作 第六章

一場把軟件運作起來的比賽

盡快地推出一個真實的產品

一個可運作的軟件是積蓄動力，整合團隊，去除行不通的點子的最佳方式。你必須從第一天開始就將它擺在首要位置。

做少一些功能，跳過一些細節，如果一些捷徑能加快軟件進度就大膽用，這些都是OK的。當你做下去的時候，你會對下一步的方向有更準確的把握。太多的故事，建模，甚至HTML演示都是比較虛的構想。一個運作著的軟件是真實的。

只有一個真實的，可操作的軟件才能拉近每個人對現實的理解和認同。避免了為一些草圖和段落爭得面紅耳赤，最終發現這些都是無謂的。同時，你也會發現有些你想像中無關痛癢的事情事實上是很重要的。

真實的產品導致真實的行動。這才是你走向真理之路。

辦實事能導致共識

當一群不一樣的人開始嘗試尋找和諧共鳴的時候...如果他們是一建立一個全方位的真實的產品那麼他們的意見總會趨於一致。當然，如果他們只是打打草稿或是生出一些點子的話是很難達成共識的。因此，當你真正開始做一個實在的產品時，共識就比較容易達成。

—Christopher Alexander, Professor of Architecture
(摘自 Contrasting Concepts of Harmony in Architecture（對比和諧建築中的概念）)

盡快地運作起來

我不認為我有參加過任何軟件項目，不管大的或小的，是從一段漫長的規劃討論起步，不求同步發展，而又能在進度，成本或功能上成功的。把寶貴的時間浪費在發明一些不必要的或難以實施的性能上是容易的，有趣的，僅此而已，別無益處。

這個道理適用於軟件開發的所有層面，「把一個產品搞起來」是一個靈活的思想。它不僅適用於一個整體的項目，微觀上也適用於小規模的組件開發。

當一個可操作的組件做成後，開發者就希望知道它是否能和應用程序配合，因此他們就會盡可能快的去用它。即使一開始組件的實施並不完全，這種初期的開發協作通常會產生一個比較規範的界面和一些物盡其用的功能。

—Matt Hamer, 開發者和產品經理, Kinja公司

沖洗一下再來過

在不斷反覆中工作著

別期望一開始就做得好。讓軟件自然成長，和軟件對話。讓它自然蛻變而進化。做為一個在線的軟件是不需要在完成後才推出的。設計一些界面，使用它們，分析它們，反覆地做。

與其停止在把一切都事先做好做對的思路上，不如在經反覆求證得出的分析判讀中前行。同時，你可以更快的推出一個積極的產品，因為你並不是一味追求一出門就完美的產品。結論是是由真實世界裡的反饋，真實的目標來引導你的注意重心。

反覆能解脫你

如果你知道過後總是要重來一遍，你就不需追求一開始就達完美。這種明瞭不管如何你總是得過後重新審視一些問題的理念，能引發你先把產品想法推出去看看是否可行的激情。

可能你比我聰明

可能你比我聰明的多。

這是完全有可能的。事實上，是非常有可能。但是，如果你像大多數人的話，那麼你就會像我一樣，在對看不見摸不著的東西的想像方面有困難。

人類極度善於對環境週遭的事物作出反應。一隻老虎走到房間裡時我們會驚慌失措，災難性的洪水過後我們懂得去清理。遺憾的是，我們在事先計劃方面，在理解我們行為帶來的後果方面，在重要事情的優先排序方面，卻很糟糕。

或許你是少數人中能把所有事情都把握在你的腦子裡的，但這也並不重要。

Web 2.0, 在這個時代我們預定每個人都已經開始使用網絡，這就為一些聰明的開發者運用人類行為的不確定性創造機會。怎麼說呢？就是在允許你的用戶告訴你他們想法的同時，留有空間去做改進。

最後那句同時也解釋了為什麼你應該以這種方式開發在線軟件，以怎樣的方式去推廣推出產品。

把你想做到的說清楚。確保各個環節無誤。然後就推出和進行改進。沒有哪個人自己一個能比大夥兒加起來更聰明。

—Seth Godin, 作家/企業家

從概念到實施

從靈感，到草稿，到HTML，到代碼

以下是我們Get Real（求實）的過程:

腦力激盪

先要有個點子。這產品要給我們帶來什麼？以Basecamp來說, 我們是要滿足自己的需要。我們想要用它來發佈項目的一些更新信息。我們希望能讓用戶一起參與。我們知道項目都有里程碑。我們希望能有個集中歸檔的地方讓大家能回過頭去溫習一些舊的東西。我們想要有個全局觀，從一定的高度來鳥瞰所有項目的進度。歸結起來，這些假想和一些其他設想打下了我們日後著手的基礎。

這個階段並不是有關一些實施的具體細節。這是一個大方向。軟件需要為我們做什麼？什麼時候才能知道它有用？確切的說我們要做出個什麼東西來？這是高階的理念，不是像素階段（細節）的推敲。在這個階段，那些細節是沒有意義的。

紙上草稿

草稿是迅速的，實用的和便宜的，這就恰恰是你想要開始的方式。塗些東西，畫些東西，方塊，圓圈，線條，什麼都行。把你腦子裡的想法搬到紙上。這階段的目標是把概念轉成一個界面設計的粗稿。這個階段完全是試驗性的。不存在什麼答案是錯誤的。

創建HTML頁面

做一個HTML版本的功能界面（或一個區間界面或流程界面，如果這麼做更合適的話）。發佈一個實在的東西，這樣一來大家就都可以看到它出現在屏幕上的樣子。

以Basecamp而言，我們先做「發佈一條信息」的界面，然後是「編輯信息」的界面，然後一步步下去。

先別寫任何程序代碼。只把HTML和CSS的框架搞出來。有關細節實施是後面的事。

上代碼編程

當模型框架看起來過得去又兼具一些足夠必要的功能時，就是開始上代碼編程的時候了。

在這整個過程中要記住保持機動彈性，要有多次反覆的思想準備。應該隨時有這個意識：捨棄某些已完成的步驟重新來過，如果成品看起來醜陋不堪。數次重複這個過程是很自然的。


遠離設置首選項

要幫你的客戶決定一些小處細節

假設你將面臨一個困難抉擇：在一個頁面上可以發佈多少條信息？你的第一反應可能是，「不如做個設置首選項，在那裡人們可以選擇25，50，或100條每頁」。這麼做可是一個方便自己之門。你必須要自己做一個決定。

設置首選項是一種逃避困難抉擇的方式

你不是運用你的專業去決定最佳的選擇，相反地把問題留給了客戶。表面看起來好像是你在幫客戶的忙，事實上你只是會使他們更忙（客戶自己已經是夠忙的了）。對客戶而言，面對無窮無盡的設置選項是一個很令人頭痛的問題，不是一件好事。客戶不應該去煩惱細枝末節 —當是你的責任的時候就不要讓別人去擔待。

設置選項也是邪惡的因為他們使軟件變得冗余。更多的選項就需要更多的編程代碼。而且你還要花額外的時間在測試和設計上。還有很多選項排序和顯示界面等你可能從來沒見過的東西。這意味著隱藏的軟件瑕疵：破碎的佈局，凌亂的表格，奇奇怪怪的頁面排序問題等等。

你要拿主意

替你的客戶下簡單的決定。這也是我們在Basecamp上用到的訣竅。每頁可發佈信息數是25條。項目總覽頁顯示最近的25條信息。信息反時序排（最新的在上面）。最新近的5個項目會顯示在控制面板上。不需要任何設置選項。它本來就該這樣。

是的，你有可能下了一個不太好的決斷。沒什麼大不了。如果事情發生了，人們會抱怨，會讓你知道。照樣，你可以做調整。Getting Real（求真求實）說的就都是有關能夠一路做靈活修改的道理。

做設置首選項是要付出代價的

事實證明，加設置首選項是有代價的。當然，有些首選項也有重要的作用 — 並且可能是關鍵的頁面職能。但每提供一個選項都有不菲的代價，你應當仔細考量其價值。很多的用戶和開發者都沒能理解這個道理，最終付出很大成本，寶貴的資本只帶來一點點的價值...我發現，如果你是信奉要靠設計優秀默認功能而不是懶惰地去添加設置首選項的人，那麼自然而然地你的總體UI（用戶界面）會走上正確的道路。

—Havoc Pennington, 首席技術指導, Red Hat (from Free software and good user interfaces （自由軟件和優秀用戶界面）)

"搞定!"

決定都是暫時的，那麼拿定主意就繼續到下一步

搞定。現在就開始把它看成一個有魔力的詞。當你到達「搞定」的階段就表明你已完成某事。一個決定已經下了，走下一步。「搞定」也表明你已經聚集了能量。

慢著，如果你搞砸了，下了一個錯誤的決定怎麼辦？沒問題。 這並不是什麼開顱手術，它是一個在線應用程序。 我們一再強調，在開發過程中你總是需要不時回過頭去調整軟件的功能及想法。不管你計劃得多周密總有可能一半左右的東西沒做好。所以，不要做「到死都要調查分析」的傻事。那樣做只會慢了進度和磨去意志。

相反地，要知道以「朝前看向前走」為重。要跟上拿主意的節拍。做一個迅速簡單的決斷，如果它行不通那就再回頭修改。

要接受多數決斷都是暫時的有時效性的現實。要接受錯誤必將發生的現實，同時也要認識到這並不是什麼大不了的，只要你能迅速改正之。執行，積蓄能量，而後前行。

做一個執行者

當我聽說有人對自己的點子很具保護性時覺得很可笑。（那些在告訴我一些簡單的概念之前希望我簽定保密協定的人。）

對我而言，如果不去執行的話點子是一無用處的。它們只是倍數。執行才是價值萬金的。

理由:

  • 糟糕的點子 = -1
  • 脆弱的點子 = 1
  • 普通的點子 = 5
  • 好點子 = 10
  • 偉大的點子 = 15
  • 超閃亮的點子 = 20
  • 沒有執行 = $1
  • 柔弱的執行 = $1000
  • 普通的執行 = $10,000
  • 好的執行 = $100,000
  • 偉大的執行 = $1,000,000
  • 超強的執行 = $10,000,000

如果要成就一番事業，你必須將二者相乘。

最閃亮的點子，如果沒有執行，最多值$20。如果它乘以優秀的執行，那麼就值$20,000,000。

那就是為什麼我不愛聽他人的點子。只有當看到它被確實執行下去了我才有興趣。

—Derek Sivers， 總裁，程序員， CD Baby公司 and HostBaby公司

放飛去讓大眾測試

在現實使用中測試你的軟件

讓真人在真實的環境中使用你的軟件，這是無可代替的。取得真實的數據。取得真實的反饋。然後在那些信息的基礎上進行改進。

常規的可行性測試太死板了。實驗室的設置並不能反應現實。如果你站在別人的背後觀察監視，你可能多少瞭解一個方案是否行得通，但人們普遍在攝像機面前無法自然表現。當被別人這麼看時，大家都會很小心地不去犯錯 — 但錯誤卻正是你所要獲知的信息。

相反，在正式軟件中發放beta功能給一些有選擇的用戶。讓他們能同時使用beta功能和已發佈的功能。這樣這些測試的功能就能曝露在真實的數據和流程中。從這你就能取得真實的數據。

另外，不要搞正式版和beta版的遊戲。兩者不應該有區別。另外做一個beta版本只會得到一個輕描淡寫的試用。正式版本，注入一些beta的功能，才能得到全方位的體驗。

Beta書的發佈

如果開發者在發佈代碼的時候都很緊張，那麼書的發行商和作者在推出一本書時豈不得嚇死。當一部書付諸印刷時，要做修改是一件無比麻煩的事。（事實上並非如此，但這些和舊技術聯繫在一起的感覺和記憶還瀰漫在行業中。）因此，發行商總是花很大的功夫（和成本）要在書發行前爭取把書做到「對」為止。

當我寫Agile Web Development With Rails（使用Rail的敏捷 Web 開發）這本書時，很多的開發者有相當明確的需求：我們現在就需要這書 — 我們想要知道更多有關Rails。我也可能從出版商的角度出發。「它還沒完成」，我會這麼說。但來自社區壓力和David Heinemeier Hansson的督促使我改變了想法。我們在書最後完成前兩個月以pdf的格式預先發佈了這書。結果是令人難以置信的。我們不僅賣了很多書，而且得到了反饋 — 許多的反饋意見。我開發了一個自動化系統來攫取讀者發佈的看法，最終得到差不多850個有關錯字和技術錯誤的報告，另有添加新內容的建議。所有這些的解決方案都濃入到最後的書面出版中。

這是一個雙贏的局面：我能提交一個完善了的紙面出版書籍，社區也能及早地得到他們需要的內容。如果你是在一場賽跑競爭中，早些把作品交出去可以爭取更多的追隨者而不是過後引來更多的競爭對手。

—Dave Thomas, The Pragmatic Programmers（《程序員修煉之道》）

要快

  • 1. 決定它是否值得做，如果是的話:
  • 2. 盡快去做 — 不需完美，只需做下去
  • 3. 保存。上傳。發佈。
  • 4. 看人們的反應

雖然我並不總愛給產品加新功能，但一旦那個值得去做的"yeah!"時刻到來，新的功能一般幾個小時後就能上到網頁上去，有瑕疵但就這麼發佈了，讓用戶反饋來引導下一步的修補工作。

—Derek Sivers, 總裁，程序員，CD Baby公司和HostBaby公司

縮短你的時間

把它分塊來做

做幾周甚至幾個月的預期是不現實的。事實上你無法預見那麼遠的將來會發生什麼狀況。

所以，縮短你的時間範圍。把一個時間段分成一個個小塊。把一個12周項目看成是12個周項目。與其去推演一個要花30個工作小時的任務，不如把它們分成更現實的6-10個小時的小任務。然後一塊一塊地去執行。

這個理論同樣適用與其它問題。你是否有碰到一個很大的問題想都想不過來？把它劃分開來想。就這麼一直把問題分成小塊及更小塊直到你能消化它為止。

小一些的任務和時間表

軟件開發者是一群特殊的樂觀主義物種：面對放在他們面前的編程任務時，他們總會想，「那不難！花不了多少時間。」

所以，如果給一個程序員3周去完成一個大型任務，她會花兩周半拖拉，然後用一周的時間在編程上。這種不按期執行結果就會造成和預期任務要求脫節，因為每個任務總是會比表面看起來更複雜。還有，誰還記得三周前整個團隊達成的詳細共識是什麼？

給程序員一個下午去編一個小的特定的模塊，她就會有辦法把它趕出來，然後準備進入到下一個任務。

小一些的任務和時間表比較好管理，可以省去一些可能由於繁多產生的誤解，同時你改變主意或重新做的成本也會較小。小一些的時間表可以督促開發者，讓他們更有機會去享受某種成就感，同時不讓他們有更多的理由去想，「哦，我還有很多時間去做那個項目。現在讓我給我iTunes寶庫裡的歌曲評評級先。」

—Gina Trapani, 網頁開發者，編輯 Lifehacker, the productivity and software guide（效率和軟件指南）

事實的真相

下次如果有人硬要你回答一個答案尚未可知的問題 — 不管它是有關一個截止日，一個項目的最終成本，或填滿Grand Canyon（大峽谷）需要多少牛奶 —這類不發生無法知道的問題，你儘管可以從避免空談的角度出發：說「我不知道」。

這不僅遠不會毀壞你的信用，同時能顯示你對下決定的慎重和用心。不要只說些聽起來精明的話。你還需平衡遊戲規則，將問題重整成有利協同合作的對話。通過對你的預期所能達到的效果的逐步明確化的討論，你就能和其他人一起打造一個共識的平台，揭開數字背後的真相。

—Merlin Mann, 創造者和編輯， 43folders.com

解決衝著你來的那個問題

近來我的網絡記憶中最自豪的一件事就是發佈和引進"nofollow（譯者注，一個HTML屬性值）"的態度。沒人事先討論過它。沒有一大堆的會議座談可以讓一些無聊人用來進行其含義和編程本質的爭論。沒有徵求意見的過程，於是不需要把一個簡單的理念做成得花上20行xml的小程序（還得花時間解讀如何用這個程序，最終結果就是不用它，因為我不清楚是否設定在版本0.3或3.3b）。

它簡單，有效，只提供選項給需要的人 — 這對於網絡中不在乎技術規格的框框條條或覺得遵禮節太費時的一群，無疑是非常重要的。

有時，解決後來的20個難題往往不如搞定直衝你來的那一個問題來得有用和審慎。它不僅僅是一個戰勝濫碼的一個小勝利（所有和冗余代碼的鬥爭勝利都不會是大的），而且是對那些熱愛簡潔和迅速的結果並以之為己任的網頁開發者的一個大勝仗。

—Andre Torrez, 程序員和副總工程師， Federated Media Publishing

組織 第七章

一致性

拒絕分隔

很多公司將設計，開發，廣告撰寫，支持和營銷分隔成不同的戰鬥單位。雖然專業化有它的好處，但是它創作的環境卻讓員工只看到自己的小世界而不是web應用的整個背景。

盡你所能的，整合你的團隊，這樣才能有一個健康的，反覆的討論貫穿整個流程。建立一個制約平衡的系統。不要讓事情在翻譯中迷失。讓廣告撰寫者和設計者一起工作。支持的疑問一定要讓開發者看到。

更好的情況是，僱用擁有多項天賦的人，他們可以在開發過程中擔任不同的角色。最終的結果是一個更加協調的產品。


獨處的時間

為了讓事情做好，人們需要不被打擾的時間

37signals跨越4個城市和8個時區。從猶他州的普羅沃到代碼的哥本哈根。我們五個人分隔了8個小時。這8個小時的距離的一個積極的副作用是獨處的時間。

一天中只有四到五個小時我們都醒著並在一起工作。其他的時間，美國團隊在睡覺而David，人在丹麥，在工作。剩下的時間，我們在工作而David在睡覺。這讓我們一天中一半在一起而另一半獨處。

猜猜在一天中哪一部分完成我們完成的工作最多？獨處的那部分。這沒有什麼驚奇的。很多人喜歡的工作時間是清晨或者午夜 — 他們不會被打擾的時間。

如果你有很長時間沒有被打擾，你就能漸入佳境。這個情境是你最有生產力的時間；這個時間內你不必在各種各樣的任務中切換思維；這個時間你不會受到干擾，比如回答問題或者是查找東西，發送郵件或者應答即時通訊。獨處的時區是產生真正進展的地方。

漸入佳境需要時間。這就是為什麼干擾是你的敵人。這就像深度睡眠 — 你並不直接進入深度睡眠，你先進入淺睡眠，然後你會逐漸進入深度睡眠。任何干擾都會讓你從頭開始。深度睡眠是真正的睡眠魔法發生的地方；獨處的時間是真正的開發魔法發生的地方。

在工作中建立一條規定：一天中一半的時間作為獨處時間。從上午10點到下午兩點，任何人都不可以和別人談話（除了午餐時間）。或者讓一天的前一半或者後一半作為獨處時間。只要保證這個範圍是連續的，為了避免破壞生產力的干擾。

成功的獨處時間意味著趕走交流癡迷。在獨處時間中，放棄即時通訊，電話呼叫和會議。不要打開隨時更新的email程序。只需閉上嘴去幹活。（Just shut up and get to work.）

進入最佳狀態

我們都知道知識工作者在穩定狀態工作最出色，這種狀態也被稱作「漸入佳境」，他們全神貫注於工作，開足馬力，忘了周圍的環境。他們忘了時間的流逝，在絕對的集中精力下產生了巨大的成果...那番在於這種情境太容易被破壞。噪聲，電話呼叫，吃午餐，需要開車5分鐘去星巴克喝咖啡還有合作者的打擾 — 特別是合作者的打擾 — 都破壞了這個情境。如果你需要花一份鍾處理合作者問問題的干擾，這足以破壞你的集中經歷，那麼你需要花費一個小時重新達到有效率，你的總生產力變得很糟糕。

—Joel Spolsky, 軟件開發者, Fog Creek Software
(摘自 這些人從哪裡得到他們(非原創的) 思想?)

會議有毒

不要會議

你真的需要會議嗎？會議經常出現在概念不夠清楚的時候。不要求助於會議，試著簡化概念，於是你可以快速的討論它，通過電子郵件，即時通訊或者Campfire。目標就是避免會議。你避免花費在會議上的每一分鐘是你真正做事情的每一分鐘。

對於生產力的毒性沒有比會議更厲害的了。以下是幾點原因：

在你確實地必須 開會（這必須是一個少見的事情）的時候 , 堅持這些簡單的原則：

少開會

有太多的會議了。放棄那些沒有意義的和沒有效果的會議。只有當需要討論重要的商務議題的時候或者你需要建議，贊同或者一致意見的時候才召開會議。即便如此，不要不加選擇的邀請人 — 不要不必要的浪費人們的時間。

—Lisa Haneberg, 作者 (摘自 不要讓會議統治你！)

分解它

當子昂目增長的時候，增加人員帶來了減少的回報。最有趣的原因之一就是增加的交流通道的數量。兩個人只需要相互溝通；只有一條簡單的交流途徑。三個人有三條交流途徑；4個人有6條。事實上，交流途徑的增長是指數級的……很快，備忘錄和會議匯佔據整個工作時間。

解決方法是明顯的：把團隊分解成小的，自治的和獨立的小單位以減少這些交流途徑。

詳細的，把程序也分解成更小的單位。既然問題的一大部分起源於相互的依賴（全局變量，函數間傳送的數據，共享的硬件等等），找一個方法分割程序以消滅— 或者減少— 個體間的相互依賴。

—The Ganssle Group (from Keep It Small)

尋找和慶祝小的勝利

每天發行點什麼

軟件開發中最重要的就是激勵。激勵是局部的 -- 如果你沒有被你正在做的事所激勵， 機會就沒有應有的那麼好。 實際上，很有可能變得更糟糕。

冗長，滯後的發佈週期是激勵的殺手。 這使得慶祝活動之間間隔太長的時間。 另一方面， 可以慶祝的迅速勝利是極大的激勵動因。 如果你讓冗長的發佈週期壓碎迅速的勝利，就殺死了激勵。 並且這樣也會殺死你的產品。

所以， 如果你的發佈週期是在一個月以內， 拿出每週一天（或者沒2周拿出一天）對取得的小勝利進行慶祝。 並捫心自問： 「我們可以在4個小時內發佈些什麼？」 ， 然後去實現它。 這可以是

當你發現這些 4小時的迅速勝利時， 你將發現慶祝的理由。 這樣鼓舞了士氣， 增強了激勵 並且 再次肯定了團隊正在向著正確的方向前進。


人員配備 第八章

不需過早招聘太多員工

慢慢加人迅速發展

初期後期都並不一定要壯大隊伍。即使你接觸過100個頂級人才，一口氣把他們全招來也並不是什麼好主意。沒有辦法能讓這麼多人迅速的融入到統一的企業文化中去。你將遭遇令人頭痛的人員培訓、性格不和、溝通不暢、發展方向不同等諸多麻煩。

所以不要隨便招人。真的。不要招人，另想辦法。讓你陷入煩惱的這件事是真正必要的嗎？你不做又會如何呢？能不能用某種軟件或者改變做事方法來解決呢？

ge前執行總裁Jack Welch每次裁掉一個人之後並不會馬上招人來頂替他的位置。他想看看在那個職位和人員空缺的情況下能支撐多久。我們當然不主張用裁人來驗證這個理論，但是我們的確認為Jack的做法有一定道理：你並不需要你考慮中的那麼多人手。

如果沒別的辦法再考慮招人。但是你應該清楚知道你需要什麼樣的人，怎麼向他介紹工作任務，以及具體要他負責解決什麼樣的棘手問題。

Brooks的原則

給延期的軟件開發項目添加人手只會更加拖延進度。

—Fred Brooks

編程與莫扎特的安魂曲

一個優秀的程序員在完成單個工作任務時不存在因溝通和分工而產生的額外開銷。而五個程序員坐到一起完成同一個任務的時候必須分工合作，那將花費很多時間……用很多一般的程序員而不是幾個足夠好的程序員將產生的真正問題在於：無論讓他們幹上多久，也絕對沒有優秀程序員幹得出色。五個Antonio Salieris也永遠寫不出莫扎特的安魂曲，哪怕給他們100年的時間。

—Joel Spolsky, Fog Creek Software的軟件開發人員 (摘自Hitting the High Notes)

摸底

先和候選員工在測試項目中協作

看作品、簡歷、例程、工作經歷是一碼事，和他在一起工作是另外一碼事。只要有條件，應該和准團隊成員一起去「試試車」。

在聘用人之前，我們會給他們一個小項目琢磨琢磨。我們能從中看出他們怎麼管理這個項目，他們怎樣進行溝通，他們具體怎麼做等等。和他們一起設計或者編寫幾屏代碼能看出很多東西。你能迅速摸清和他們是否心有靈犀。

這種事規劃起來比較難，但即使只能拿出20或者40小時來做也比沒有強。適合不適合都能看得很清楚。如果不適合，先摸清情況能給雙方避免很多麻煩和風險。

小處著手

從分派一個小的測試任務開始。不要一股腦把你的工作任務都拿出來。給你的新虛擬助理一兩個測試項目來做，看看化學作用如何發生。開始的時候，大家很容易在和和氣氣的氛圍中忽略掉潛在的問題。記住這只是在試車。

—Suzanne Falter-Barns, 作家和創意專家
(摘自How To Find And Keep The Perfect VA)

行勝於言

根據對開源社區的貢獻選擇潛在的技術人才

典型的通過學歷、簡歷等方式來招聘技術人員在很多方面都是很愚蠢的。應聘者畢業於什麼學校、學習成績如何真的那麼重要嗎？一份簡歷或介紹信真能信得過嗎？

開源社區是為那些需要招聘技術人員的人準備的禮物。通過開源社區，你可以在很長的時間跨度裡跟蹤某人的成果和貢獻，無論好壞。

這意味著你能以他做過什麼而不是說過什麼來判斷他是否合適。你可以通過考察真正重要的方面來做決定：

說到程序員，我們只聘用通過開源社區認識的人。我們認為其他任何方式都是不負責任的。我們聘用Jamis是因為我們關注過他在Ruby社區的參與程度和發佈成果。他在前文所述的各個方面都做得很好。不需要次要原因，我們只評判真正重要的——他的工作質量。

不用擔心團隊成員「課外活動」的活躍度帶走他們的注意力和工作熱情。有句老話是這麼講的：如果你想做好一件事，去找你所認識的最忙的人。Jamis 和David兩個都是對Rails 社區有重大貢獻的人，同時，他倆還駕馭著37signals的技術部門。熱愛編程並且能幹活的人就是你真正需要的團隊成員。

對開源社區的熱情

你最希望從新員工身上看到的就是他對自己工作任務的熱情，而最能看出這點的辦法就是在開源項目中去追溯他的提交記錄。

—Jarkko Laine, 軟件開發人員
(from Reduce the risk, hire from open source)

尋找全面發展的人

選擇能快速學習的多面手，而不是專攻一面的專家。

我們從來不會用一個信息架構師。那實在太狹隘了。對於我們這樣的小團隊，招技術層面那麼窄的人沒用。

小團隊需要能扮演不同角色的人。你需要會編程的設計師。你需要懂設計的程序員。每個人都應該對怎麼構建信息（無論它指的是什麼）有自己的想法。每個人都應該思路清晰。每個人都需要能和客戶打交道。

而且每個人都需要能」在路上換檔「。要記住小團隊經常需要迅速改變前進方向。你需要有人能持續的調整和學習，而不是故步自封，只會幹一件事。


熱情是裝不出來的

選擇快樂的和技術水平中等的，而不是令人不滿的專家

熱情，是無法偽裝的。招人的時候，不要認為你需要一個技術大師或者技術名流。他們往往自以為是。一個水平說得過去的快樂員工勝過於愁眉苦臉的專家。

尋找充滿熱情的人；尋找你信任他可以獨立完成任務的人；尋找在發展緩慢的大公司受過折磨，並且渴望新環境的人；尋找為一起去建造你正在建造的東西而感到激動的人；尋找對你所厭惡的事物同樣感到厭惡的人；尋找為入你的伙而感到興奮不已的人。

為提問加分

留意候選人是否對你的項目提出很多疑問。熱心的程序員總是想盡量去理解存在很多疑點的問題並快速提出可能的解決辦法和改進方案。闡明問題能產生一種認識：項目的做法很多，但基本上取決於你對你的Web應用如何運作的想像。當你深入到細節，你能感覺到這個人是否在文化水平上符合。

—Eric Stephens, BuildV1.com

煉字師

招文字功底好的人

如果你在琢磨從幾個人選中挑出哪一個來填補空缺，選文字功底好的那位。無論他是設計師、程序員、市場人員、銷售人員還是其他，寫作技巧都很有用。簡潔高效的寫作和文字編輯能力可以帶來簡潔高效的代碼、設計、郵件、即時信息以及更多。

這是因為要當好寫手並不只是堆砌詞藻。好寫手懂得溝通的技巧，他們讓事情易於理解，他們能站在別人的立場考慮問題，他們知道什麼是可以忽略的，他們思路清晰。而這正是你需要的才能。

條理清晰的頭腦

好的寫作風格是頭腦清晰的指示器，清晰的頭腦能有條絮地梳理信息和論點，還能幫助（而不是逼著）其他人去理解。這種技巧能滲透到代碼的編寫、口頭表達、即時通信（對於那些遠程協作的人來說），甚至更深層次的職業素養和可靠性等領域。

—Dustin J. Mitchell, 開發人員 (摘自Signal vs. Noise)

有清晰的文字才有清晰的思路

清晰的文字能帶來清晰的思路。表達它的時候你才知道你對它瞭解些什麼。好的寫作風格也從一定程度上反映出人的性格。讓讀者省事，而不是給自己省事。

—Michael A. Covington, 佐治亞州立大學計算機科學教授
(摘自How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily)

界面設計 第九章

界面先行

開始編程之前先設計界面

很多應用人們在開始做的時候都抱著先編程的心態——那是個壞主意。編程是構建應用的過程中最笨重的部分，也就是說，它改動起來最複雜，成本也最高。做應用應該始於界面設計。

界面設計相對來說是比較輕量級的。一紙草圖修改起來簡單，成本也低。html頁面的設計修改起來或是推翻也比較簡單。修改程序就不是這麼回事了。界面先行可以讓你保持靈活；先行編程則會讓你陷入花費額外開銷的圈套。

界面設計先行的另一個原因是——界面就是你的產品。你向人們銷售的產品正是他們能看到的。如果你最後才推出界面，就會出現缺口。

我們先從界面開始，所以從一開始我們就知道這個應用看上去如何，給人感覺怎樣。在開發過程中，界面將會不斷的改進。合理嗎？易用嗎？是不是解決了手裡的問題？這些問題只有你和真實的界面打交道的時候才能回答。設計優先讓你保持靈活而且讓你能更早地回答那些問題。

開創Blinksale的橙色鋼筆

當我意識到現有的帳單管理軟件都無法讓我滿意的時候，我決心把我想要的帳單管理解決方案畫出來。我拿出一支橙色鋼筆，因為它是那晚上唯一好用的東西，然後我用了幾小時畫出了75％的用戶界面。我把它拿給我妻子Rachel看，當時她正在燙衣服，我問她：「你覺得怎麼樣？」她微笑著回答：「你真該把它實實在在的做出來。」

接下來的兩個星期裡我重新斟酌了設計，並且做好了當時可能成為Blinksale第一版的大部分靜態頁面。除了那些用橙色鋼筆畫的草圖，我們從來沒有做過其它網格之類的東西。而且直接進入html頁面的設計讓我們一直為項目變得現實起來而感到激動，即使在當時我們並不知道我們正在陷入什麼當中。

html頁面一完成，我們就和開發員Scott一起商量關於Blinksale的想法。已經設計好的用戶界面在好些層面都發揮了非常好的作用。首先，它讓Scott能親眼看到，使他為我們的目標感到激動。它遠遠不止是一個創意，它是真實的。其次，它幫助我們可以精確衡量Scott需要花多長時間和精力才能把設計變成能跑的應用。當你在對一個項目的孵化提供資金上的支持，越早能做出預算越好。界面設計成為了我們在項目初期的評估基準。最後，用戶界面的設計就像一個嚮導，能在我們進一步開發的時候提醒我們這個應用程序的核心目標。當我們臨時決定添加新功能的時候，我們不能簡單地說：「好的，那就加吧！」我們必須回到設計上來，問自己新功能應該放在哪，如果沒有它的位置，它就不該加。

—Josh Williams, Blinksale創始人

震中設計

始於頁面的核心然後向外延展

震中設計就是關注於頁面的本質——震中，然後再向外拓展。這意味著，一開始要忽略細枝末節的東西：導航條或者導航標籤、頁腳、用色、邊欄、標識等，從震中著手，先設計頁面中最重要的內容。

頁面賴以生存的是其核心。舉例來說，如果你正在設計顯示博客文章的頁面，那麼核心就是博客文章本身。不是在邊欄裡的文章分類，不是頂部的頁頭，不是底部的評論提交表單，而是實際的博客文章單元。沒有博客文章單元，這就不是一個博客文章頁。

只有當這個單元完成之後你才能開始考慮頁面中次重要的元素。次重要的元素完成之後，你再轉戰第三重要的元素，以此類推。這就是震中設計。

震中設計規避了傳統中 「先搭建框架，再填充內容」的方式。在那種方式裡，人們先建立好頁面佈局，然後把導航條包含進去，然後插入有關銷售推廣方面的東西，到最後才把核心功能——頁面的實際意義所在用來填充剩下的空間。這是本末倒置的做法。

震中設計讓你從一開始就關注於真正重要的部分。先做必需要的，再做其他的。結果是給用戶一個更友好、重點清晰的界面。並且，這樣可以讓你馬上和設計、開發人員展開對話而不是等到頁面所有部分都各就各位之後。


考慮三種情況下的解決方案

常規、初始、錯誤三種情況下的設計

對於每一個界面，你需要考慮可能出現的三種情況：

常規的情況眾人皆知，它將花去你最多的時間。但別忘了也要為初始和錯誤兩種情況花些時間（接下來的文章作更詳細地說明）。


初始界面

期待一個周到的初次運行體驗

忽略初始界面的階段是你會犯的最大錯誤之一。初始界面是應用留給人們的第一印象，永遠不會有第二次這樣的機會……這個麼，你應該知道。

問題是，設計界面時，通常是事先用數據填充起來。設計者總是用臨時數據填滿頁面模板，每一個列表、文章、輸入框、邊邊角角里都填上內容。這時候界面看上去很棒。

然而，產品在初始狀態下是沒有內容的。當新人註冊，他們將從初始界面開始。就像是一個博客，用戶需要自己去充實它。而在用戶輸入文章內容、鏈接、評論、日期、邊欄的信息或其它數據前，整體外觀無法成形。

不幸的是，用戶會在初始界面時決定產品是否值得一用——在這個內容和信息最少的階段來判斷產品的適用性。如果你設計的初始界面有缺陷，人們就不知道缺少些什麼，因為他們感覺什麼都沒有。

然而大多數設計者和開發人員仍然認為這種狀況理所當然。他們沒有很多時間為初始界面做設計，因為當他們開發和使用產品的時候，裡面填滿了他們用來測試的數據。他們甚至沒遭遇過初始界面。當然，他們可能也以新用戶的身份登錄過幾次，不過他們主要的時間是沉浸在一個充滿數據的產品裡。

一個有用的初始界面應該包含些什麼？

第一印象太關鍵了。如果沒有設計出周到的初始界面，會為你的產品或服務留下反面的（錯誤的）印象。

沒有第二次機會……

我覺得蘋果OS x操作系統的界面中另一個深受Steven Jobs影響的是安裝和初次運行的體驗。我想Jobs一定深深理解到第一印象的重要性……也許Jobs在考慮初次運行的體驗時會想，它可能是一個用戶對電腦上千次用戶體驗中的一次，但是它將是最重要的千分之一，因為它是一千次中的第一次，人們對它寄予了期望並形成初步印象。

—John Gruber, 撰稿人和開發人員 (摘自 Interview with John Gruber)

做好防禦

出錯時的設計

我們得承認：在線上的程序總有出錯的情況。無論應用設計得多麼用心，無論做了多少測試，用戶仍然會遇到問題。那麼如何處理這些不可避免的故障呢？做好保護性設計。

保護性設計就像是在小心駕駛。和司機在行車時必須留意道路是否打滑、魯莽的司機以及其它危險情況一樣，網站建設者們必須不斷尋找會造成訪問者困惑和不滿的故障點。好的保護性設計能決定用戶體驗的好壞。

關於保護性設計的內容我們可以單獨寫成一本書。實際上，我們已經寫了。這本叫《網站的保護性設計》的書對於想學習如何改進出錯界面和其他故障點的人來說是非常好的資源。

記住：你的應用可能90％的時間都運行良好。但是如果在用戶需要幫助時置之不理，他們是不會忘記這一點的。


應用環境勝過一致性

這裡有意義的那裡不一定有意義

動作是使用 按鈕 還是用 鏈接 來實現 ？ 這取決於那個動作。 一個日曆視圖是應該使用列表方式還是表格方式實現？這取決於 它要用在哪裡 並且 要顯示多長的時間。 全局的導航鏈接是否需要出現在每個頁面上 ？ 是否每個地方都需要一個全局的搜索條 ？ 否在每一頁上需要一個完全相同的頁腳？ 答案是「這取決於應用環境」 。

這就是應用環境比一致性重要的原因。 如果你的設計在那種狀況下有意義， 不一致也沒有什麼大不了的。 只給人們重要的。 給他們所需要的，並且去掉其不需要的。 比保持一致性更好的是保持正確。

聰明的不一致

一致性不是必不可少的。 很多年來， 學習用戶界面和用戶交互的學生都這樣被教導，界面中的一致性是界面設計中的核心守則之一。也許這在軟件中成立，但是在Web上，這不對。 Web上真正重要的是，在每個獨立頁面，用戶是否能夠快速、簡單地前進到流程中的下一個步驟。

在 「好的創新」 （Creative Good）, 我們把這叫做「聰明的不一致」 ： 確保流程的每個頁面都給用戶提供他在流程中的那個位置所真正需要的東西。 只因為了和網站的其它部分保持一致，加入多餘的導航因素，是很愚蠢的。

—Mark Hurst, Creative Good 以及Goovite.com 的創辦人
(摘自： 頁面範式)

文案也是界面設計

每個字母都重要

文案也是界面設計，偉大的界面是寫出來的。 如果你認真考慮每個像素，每個圖標，每個字體， 那麼你要相信每個文字都是至關重要的。 當你寫界面時，要常常要設身處地的為閱讀你的界面的人著想。 他們需要瞭解什麼？ 你怎樣才能簡潔明瞭地闡述 ？

你標注一個按鈕的名字是 提交 還是 保存 或者 更新 還是 新建 或 創建 ？ 這就是文案。你是寫3句話還是5句？是用一般的舉例說明，還是詳細闡述？ 如何標注新內容？是 『新增的』 還是 『更新的』 抑或是 『最新更新』 還是 『修改的』 ？ 是使用：『新消息： 5』 還是 『5個新消息』？是 『5個』 還是 『五個』 ，是『5個消息』還是『5個帖子』？ 所有這些都很重要。

你也需要和你的讀者講同樣的語言。 只因為你寫的是一個Web應用，這並不意味著你可以使用技術行話。想想你的客戶，想想這些按鈕和詞語對其意味何如。 不要使用縮寫 或者 大多數人不懂的詞語。 不要使用內部隱語。不要聽起來像一個工程師和另一個工程師的談話。 保持簡短和親切。 說你要說的，別說廢話。

好的書寫就是好的設計。 界面用詞和設計要相輔相成，這很少有例外。 圖標要有名字， 表單項要有示例， 按鈕要有標籤，流程要有一步一步的指示， 退款政策也要有一個清楚的說明。這一切都是界面設計。


統一界面

合併管理功能到公共界面

管理界面—就是那些用來管理選項，人員等的屏幕界面。—看起來很低劣。這是因為大多數時間都花在了對公共界面的設計上。

為了避免 這種 低劣管理界面 的併發症， 不要分開去開發系統管理界面。 而要把管理功能（例如，編輯，增加，刪除）嵌入到應用界面開發中。

如果你必須維護2套分開的界面（如： 一個一般用戶用，另一個管理員用）， 這2個都會很難受。 實際情況就像同一個稅你交了2次。 你強迫自己重複 並且 這還意味著事情變麻煩的機會大大增加。

拒絕分離的界面

應用軟件就是全部。 所有可以被改變的，增加的 或者調整的，都應該直接通過應用的管理區域完成。這使得我們能精確感知我們客戶的需要，從而通過解決他們的問題和疑問來幫助他們。 我們的客戶也不必擔心，必須登入分開的界面來完成不同的工作。一分鐘前，他們也許在處理和客戶的約會，隨後一分鐘他們也許要添加新僱員。他們不會為了在不同的應用間跳來跳去而煩惱，通過一個統一的界面，他們能夠很快的適應這個應用軟件。

—Edward Knittel, KennelSource銷售和市場部總監

代碼 第十章

更少的軟件(Less software)

讓你的代碼盡可能簡單

你或許認為代碼量加倍軟件複雜性也相應加倍，但實際上，每增加一些代碼，軟件的複雜性就隨之指數式增長。代碼的每一點增加，每一點改動，每一個相依性，每一個前指性（Preference) 都有著聯動效應。輕率地增加代碼，不用多久，你就會造出一個可怕的大稀泥巴。

對付複雜性的辦法就是更少的軟件。更少的軟件意味著更少的特徵（features），更少的代碼和更少的浪費。

關鍵在於將每一個困難的問題（要求很多的軟件）重新描述成一個簡單的問題（要求少得多的軟件）。你解決的問題也許不是和原先百分之百一樣的問題，那也沒關係。用20%的努力解決原先問題的80%就是一個很大的勝利。原先的問題幾乎從來就沒有糟糕到值得花5倍的精力去解決。

更少的軟件意味著撇開水晶球。處理今天面對的問題而不是預測未來的問題。為什麼？對明天的恐懼常常是毫無結果的。不要讓幻想的問題把你拖住。

從一開始，我們就將產品的設計基於更少軟件的概念。只要可能，我們就將問題簡單化。我們發現，對簡單問題的解決方案不僅更容易實施和支持，也更容易理解和使用。這都是我們用來區別於競爭對手的做法的組成部分。我們造的產品要做更少，而不是做更多。

決定哪些特徵包括進去，那些特徵拒之門外，這也和更少軟件相關甚密。不要怕對難以實現的特徵說不。只要不是必不可少的基本特徵，就不要包括進來。這樣既省時省力，也減少混亂。

同時也要慢下來。把一個主意丟在一邊，平靜一個星期後，再看看這是否還是一個好主意。這額外的醞釀時間，常常會讓你想出一個更簡便的解決方案。

鼓勵程序員提出反建議
你想聽到："你建議的方法要花12小時，但我這樣做只需1小時，它不做x，但它做y。"讓軟件推你回來。告訴程序員用他們認為最好的方法去戰鬥。

還有，尋找可以避免編寫更多軟件的途徑。用屏幕文字的方式建議用戶繞道而行，從而避免對於軟件模型的更改。比如，建議用戶上載指定尺寸的圖片，而不是在服務器端作圖像處理。

對你的應用（app）中的每一個特徵，問問自己：有沒有不需要這麼多軟件的方法來加進這個特徵？只寫需要的代碼，不多不少。你的應用將會更簡練而健康。

沒有任何代碼比沒有代碼更靈活

好軟件設計的"秘密"不在於知道在代碼裡放什麼，而在於知道代碼裡不放什麼！這在於辨認出硬點和軟點在哪裡，還知道哪裡該留下空間而不是試圖塞進更多的設計。

—Brad Appleton, 軟件工程師
(摘自 There is No CODE that is more flexible than NO Code!)

複雜性和大小不成線性比例

打造軟件最重要也是最鮮為人知的規則：複雜性和大小不成線性比例…… 2000行的程序比1000行的程序要用多於兩倍的開發時間。

—The Ganssle Group (from Keep It Small)

為快樂而優化

選擇能讓你的團隊歡欣鼓舞的工具

快樂的程序員也是多產的程序員。這就是我們為什麼要為快樂而優化。你也應該這樣。不要單憑行業標準或性能指標來選擇開發工具和開發方法。看看無形的東西：這其中存在激情、驕傲和精湛技藝嗎？每天8小時在這樣的環境下工作真的會快樂嗎？

這一點在選擇編程語言上尤為重要。儘管與公眾看法相悖，編程語言並非個個生而平等。雖然幾乎每個語言都能寫出幾乎每一個應用，對口的那個（the right one）不僅僅是讓你的努力成為可能和可以忍受，而是讓你覺得愉快和充滿幹勁。這都是為了使得每天工作的小小細節快樂有趣。

快樂有聯動效應。快樂的程序員做正確的事情。他們寫出簡單易懂的編碼。他們採用簡潔、清晰、易懂和優雅的方法。他們樂在其中。

我們發現了使用語言Ruby編程的極致快感並通過我們的Rails框架（framework）將其傳遞到其他開發人員身上。Ruby 和 Rails都遵循為人類、為快樂而優化的信條。我們鼓勵你嘗試一下這對組合，給它們一個一展身手的機會。

總而言之，你的團隊需要使用他們喜愛的工具。我們這裡談的雖然只是有關編程語言，但其原理也適用於應用、平台和其它任何東西。選擇讓人們興奮的導火線，帶來激動和鼓舞，更好的產品也就接踵而至。

你要的那類工程師

我用Ruby On Rails來開發的最重要原因是：它是如此優雅、多產而又擁有美妙的設計。它吸引看重這些優點的那類工程師，並鼓舞他們用它創造出同樣的軟件。那真是你的團隊所要的。

—Charles Jolley, Nisus Software 管理總監 (摘自 Signal vs. Noise)

代碼在說話

當你的代碼將你打回，聆聽

聆聽你的代碼。它將提出建議。他將把你打回。它將告訴你毛病在那。他將建議新的做事方法。他將幫你遵循更少軟件的模式。

一個新特性需要幾個星期的時間和幾千行代碼？這是編碼在告訴你很可能有更佳的方法。有沒有簡單的方法讓你一小時完成代碼而不是需要十小時的複雜的方法？這又是代碼在指引著你。仔細聆聽。

你的代碼將引導你找到又便宜又輕易的修補辦法。在捷徑顯露出來時要倍加注意。當然了，容易做的特性也許與你原先所想的特性並不完全一致，那又何妨？只要它足以勝任，並且給你更多時間作別的事情，那就留著它。

聆聽

不要擔心設計，聆聽你的代碼，好設計也隨之而來。聽聽技術人員的話。如果他們抱怨改動太難，認真對待他們的抱怨並給他們足夠的時間去解決問題。

—Martin Fowler, ThoughtWorks 首席科學家 (摘自 Is Design Dead?)

假如給程序員付錢是讓他們刪除代碼……

假如給程序員付錢是讓他們刪除代碼而不是寫新的代碼，軟件將會好得多。

—Nicholas Negroponte, MIT 媒體技術教授
(摘自 And, the rest of the (AIGA Conference) story)

管理債務

還清你的代碼和設計"賬單"

我們通常將債務與金錢掛鉤，但債務還有別的形式。你可以很容易就拖欠代碼和設計的債務。

東拼西湊一些能用但讓人汗毛直豎的代碼，你就是在增加債務。隨便搞一個足夠好但並非真正好的設計，你還會再來一遍。

偶爾為之，不足為慮。實際上，它常常是你完成整個"迅速實現"事情所需的技巧。但還是應該認識到它是一筆債並需要在其他時候通過清理可怕的代碼和重新設計差強人意的頁面這種方式進行償還。

就像你該定期將部分收入納稅一樣，定期將一部分時間償還你的代碼和設計債務。否則，你只是付著利息（修理劣作），而不是償還本金（並邁步前行）。


開放門戶

讓數據通過 RSS，API等途徑走向世界

不要試圖鎖住你的客戶。客戶想什麼時候，以何種方式拿他們的數據都要悉聽尊便。要做到這一點，我們必須放棄將數據封存的念頭。而要讓數據遍地跑。讓人們通過 RSS Feed 取得他們的數據。提供 API 讓第三方開發商在你的工具上進行開發。這樣做不僅讓你的客戶的日子更好過，而且還擴大了你的應用所能做的事情的可能性。

過去人們常常認為 RSS Feed 只是用來跟蹤博客和新聞網站的好方法。但它要比這更強大。它也是客戶無需一次次地登錄就能獲得一個應用的內容最新變化的絕妙方法。Basecamp 的 RSS 使得用戶只需將 URL 放入新聞閱讀器（newsreader），從而無需頻繁登錄網站就可以留意項目信息、任務列表（to-do lists）和項目里程碑。

API 讓開發者為你的應用建造附加（add-on）產品。這些產品的價值很可能難以衡量。例如，Basepack 提供的 API 讓 Chipt Production 公司開發出在蘋果Mac OS X 上使用的任務欄組件（Dashboard widget）。這個小組件讓人們從桌面電腦增加、編輯提醒單（reminders），列表項和更多信息。客戶們對此欣喜若狂，甚至說這是促使他們使用 Backpack 的關鍵因素。

公司讓數據自由流動以獲得迴盪效應的其它好榜樣：

小組件造成的差別

早些時候 37signals 發行了 Backpack。我的第一印象是……呃……

所以一直到 Chipt Production 公司發行了一個為Mac OS X Tiger 操作系統開發的 Backpack 小組件 - 這個小組建實在超酷，不得不下載試用 - 我才對 Backpack 再瞧一眼。結果如何？差別可大了。

如今每當一個想法襲來，我就打開這個小組件，打字然後提交 - 成了。Email 帶來了我想查看的東西？打開小組件，打字然後提交 - 成了。在每一個我使用的蘋果電腦上這個小組件都可輕易獲取，它是一個即刻的"腦瓜扔"（brain dump，譯者註：思想收集簍）。因為所有事情都是基於網上，所以沒有什麼版本控制或者同步 - 只是內容的流暢輸入，無需擔心它去哪裡或以後怎樣訪問它。

—Todd Dominey, 創始人, Dominey Design
(摘自 Trying on Backpack)

文字 第十一章

功能定義一點用都沒有

不要寫功能定義文檔

這些藍圖文檔通常和成品幾乎毫無關係。理由如下：

功能定義文檔是虛幻的

功能定義文檔不反映真實情況。一個應用只有在被構造時、被設計時，和被使用時才是真實的。功能定義文檔只是紙上談兵

功能定義文檔是無關痛癢的

功能定義文檔可以用來讓人感受到參與的樂趣，措辭溫和但是並不是那麼有用。它們不關心艱難的抉擇，不關心成本——而這些正是建立一個成功的應用所必須考慮的。

功能定義文檔只能達成虛幻的共識

看文字並不能讓人們達成共識。大家可以讀到同樣的文字內容，但每個人的想法卻可能不同。以後將不可避免地發生這種情況：「等下，我不是那樣想的。」「啊？我們可不是這麼說的。」「是的，就是這樣的，我們大家都同意了——你還簽過字呢。」我相信，你知道該怎麼做。

功能定義文檔逼迫你在擁有最少資訊時作出最重要的決定

當你剛開始構建時，你知道的是最少的。而做得越多，用得越多，你才能瞭解得越多。這才是你應該做出決定的時候——即當你有足夠多信息，而非信息少的時候。

功能定義導致功能氾濫

功能定義階段對整個過程沒有什麼推動。寫點東西加個標注，看上去並不需要什麼代價。你可以加上他們欣賞的功能，讓那些令人頭疼的人高興。然後你按照那些寫下來的文字標注設計，而不是為人設計。最終你得到的將是一個擁有30個欄目的臃腫站點

功能定義讓你無法變通、變化和重新評估

一個功能一旦得到認同，即使在開發階段你就意識到它是個壞主意，你也不得不照做。一旦你開始做某事，一切都在變化，而定義卻不會去處理這些實際情況。

那麼，你應該做什麼去替代功能定義呢？ 去寫一個簡明的替代文檔，以此引導你去做那些真正的事。 寫一頁的說明去描述這個應用要做什麼。 使用平實的語言並且要簡短。 如果要闡述的內容超過了一頁紙，就太複雜了。 這個過程不應該超過一天。

接下來開始建立界面----界面將成為功能文檔的替代物。 在紙上簡單快速地畫些草圖。 然後把它寫成html代碼。 界面設計是每個人都會認同的共同基礎，這不同於，大段的文字可以有不同的理解。

人人都使用同樣的屏幕界面時， 混亂不見了。在你開始擔心後台代碼之前，要建立一個人人都可以看得見的，使用的，點擊訪問的，並且可以「感受到的」 界面。 一定要盡量把自己置於客戶體驗之前。

忘記那些鎖定的功能定義。 它們迫使你做大，在太早的時候逼你作關鍵決策。 略過功能定義階段，你將可以便於改變並且保持靈活性。

沒用的功能定義

「功能定義」幾近無用。 我還從來沒有見過一個足夠全面和足夠準確的功能定義文檔。

而且，我見過大量的基於功能定義（文檔）的無用功。 這真是寫軟件的唯一最壞途徑，這從它的定義就可以看出： 為了教條而寫軟件，而不是現實。

—Linus Torvalds, Linux之父 (摘自: Linux: Linus 談規格書))

和阻礙作鬥爭

我發現人們常常堅持在任何設計工作開始之前，要先準備大量的需求文檔， 這真是一些「阻礙」，使整個過程變慢。（這些人通常對設計沒有任何的貢獻和創新思維）

我們所有的最佳工作都是這樣做出來的， 我們把頭腦中的一些關於站點改進的想法， 先作一個（靜態）的快速原型， 再改動一點設計，然後使用真實數據建立一個活的原型。 在把原型上的一些累贅剔除以後，我們通常都會得到一個健康運轉的項目，並且取得很好的成果。

—Mark Gallagher, 公司內部網研發人員 (摘自 Signal vs. Noise)

別寫死文檔

根除不必要的文書工作

避免寫功能規格定義是一個好的開始,但不要僅只於此；要處處避免過分的寫文檔工作。除非有個文件確實要演變成現實, 否則別寫它。

建造出來,別寫出來。如果你需要解釋什麼,先建造一個原型而不是寫一份冗長的文檔。實際的界面或原型是你正在構建一個真正的產品的很好說明。另一方面,一紙文檔,只能說明它們終將被丟入垃圾桶。

這裡有一個例子:如果一個線框文件是注定要停止,並且永遠也不會直接變為實際設計,不要為此煩惱。而如果線框開始作為一個線框造型並且演變為實際設計,那就用它。

脫離實際應用而存在的文檔是沒用的。 它們對你沒有幫助。 你在作的所有事都應該最終變為真實存在的。 如果一個文檔在變為真實之前，就停止了，那它完蛋了。

誰也不會去讀它

我從不會去數在我們研發隊伍的身邊有多少這樣無聊的，未讀的，沾滿灰塵的，有很多頁的產品規格書或者業務需求文檔。 我們只管去編碼，討論問題，質疑和進行用戶測試。 我也和那些寫了好多冗長的，描述性的電子郵件或者編碼規範文檔的研發人員一起工作過， 同樣那些文檔也沒人讀過。

開發Web應用並不會因為有豐富的文檔就會一帆風順。 軟件開發是一個不斷變化的，反覆迭代過程，這其中包含著 相互作用， 快速決策 和一堆在前進路上不斷遇到的無法預測的問題。 這些沒有一個是能夠，也不應該在文檔中捕獲的。

不要浪費時間去堆砌這些冗長成冊的不實文檔； 沒人去讀它。 如果你給你的產品足夠的空間去成長，到最後這個產品無論如何也不像你寫到的那樣，這個事實應該是你得到安慰。

—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide

告訴我一個短故事

寫故事,別寫細節

如果你發現你確實需要來解釋一個新的特徵或概念,寫一個簡短的故事說明之. 別陷入技術或設計的細節,只講一個短故事. 像你在正常的交談時和一個人講話的方式一樣。

它並不需要成為一個短文。只要象記流水賬似說明發生什麼事。如果拿出你正在開發的屏幕作背景，來簡述這個故事,那就更好了。

堅持經驗,而不是越來越拘於細節。考慮戰略,而不是戰術。一旦你開始建立的你的那部分應用，戰術自然就會適得其所。現在你只是要想出一個故事,發起討論,然後使你步入正軌。


使用平實的語言

填入真實的文字而不是測試用的胡亂用語

測試用的胡亂文字（Lorem ipsum dolor）一直是設計者的忠實夥伴。 虛擬文字幫助人們認清設計完成後的觀感。但是這些虛擬文字會很危險。

測試用的胡亂文字改變了拷貝的視像。 使得文本內容弱化為一個視覺設計元素 --- 文本形狀 ---而不是其本來面目：有價值的某人錄入/或要讀的信息。 虛擬文本意味著你不會看到當真實信息錄入後出現的不可避免的改變。這意味著你不會知道在你的站點填寫表格時會是什麼樣子。 虛擬文字是隔在你和現實之間的面紗。

你需要真實的拷貝去認識某個字段要多長才合適； 你需要真實的拷貝去懂得表格是怎樣擴展或收縮的； 你需要真實的拷貝去感知你的應用看起來究竟怎麼樣。

只要有可能，你就要使用真實，準確的用語。 如果你的站點或應用需要數據輸入，那就錄入真正的交易數據。並且要敲入實際的文本--不要從其他來源拷貝粘貼。 如果那是一個姓名，就敲入一個真實的姓名。 如果是個城市， 錄入一個真正的城市。如果是一個密碼，就要重複2次，錄入2次。

確實，從上到下過一遍表格並把每項都填入垃圾數據（"asdsadklja" "123usadfjasld" "snaxn2q9e7"）是很簡單。但是這不真實。 你的客戶一定不會這樣使用。當客戶被強迫要長途跋涉時，你卻走捷徑，這能算是精明麼？ 當你用連發開火的方式快速錄入假數據時， 你根本不會體會到填表格時的真實感受。

像你的客戶那樣去做，你才能更好的理解他們。 當你更好的理解他們時， 你會感同身受，做出更好的界面。

胡亂用語垃圾

由於沒有想像力想出真實內容「大概」應該怎樣， 一項設計考慮因此丟失。「這裡該是文本」使得含義晦澀，因為沒誰意識到這些文本是要實際被讀到的，明白易懂性大打折扣。機會也會浪費，因為這些你使用的胡亂用語垃圾不是真實內容，你無法從中悟出機會。這些文本的作用很小，因為，不能這樣用，我們興許也可以創建一堆可愛的空格。

—Tom Smith, 設計師及開發人員 (摘自 我憎恨 Lorem Ipsum 和 Lorem Ipsum 使用者)

個性化你的產品

你的產品的個性類型是什麼？

把你的產品想像成一個人。 你要賦予他什麼個性類型？ 有禮貌？ 嚴肅的？ 慈悲的？ 精確的？ 有趣的？ 無表情的？ 認真的？ 自由的？ 你想它以怎樣的面目示人，是偏執的 還是令人信服的？ 是作為一個萬事通？ 抑或是謙遜並且人見人愛 ？

一旦你確定下來，就要在構建產品的過程中時刻記得保持這些個性特徵。利用這些個性指導拷貝寫作，界面設計 和 功能項配置。 一旦你想要改變什麼， 自問一下這會不會改變你的應用的個性特徵。

你的產品有聲音---會一天24小時的不停地與你的客戶交談。


定價和註冊 第十二章

免費樣品

免費贈送

外面的世界很嘈雜。為了讓人們在喧囂中注意到你，免費贈送一些東西吧。

聰明的公司都知道免費發贈品是吸引顧客的一個好方法。看看蘋果公司，他們提供免費的 iTunes 軟件，是為了建立客戶對iPod 和 iTunes 音樂存儲的需求。在網下的世界裡，零售商們也這麼做。星巴克公司認為，每送出5個飲料贈品，就刺激了一種新商品的購買。不要太小氣。

對於我們來說，Writeboard 和 Ta-da list 是完全免費的應用，用來吸引人們逐漸使用我們的其他產品。同時，對於我們所有的應用，我們總是提供一些免費的版本。

我們希望人們來體驗我們已經完成的產品、界面和有用的東西。一旦他們著迷了，就更有可能升級到一個付費產品（付費產品提供更多的項目或頁面，讓人們獲得更多的功能，比如：文件上傳和ssl數據加密）。

可吃尺寸的塊

做成可吃尺寸的塊： 專門設計的，較小的功能可以促使客戶來試用。 至少要把一個產品或服務再細分成很小的可吃尺寸的塊，這些小塊的功能花錢不多，簡單或者充滿樂趣。

—Ben McConnell 以及 Jackie Huba, 客戶博客的教堂的作者
(摘自： 什麼是客戶的福音布道?))

拿出你的最熱單曲

設想一下在你的每個專輯中拿出一首單曲作為免費獎勵，讓全世界下載 --- 就像電影的預告片 --- 就像送往電台的最熱單曲---使得人們想去買你的音樂。

不要擔心這首曲子被盜版。 讓人們去演奏， 去拷貝 ， 去共享 ，去分發。要有信心，一旦全世界都聽過，他們會付錢買更多。

—Derek Sivers, 董事長 兼 程序員 CD Baby and HostBaby (摘自： 免費促銷單曲)

來去自如

讓註冊和註銷的過程毫不費力

在你的程序裡註冊和註銷應該盡可能簡單。

如果我是一個客戶，想用你的產品，這應該是一個毫不費力、輕鬆容易的事。在銷售站點的每一頁都放上一個大大的、清楚的註冊按鈕。告訴大家這是多麼容易的事：「從註冊到登錄僅僅只需要1分鐘！」

應該總是有個自由選項，讓客戶不用輸入信用卡信息就能進行產品演示。有些公司需要用戶確認、預約或者特殊密碼才能體驗他們的產品，根本就沒有必要這麼做。任何人隨時都可以自由地體驗我們的產品而無須提供任何信息。

註冊表單要盡可能短。不要問一些並不需要的問題，不要拋出一個長得嚇人的表來為難大家。

這些原則同樣適用於註銷過程。永遠不要指望把人們「困在」你的產品裡。當有人決定註銷他們的Basecamp 帳戶時，儘管我們感到遺憾，但是我們不會讓註銷過程繁瑣或是含混不清。個人帳戶頁就有一個「註銷我的帳戶」的鏈接，並不需要發郵件、填寫特殊表格或者是回答問題。

同時，如果他們決定離開，要確保能導出他們的數據。我們確保客戶隨時可以輕易地導出xml 格式的所有信息和評論。那是他們自己的數據，他們理應能按自己的意願來處理。

這一點很重要。因為給予人們掌握他們自己信息的能力可以塑造對我們的信任。這給了他們一座通向自己的數據島的橋樑。如果他們找到了一個能提供更優服務的地方，讓他們自由離開。這麼做是對的，而且可以建立良好的聲譽。

輕鬆離開

不要勉強留住用戶。如果他們要離開，就讓他們帶上在你網站創造出來的全部內容，然後自由離去。必須敞開糧倉，集中精力留住客戶，所以他們願意回來，而不是因為被門卡住了才不得不回來。

—Charlie O'Donnell， 分析師， Union Square Ventures
(摘自 10 Steps to a Hugely Successful Web 2.0 Company)

Silly Rabbit, Tricks are for Kids

規避長期合同和註冊費用等

誰都不會喜歡長期條款，提前終止費或是一次性的安裝費，所以要避免這麼做。我們的產品付費方式為月付，不用簽訂條款，你可以隨時取消，而且從不會有什麼安裝費。

別企圖去找什麼「高明」的方式以賺得更多的錢。Earn it.


塑料子彈

用提前通知和保留條款來緩和壞消息給用戶帶來的打擊

要發佈類似提價這樣的壞消息啦？應該多次提前通知，盡量把壞消息帶給用戶的痛苦降到最低。同時，應考慮在保留條款中規定，現有客戶在一定時間內仍可以原價使用產品。用戶就是你的奶油和麵包，你要讓他們感受到被重視，而不是被欺騙。


推廣 第十三章

好萊塢運作

從挑逗 到 預演 到 開幕

如果你的應用選在森林中發佈，每人會去使用， 它弄出動靜了麼？ 關鍵一點是，如果你在發佈應用之前沒有一些事前吹噓，人們根本就不知道有這回事。

為了鬧出個大動靜和引起期待， 學學好萊塢風格的運作： 1） 挑逗 ， 2） 預演， 3）上演

挑逗

提前幾個月要開始不斷透露些暗示。 讓人們知道你在幹什麼。 發佈一個徽標。 在你的博客中發佈一下進展。 保持神秘，但是要播下種子。同樣，建立一個網站，好讓你可以從那些感興趣的人那裡收集電子郵件。

這個階段， 你也要開始引誘專業和業內人士。 這些傢伙站在前沿。 他們是引領時尚潮流的人。他們的虛榮心和其作為時尚領導者的地位,使其容易被吸引。 告訴他們，要安排他們參加秘密進行的內部預演。 如果有一個象 Boing Boing， Slashdot 或者 Digg 這樣的站點鏈接了你的（Web）應用，你就會有大量的瀏覽訪問量跟進。另外，你在Google的網頁評級也會水漲船高。

預演

發佈前的幾周， 開始預演特徵。 給人們幕後入口。 描述產品的主題。 對於Basecamp ， 我們發佈了屏幕截圖 和 高亮度的提示條， 里程碑 和其他一些特性。

同樣， 告訴人們此應用背後的思想和原則。例如 Backpack ， 我們在上線前公佈了產品宣言。 這使得人們去思考並且談論這個應用。

你也可以給少數人發放一些特殊「金元券」，讓他們可以提早開始使用這個應用。 這些自我感覺提前被選中，享受了特殊榮耀的人其實充當了你的beta版測試人員，你從中獲益。

同理， 一旦上線發佈，鼓勵人們來註冊，你因此可以得到大量的電子郵件用來發起閃電般的宣傳攻勢。 當我們的應用正式發佈時，成千上萬的電郵向我們湧來，這對賺取眼球幫了大忙。

上線（開演）

正式上線時間到了。 現在人們可以真正地去「劇院」看你的應用了。 發郵件給那些註冊的用戶。 發佈你的全面營銷網站。 盡力到處散佈你的信條。 讓博客都鏈接到你。 公佈你的進步： 已註冊了多少用戶？已經進行了那些更新/調整 ？ 顯示你的成長勢頭並且保持住。

通往發佈之日的道路

當我們剛一得知 Blinksale ，真的要有所動作時，我們就開始在我們的郵件列表中散播誘人的小花絮。 那些列表用戶都曾經申請要收到我們項目的最新消息， 他們是我們的"粉絲" , 聽我們的。 如果你已有權和一組人對話，這些人就是你使用這種策略的最佳地方。

我們做的第二件事就是取得和更多人宣揚我們產品的權利。 在Blinksale 上線前6周，我們在站點上加入了一個花絮頁面，宣稱更簡便的在線寄送發票方式即將誕生。這個頁面給出了剛剛好足夠的信息，以引起興奮和懸念，而沒有洩露那些需要保密的敏感細節。在頁面的顯著位置上有一個時事快訊訂閱表，不要別的，只有填入電子郵件（保持簡單），就可以使那些有興趣的用戶在產品發佈時得到通知。

我們同樣也給將近一打左右的，可能對此產品有興趣的朋友和同事傳了話， 他們也開始把花絮頁面上的內容，通過他們的博客和網站作了進一步的宣傳。短短幾天之內， 我們的郵件列表中就有了上千的訂戶。 這些都是及其重要的人---他們在要求多瞭解我們的產品 並且 他們想知道我們何時（上線）發佈。

終於， 我們在上線前的2周， 邀請了少數的朋友，同事 和業內專家，來進行發佈前beta測試一下 Blinksale 產品。這讓我們把產品拿到用戶面前，通過使用進行檢驗，我們感到這會使我們從中受益。他們還可以幫我們，在產品發佈時作宣傳。這點值得強調，因為我們沒有強迫誰去使用，或者去寫評論文章。 我們只是想讓產品面市，並且想讓人們在產品發佈時談論它。 最後， 如果你要這樣引起共鳴，你最好確定你的產品可以交付。否則， 就像光打雷不下雨。（有雲不下雨）

當上線之時， 我們向郵件列表發了封信， 通知我們的博客朋友 ，並鼓勵我們的Beta測試者暢所欲言。 令我們高興的是，努力取得了巨大回報。 上線發佈後不一會兒， 成千上萬的人訪問了我們（應用）的網站，其中幾千用戶註冊了使用我們的產品。

—Josh Williams, Blinksale 創始人

強大的推廣網站

從 花絮 到 預演 到 上線

最佳推廣工具是一個偉大的產品 。 全世界會發現你擁有一個確實有用的應用

即便如此， 你仍需要一個頂級的推廣站點。 在這個網站中要有什麼？ 這是一些主意：


駕馭博客潮流

博客可以比廣告更具效力（而且便宜很多）

廣告很貴。 而且評估各種類型的廣告的效果，已被證明比廣告本身還有昂貴。 當你沒有財力和時間去走傳統的廣告路徑時，應該考慮一下通過博客推廣的路線。

應該一開始就建立一個博客，不僅可以招攬顧客，還可以提供有幫助的建議，技巧，花招，鏈接等等。 我們的 信號vs噪音 博客，由於每天都張貼出一些 有幫助的，啟迪的 和 有趣的信息和奇聞軼事，每週都會吸引來成千上萬的讀者。

因此，當要推廣我們的第一個產品 Basecamp 時。 我們在SVN上透露了這個消息，並開始傳播。 象 強森 考特克，BoingBoing用戶，吉姆 庫都 這些人，和身份各異的其他一些擁有博客的人，幫我們提升了可見度。推廣工作起飛了。

Ta-da List是另一個顯示了基於博客進行市場營銷威力的偉大案例。 我們在 Signal vs. Noise 上只發了一個關於Ta-da 上線的帖子，幾周後就有 200 多個博客提到了它，並且 12000 人註冊了自己的Ta-da List 帳戶。 關於Backpack的消息傳的更迅速。上線後24小時， 就有 10000 個用戶註冊。


盡早徵集

盡早獲得議論和註冊

我們已經略微談到這點，並且認為值得重複： 要建立某類網站 , 要盡快徵集郵件。選定你的域名並且發佈你的徽標，還要寫上一兩句，或者至少也要暗示一下，你的應用是作什麼用的。然後，要求人們留下電子郵件地址。現在，你已步入正軌，因為已經有了一幫想在上線發佈時準備得到通知的人。


通過教育推廣

與世界分享知識

當一個老師作為選手出現在 Jeopardy 電視節目上時，亞歷克.特別可 常常評論說，教師是個高尚的職業。因此可以肯定和別人分享知識是十分美妙和很有收穫的一件事。 他是對的。 當你教的主題是你的應用時 ，這具有雙重目的：你能回饋社區，這不僅支持了你，還可以在同一時間 為你的那些漂亮的宣傳曝光取得加分。

作為一項推廣技術，教育是用一種軟的方式來 把你的名字---你的產品的名字----擺到更多的人面前。而不是採用強硬推銷 "購買此產品"的方法，通過提供有價值的服務，你越來越引起重視。此舉激發了積極的共鳴，是傳統的營銷策略不能比擬的。那些受你教育的人將成為你的福音傳播者。

教育可以有許多形式。人們通過在你的網站上發表竅門希望同他人分享。在會議上發言並且會後和與會者見面。舉辦講習班，讓好奇的粉絲可以學到更多並且與你懇切交談。 接受出版物的採訪。寫文章，分享有益的資料。並且寫書出版。 ; ）

如我們歷來採用的例子，使用「黃色漸淡技術」，這是我們發明的一種方法，用來巧妙地高亮標明頁面上最近修改過的區域。 關於它，我們在「信號與噪音」寫了一個帖子。這個帖子不斷被瀏覽，已經被瀏覽了成千上萬次（至今應該已有極大的訪問量）。

那個帖子在教育和推廣層面都起了作用。學了一招，並且原先很多絕不會知道我們的產品的人也被暴露在產品面前。 另一個例子：在我們的使用Ruby on Rails研發的階段，我們決定把基礎框架開放源代碼。這被證明是個明智之舉。我們把一些成果回饋社區，建立商譽，贏得我們團隊的認可，收到了有益的反饋，並開始收到來自世界各地的程序員的補丁和無私奉獻。

教學總是好事。 你先付出。你在幫助別人,就會得到一些很好的促銷效果。你甚至可以沐浴在一絲高尚的榮耀裡。那麼，你知道世界想要聽到什麼？

(譯註： Jeopardy! 摘自：維基百科， 一個國際電視測試遊戲節目

先付出

我們博客的文章和技巧是我們網站中最受歡迎的部分。通過傳授電子郵件行銷，確保我們的顧客從我們的軟件中獲益最大化。如果他們能提供更好的服務給顧客，那麼他們就可能得到更多生意，而這反過來又為我們創造了更多生意----多贏。

自由地分享我們的知識，還幫助我們樹立了作為業內專家形象，並加強了我們與現有客戶的合作關係。 他們知道我們關心他們工作的質量。最後，我們從與讀者分享我們文章的搜索引擎和博客那裡，得到了大量的流入訪問瀏覽量。 如果我們不寫那些文章，這些人們永遠也不會聽說我們的軟件。

—David Greiner, Campaign Monitor創始人

特色食品

他們渴望得到的,就給他們

新的或有趣的特性是一為你的應用引起共鳴的很好的辦法。特殊興趣小組愛咀嚼"特色食品"，並且吐回回饋社區。 好吧，這是一種不愉快的比喻，但你得明白這一點。

舉例來說，通過使用Ruby on rails，一個新的開發框架，我們的basecamp引起了開發社區的巨大關注。

在我們應用中使用的ajax的元素引起許多反響，甚至連 「商業2.0雜誌」 也把 37sigals作為一個"Ajax的關鍵角色"， 把我們與一些響噹噹的公司，如：谷歌，雅虎，微軟以及亞馬遜等並列。

另一個例子：很多博客注意到了 Basecamp 的rss支持，因為它是企業的rss的最早的應用之一 。

集成iCal，一個看似輕微的小特色，使我們得到了原本永遠也不會提到我們的應用的Mac(蘋果)相關站點的大量關注。

小團隊時刻準備把新想法整合到軟件中去。而大公司要處理官僚主義瓶頸，你能夠迅速實施新想法並且因此受到重視。

掌握使用最新時髦技術的花邊噱頭，是一種有效且廉價的方式來引起轟動效應。那種不要加入最新曖昧技術的說法只是為了引入注意。但是如果你正在使用了一些新的或引入矚目的技術，一定要繼續使用並且把它在特殊興趣社區中大肆宣傳。

譯註：iCal 摘自： Apple中國- Mac OS X - iCal
iCal 允許你以天，星期或者月查看你的計劃表。並且使用iCal 強大的搜索功能，找到你日程表上的內容就更容易了。）


跟蹤你的日誌

研究日誌並跟蹤共鳴

你必須知道誰在談論你。檢查你的日誌，找出共鳴來自哪裡。誰鏈接了你？誰在誹謗你？ 哪些列在 technorati blogdex ， feedster ， del.icio.us 和Daypop 上的關於你的博客文章最熱門。

找出來這些博客，然後讓感覺到你的存在。在這些博客上留下評論。感謝他們鏈接到你。問他們，是否想被列入你的特別提前通知名單，這樣他們將最先知道你的應用的未來發佈，更新等等。在你的站點上收集積極的讚揚並建立一個"共鳴"網頁。 證人證言是一個推廣你的應用的偉大的方式，對於廣大的人群而言，來自第三方的讚美更值得信賴。

如果評論是負面的，你還要注意。顯示你在認真聽。 仔細地回應批評意見。可以這樣說： "我們很感激你的反饋，但我們這樣做是因為....." ,或者, "您提出一個好一點，我們正在加緊努力實現。"，這將軟化對你的批評，並使你的產品顯出了一副人性化面孔。在博客上的深思熟慮的評論可以驅散唱反調者，甚至把抱怨的人轉化成了你的福音傳播者，這真是令人驚奇的事。


內線追加促銷

在應用內部推銷升級機會

誰都知道選擇網站營銷。但是銷售不僅止於此。 如果你有一個分級的定價策略（或，你的應用有個免費版），不要忘了在產品內部大聲呼籲升級的機會。

告訴人們 他們升級後，你會撤除限制。 例如： 在Basecamp 中，使用免費帳號是不能上傳文件的。當有人試圖上載一個文件，我們並不是簡單的拒絕。 我們會解釋，因何文件上傳不能用，並鼓勵他們升級到一個付費版本，並說明這樣的好處。同樣的方法也用來鼓勵現有用戶當其現有規模已達極限時 升級到更高一級的用戶帳戶。

現存用戶是你最佳銷售對象。在向這些已經熟知並已使用你的產品的用戶進行重複銷售時，請不要害羞。


名字的魔力

給你的應用起個好記的名字

好多人都想給其應用起一個極其具有描述意義的名字，這是一個大錯誤。不用擔憂 挑一個能生動說明你的應用的用途的名字。這通常會產生一個一般意義上的，容易被遺忘的名字。 Basecamp 是一個比什麼 「項目管理中心」 或者 「項目特快」更好的名字。 Writeboard(寫字板)這個名字要比 CollaborEdit(協作編輯)這個名字要好。

同樣在起名過程中也別太指望群策群力。 挑選一個簡短，上口，好記的名字並且馬上使用之。

並且，如果你沒有取得那個你想要的確切域名，也別急躁。 你經常可以有創造性的使用一些其它的字母。（例如： backpackit.com 或 campfirenow.com）

簡化之

技術行業是否已經意識到了想出一個上口，自圓其說的名字會最終同樣地受益？ 不管產品是啥，應該賣的更好，因為技術界將不會把 那些 認為自己被一群傲慢的工程師關到高科技俱樂部門外 的 消費 嚇跑。 技術也應該迎頭趕上。 新產品會更易描述，更易使用並且更易購買--- 這樣，對公司而言， 意味著更易銷售。

—David Pogue, 紐約時報 專欄作家, (摘自 產品名字裡有什麼?)

技術支援 第十四章

感知痛苦

拆除研發和技術支援之間的牆壁

餐飲業中，在廚房幹活和在前台服務顧客是兩個截然不同的世界。這兩邊的相互理解和支持尤為重要。這就是烹飪學校和餐館經常讓廚師在前台作侍者服務顧客的原因，這樣廚房的員工就可以和顧客接觸並且體會到前台工作的真實情況。

很多軟件開發人員也有類似的分工。 設計者和程序員在「廚房」工作， 支持人員應對客戶。 不幸的是，這意味著軟件大廚從來不會聽到客戶的真實意見。這是很有問題的，因為傾聽客戶的聲音是你改善產品優缺點的最好途徑。

解決方案？ 避免在你的客戶和研發/設計之間豎起一堵牆。 不要把客戶支持外包給呼叫中心或第三方。而是自己來做。你，和你的整個團隊，應該搞清楚客戶的意見。 當客戶煩惱時，你需要知曉。你要聽他們的抱怨。你也要因此煩惱。

在 37signals公司， 所有我們的技術支援郵件，都是真正的產品構建者親自回復。 為何如此？ 首先， 這為客戶提供更好的支持。 他們得到了從構建應用的某人腦中想出的一個 直接回應。 其次，這使我們和使用我們的產品並且遇到問題的人們保持接觸。 當他們受挫時， 我們也受挫。我們可以說， 「我感知到了你的痛苦」，並且我們感同身受。

依靠統計分析來揭示問題點，很有誘惑力。但是統計數字和真實聲音不可能一樣。 你需要盡力去消除盡可能多的這種緩衝區，它擋在你和客戶的真實聲音之間。

前台是行為發生的地方。 去那裡。 讓你的大廚干侍者的活。 讀客戶郵件，聽到他們的挫折，傾聽他們的建議並且向他們學習。

拿掉中間人

在 "運作監控" 軟件的開發所有時間裡，支持和市場營銷工作由2個人承擔。 即便我們被迫擴充團隊，我們也從不把技術支援從研發中分離出去。通過親自對每個請求進行響應，我們強迫自己設身處地為客戶著想，並且從他們的角度看問題。

理解你的客戶因何需要某物很重要，不僅因為客戶需要它。這種情形對於我們如何設計有直接影響。拿掉中間人。 當你把耳朵貼近地面仔細傾聽時，會更容易地滿足用戶的需求。

我和很多人討論過這種情形，他們的第一反應往往是： 「你怎麼不雇一個初級工程師來作技術支援？」 ，為用戶設身處地著想。 如果想要你的牛排按照你喜歡的方式烹飪，你是要和一個巴士男孩說，還是應該和那個真正在烹飪牛排的大廚講呢？

—David Greiner, Campaign Monitor 創始人

零培訓

使用內嵌的幫助和常見疑難解答，產品就不需要手冊或使用培訓

你不需要一個手冊去使用Yahoo 或者 Google ， Amazon。 因此， 為什麼你不能也建立一個不需要手冊的產品呢？ 力爭建立一個這樣無須培訓的工具

你該怎樣去做？ 好吧， 就像我們以前提到的，你開始就要保持簡單。 你的應用越不複雜，你就越能免除幫助人們擺脫困境的麻煩。之後，一個偉大的事前支持途徑是在潛在的、容易引起疑惑的地方，使用內嵌的幫助和常見疑難解答。

例如, 我們在屏幕上給出事先支持，允許 Basecamp 用戶上傳他們的 徽標。 有些人經歷過這樣一個問題，他們老是看到老的徽標，這是瀏覽器緩存引起的一個問題。因此在"提交你的徽標" 旁邊的一個區域，我們增加了一個鏈接指向 這個常見疑難解答，來教客戶 強行刷新 瀏覽器 以便看到新的徽標。在我們這樣做之前， 我們每天都要接到5個關於此問題的郵件。現在一個也沒有了。


快速回答

在疑難問題上的快速響應時間應該置於最高優先級

當你快速解答他們的問題時，客戶很高興。 他們已經習慣了錄音電話式的支持，需要等幾天（如果有的話），因此你可以通過提供體貼的即時響應區別於你的競爭者。 在工作時間， 我們在90 分鐘內答覆百分之九十的支持郵件，並且經常不到半個小時就完成了這項工作。人們喜歡這樣。

即使你沒有一個完美的答覆，說點什麼。 你可以用開放，誠實的方法 一個快速回復來贏得善意。 若有人抱怨有個不能馬上得到解決的問題，像這樣告訴他們, "我們已知道你所言那個問題，我們即將在不久之後仔細研究一下。" 這是驅散潛在負面困境的一個很好的方法。

客戶欣賞直率，並且經常轉怒為喜，如果你用一種切中要害的方式快速響應。

混合部隊

一個3人小團隊怎樣才能研發出一個創新型產品並且怎樣成功地和那些大人物們競爭呢？ 答案就是招募一隻混合部隊。

從你創業的第一天起，就要牢記客戶是最重要的資產，他們對你的長遠成功至關重要，因此對待社區用戶要禮貌至上。和大人物競爭的方法是要從小處開始， 並且關注每個客戶。

是你的客戶第一個警告你，有bug（程序缺陷），第一個警告你需求還沒有得到滿足。 並且你的第一個客戶會扛著你的大旗，替你廣而告之。

這不是指你的產品要在上線時做到完美無缺。 恰恰相反，這是要你早早發佈，常常發佈。無論何時，當你的客戶遇到bug時，一定要即時答覆並且感謝他們的告知。

客戶不指望你的產品完美無缺，也不指望你能實現他們所有想要的特性。然而， 客戶一定想要你的傾聽和你的關心，因此要顯示你的關心。這是很多大公司表現尤為不足的地方，所以要早早建立一種社區歸屬感。

在Blinklist, 每個客戶的郵件都得到答覆， 通常在第1個小時內（除非湊巧我們在睡覺）。 我們有個在線論壇，我們確保每個帖子和評論都會有回復。

同樣重要的是， 所有我們的開發者都收到客戶反饋，並且他們積極參與在線論壇。這樣，我們慢慢地，確信地建立起了一個活躍的，忠實的BlinkList 社區。

—Michael Reining, MindValley & Blinklist 聯合創始人

強硬的愛

樂於向客戶說 不

至於功能需求，客戶並不總是正確。如果我們把客戶需求的每個零零碎碎都加入產品中，那麼沒有人會要我們的產品。

如果我們屈從一個客戶的一時的興致， Basecamp 中就會有： 全面的時間跟蹤， 全面的帳單，全面的會議安排，全面的日程安排，全面的附屬任務系統，全面的即時消息聊天，全面的wiki功能，和全面的隨便什麼你能想到的。

然而， 我們通過客戶調查得到的第一號 需求就是 要 保持 Basecamp 簡單。

這裡還有另一個例子： 儘管有一些怨言， 我們決定產品不支持IE5， 這樣就有 7% 的市場被我們抹去了。但是我們認為我去關心剩下的 93% 更加重要。 為IE5 修補產品錯誤和測試在時間上不划算。 我們寧願為其它93%的每個人作一個更好的產品。

作為一間軟件研發公司，你必須扮演過濾器的角色。 並不是每個人建議的每件事都是正確答案。 我們認為客戶所有的需求並不總是正確。 你不得不時常讓一些人傷心失望。

關於這點， 作為一間研發公司熱愛你的產品是最重要的。如果你的產品中摻和了一些你不認可的因素，你將不會愛你的產品。這是必須要否決你不認同的客戶需求的另一個明證。


良好的論壇

使用論壇或聊天室讓客戶互相幫助

論壇以及基於Web的討論組是讓客戶提問及互相幫助的絕佳方式。通過提供開放的交流平台，消除了中間人——即你自己的角色，為你節約了流程時間。

在我們的產品論壇中，客戶發佈應用技巧及竅門、功能需求、故事等諸多信息。我們常常參與其中以為他們提供幫助。但論壇應主要是社區成員互相幫助及分享產品體驗的地方。

你會驚奇地發現有那麼多人是如此樂於助人。


公開你的錯誤

拿出壞消息別讓它擋道

如果某事出錯就告訴人們。即使他們開始並未曾發現。

例如， Basecamp曾經在半夜宕機了數小時。 99%的顧客都未曾察覺，但是我們仍然在我們的Basecamp博客大全上張貼了「意外停機」的公告。 我們認為顧客該知道此事。

這是一個在我們出錯時，張貼的公告的一個樣本： 「我們為今晨停機謹此致歉-我們有一些數據庫問題，導致了某些用戶的重大減速和故障。我們已經修復問題，並正在採取步驟，保證這個故障不會再次發生… …感謝你的耐心，並再次，為停機道歉。」

要盡可能開誠佈公和透明。 不要保秘也不要遮遮掩掩。知情的客戶是你最好的客戶 。 另外，你也會意識到大多的錯誤,在你的顧客的心中並不是那樣地糟糕。 客戶通常樂意給你一點喘息空間，只要他們知道你對他們是誠實的。

關於發佈消息的旁注，好和壞： 當壞消息來時，立即把全部公開。另一方面 ，應該慢慢地一點一滴地透露好消息，如果您能延長好的信息起到的效果，那麼一定要這樣作。

快速，直接和誠實

也許聽起來奇怪，但是最佳情景是，當公司報告自身的壞消息時。 這是一個積極主動的舉措，防止您的公司被置於不利的被動防禦地位。

—Greg Sherwin, CNET應用技術副總裁, 以及 Emily Avila, Calypso Communications負責人， (摘自 A Primer for Crisis PR)

上線之後 第十五章

一個月調整期

上線30天後發佈一個重大更新

快速更新顯示你的幹勁。也表示你在聽。還顯示你有更多的後備招數。這使你能引起第二波的共鳴。加強了最初的好印象。 這給你一些談資的和其他博客評論的話題。

明知快速升級迫近，使你在發佈前把精力集中放在最關鍵的部件。 與其試圖加入更多東西，不如開始真正完善核心功能群。 那麼你就可以在真實世界推出產品。 一旦它在那裡了，你可以開始收集客戶的反饋意見，你就會知道其後的哪些方面需要注意。

這個嬰兒學步的做法在 Backpack 行之有效。我們首先發佈了基礎產品，然後在數周後，加入一些新功能，像 Backpack移動手持設備和標籤，因為這些東西是我們客戶告之的，他們最想要的功能。


保持發帖量

上線後維護一個持續的產品開發博客，顯示你的產品充滿活力

上線後不要停止寫博客。 用一個專門的經常更新的博客，顯示你的產品是充滿活力的，（至少每週一次，如果可能應該時常更新） 。

這些事情包括：

一個博客不僅標誌著你的應用充滿活力，也使你的公司似乎更加人性化。 再次，不要害怕保持友善的和個性化的語氣。小團隊有時感覺需要保持一種聽起來像大公司一樣的語氣，並且在所有時間裡都要表現的極其專業。這幾乎就像一個商業版本的拿破侖綜合症（譯註：矮人自卑心理）。 不要因為聽起來小就害怕。 事實上這其實很好，你可以跟客戶像朋友那樣聊天。

還活著

一個經常更新的產品博客是一個最好的網絡應用正在積極發展的標誌，，人們喜愛這個博客並且有人在家挑燈夜讀。 被遺棄的產品博客是一個廢棄產品的標誌，人們會說，其負責人正趴在方向盤上睡覺。

與用戶在產品博客持續交流，要開誠佈公並且慷慨的分享資訊。 讓貴公司的哲學大放異彩。 公開鏈接並討論競爭者。 暗示即將發佈的功能，保持開放的意見反饋。

一個鮮活的產品，是一個與用戶對話，並認真傾聽的產品。 一個經常更新的產品博客提高了透明度，社區意識和對你的品牌的忠誠度。另外，免費宣傳也是一種獎賞。

作為Lifehacker的編輯，我經常不斷地瀏覽我所喜愛的產品的博客----例如： Google，flickr，Yahoo， el.icio.us和37sigals的產品博客。 比起那些單方面唐突發佈版本，不與他們的用戶和粉絲公開對話的公司，我更傾向於提起上述公司。

—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide

更好，而不是測試版

不要用"測試版"作替罪羊

這些日子感覺一切都是永遠在測試階段。 這真是一個好推辭。 一個無休止的測試階段告訴客戶你不是真的決心生產出成品。 像在說 ， "先用這個，但如果它不完美，這不是我們的錯" 。

測試版將球推給你的客戶。如果你對你的發行版沒有足夠的信心，你怎能期望公眾會有呢？私下的測試版還好，公開的測試版簡直就是胡扯。 如果產品對於公眾使用而言還不足夠好，就不要讓公眾去使用它。

不要等待你的產品盡善盡美。這不會發生。 對你發佈的東西要負責。把它推出並稱其為發佈版。否則，你只是在找借口而已。

測試版是毫無意義

怪google 等公司造成了類似問題。 現在，用戶已經被大量的研發人員訓練出來了 ，他們認為所謂 "測試版" 其實並不真正意味著什麼。

—Mary Hodder, 信息架構師和交互設計師 (摘自： Beta測試的定義)

All the Time

僅僅是我，還是大家都在測試階段，所有時間都在？

—Jim Coudal, 創始人, Coudal Partners

所有缺陷並不生而平等

分清缺陷的輕重緩急（甚至可以忽視其中一些）

只因為在你的產品中發現一個缺陷（bug） ，並不意味著這時候要引起恐慌。 所有軟件都有缺陷---這是一個活生生的事實。

您不必每次馬上就修補漏洞。 大多數缺陷（bug）是讓人煩惱的，但都不是毀滅性的。 困擾問題可以擱置一會兒。 那些導致"看起來不太對"的錯誤的缺陷或其他小錯誤可以安全地預留一會兒。 如果一個缺陷（bug）破壞你的數據庫，這時，顯然需要修補。

分清缺陷的輕重緩急。 有多少人受到影響？ 問題壞到什麼程度？ 這個缺陷bug值得立即重視嗎或可以等待？ 你現在做什麼將對絕大多數人產生最大影響？ 很多時候，加入新的功能，甚至比更改現有缺陷更為重要。

同時，要創造一種別害怕周圍缺陷bug的文化。 缺陷發生，別總是找人去責怪。 你最不需要的就是這樣一個環境，缺陷被私下解決，而不是通過公開討論。

記得我們以前說過誠實的重要性。 如果客戶抱怨的一個缺陷bug ，可以與他們坦誠相見。 告訴他們你已經注意到這個問題並在處理。 如果不能馬上糾正，你要說明理由，並且說明你在專注於改進產品的某些影響更廣泛的方面。 誠實是最好的政策。


安度風暴

等到要求改變的應激反應停止後再採取行動

當你在小船上搖晃，將會激起波浪。 當你引入一個新的功能，改變了一個政策，或刪除了什麼，應激膝跳反應，往往負面的，就會湧入。

要抵制恐慌情緒，和拒絕作出迅速改變的反應。 激情在開始時閃耀。 但如果你安然度過這最初的24-48小時，事情通常會平靜下來。大多數人在向你反應之前，他們並沒有認真的使用和挖掘你添加的功能（或習慣你已經刪除的那些功能） 。所以你要坐穩，讓這些反應都進來，並且在沒有等待一段時間的情況下，別採取任何行動。 然後你可以採取一種更合理的反應。

還記得負面反應幾乎總是高過正面的，而且更加充滿激情。 事實上，你可能僅呢個聽到負面聲音，即使在大多數的用戶對變化感到高興的情況下。 請務必不要愚蠢到為了一個有爭議的，但卻必須要的決定，而作出後退的妥協。


保持先知先覺

訂閱你的競爭對手新聞消息

訂閱你的產品和你的競爭對手的新聞消息（知己知彼總是明智的）。 使用像 PubSub, Technorati, Feedster的這些新聞反饋服務，得到最新更新（用關鍵字，公司名稱和產品名稱） 。使用RSS ，這個不斷變化的信息源將把信息直接傳遞給你，是你總能跟上前進的速度。


小心那個臃腫的怪物

更成熟並不意味著更複雜

事物發展中，不要擔心抵制臃腫。 誘惑將是做大。 但是那樣並不總是正確。 只因為有些事物長大並且更加成熟， 但這不意味著要變得更加複雜。

你並不需要成為一個外太空鋼筆，要上下顛倒地書寫。 有時成為一支鉛筆就挺好。 你不需要是一把瑞士軍刀。你可以作一把螺絲刀。 你不需要做一個潛水表，在5000米下還安全工作，假如你的客戶是陸地愛好者，只想知道現在幾點了。

不要因為膨脹而膨脹。這是許多應用變得臃腫的原因。

新的並不總是意味著改進，有時你應該找準你的產品的定位點。

這是基於Web的應用優於傳統桌面軟件的主要好處之一。 桌面軟件生產商 如： Adobe， Intuit，和微軟每年都要向你兜售新版本。 只因為他們不能總是賣給你相同的版本， 他們不得不通過添加新功能為收費提供正當理由。 正是從這裡軟件變得臃腫了

Web軟件是基於訂閱收費的模型之上， 人們按月付費使用服務。 你不需要通過不斷增加更多更多的功能來進行增值銷售，你只需要提供一個持續的有價值的服務。


跟著潮流走

對於新的方向保持開放的態度

Web 應用的美麗之處在於它的流動性。你沒有必要把它包裝在一個盒子裡，郵寄出去，然後枯等幾年後的下一個版本；你可以一邊實施一邊調整。保持開放的態度，尤其是您原始的點子可能並不是最好的這種情況下。

看看 Flickr。一開始它是個叫做 The Game Neverending（無結尾遊戲）的網絡遊戲，但它的創始人很快地發現遊戲內分享照片的功能比起遊戲本身，反而是個比較可能的產品（遊戲最後是擱在架上塵封了）。要願意承認錯誤並且修改方向。

當個衝浪者。觀察海洋。想出大浪什麼時候來並且依照它來調整。


總結 第十六章

發動引擎

完成了！

完成了！希望您已經躍躍欲試，急不可待地在您的軟件上開始 Getting Real。但是想用最少的資源來創造偉大的軟件，決不是那麼簡單。您需要有正確的點子、激情、時間與能力——決定著您最終所能達到的高度。

最後一些收尾的想法：

執行力

每個人都能讀書，每個人都能想到好點子，每個人都可以是網頁設計師，每個人都會寫博客，每個人都能夠僱傭程序員寫程序。

但您和其他人的差別在於您如何將他們變成現實。成功取決於偉大的執行力。

以軟件來說，這就意味著很多事情要做得正確。您不能只有好的寫作水平卻無法實現文章中的承諾；乾淨的界面設計不能拯救糟糕的代碼；一個優秀的軟件要是沒有好的宣傳，沒有人知道，仍然是不值分文的。如果要有所成就，就必須綜合前述的所有元素。

其關鍵在於平衡能力。如果你向某一方面傾斜了，這就意味著你正走向失敗。應該不斷試著找出並且專注於最弱的一環，直到所有要素達到平衡。

人

創造一個成功的Web應用最重要的，也是值得我們再次強調的一點——參與其中的人。如果沒有合適的人來實現，那麼諸如印度教箴言、中心設計、更小的軟件、以及其他精采的概念將沒法發揮他們應有的作用。

你需要對工作有激情的人。這些人在乎他們的技術——他們真的會認為這是種藝術。這些人對他們的作品感到驕傲，而不關心所獲得的報酬有多少。這些人會在細節上揮汗如雨，即使 95% 的人不知道這些細節間的差別在哪裡。這些人想要創建偉大的作品並且不與劣質品妥協。這些人需要其他人，可能不止一個，但我們也很難不想多來上幾個。總而言之，當你找到上面所述的這些人，留住他們。再怎麼說，產品的成敗——也是公司的成敗——掌握在團隊的成員手中。

不僅只限於軟件

在這裡提醒您，Getting Real 的概念不只適用於建立Web應用程序。當您開始瞭解裡面蘊含的點子，到處都可以發現他們的蹤跡。舉些例子：

當然，Getting Real 是關於編寫偉大的軟件，但沒有畫地自限的必要。將這些概念套用在生活中別的領域中，您或許會偶然發現結果十分不錯。

保持聯繫

要讓我們瞭解 Getting Real 如何幫助您解決問題，請寫信至：gettingreal [at] 37signals [dot] com.

另外，訪問我們的博客 Signal vs. Noise ，來瞭解 37signals 的最新產品、Getting Real、關於可用性、設計以及一些其他內容。

感謝您的閱讀，祝您好運！


37signals 資源


翻譯

感謝如下譯者的辛勤工作: "Bin Dong":http://dongbin.javaeye.com (dongbin.cn@gmail.com); "Jeff Chang" (x12345678@gmail.com); "Tom Liu":http://tarkus.2gang.net (tarkus.nnkh@gmail.com); "Glory Yu":mailto:glory.nnkh@gmail.com

The rest of the book is not yet translated into this language. Contact us via email if you'd like to help translate. The entire book is available in English.


整合中文版編後

本版本在37signals未翻譯完成的原版基礎上，通過採用如下網友的翻譯以及相關工作增訂而成（排名不分先後）

總體修訂：CNBorn

繁體中文版修訂：VampireNeo

 

All content copyright c1999-2006 37signals, LLC. All rights reserved. No part of this book or site may be reproduced or redistributed in any form or by any electronic or mechanical means, including information storage and retrieval systems, without permission in writing from 37signals, except by a reviewer who may quote brief passages in a review.