Getting Real 中文 繁中版
Getting Real Overview
購買本書
購買Getting Real (英文版) PDF電子版或印刷版本。
翻譯修訂中
基於官方翻譯加上網友的翻譯修訂而成。 持續修訂中，如有意見請聯繫CNBorn 。
Getting Real
中文版最後修訂： 2010年5月25日， CNBorn
第一章 引言
第二章 起跑線
第三章 保持精益
第四章 首要任務
第五章 挑選功能
第六章 操作
第七章 組織
第八章 人員配備
第九章 界面設計
第十章 編碼
第十一章 文字
第十二章 定價和註冊
第十三章 推廣
第十四章 技術支持
第十五章 上線之後
第十六章 總結
引言第一章
什麼是Getting Real?
想構建一個成功的Web應用麼? 那麼正是時候Getting Real. Getting Real 是一種更小規模，更快速，更高質量的軟件構建方法。
Getting Real是關於省略所有表達現實（圖表，曲線，矩形，箭頭，統計圖），而構建現實。
Getting real 是追求精煉。 更少的代碼量，更少的軟件，更少的功能，更少的文檔工作，更少無所謂的東西（而且大部分你認為必要的，其實不是）。
Getting Real 是保持精益，變得敏捷。
Getting Real從界面開始，也就是用戶使用的屏幕。 它從實際的用戶體驗開始，並且構建似曾相識的體驗。 這讓你在軟件誤入歧途之前得到正確的用戶界面。
Getting Real 是關於迭代和降低變化成本的方法。 Getting Real聚焦於上線、調整、持續改進，使得其成為開發Web軟件的最佳途徑。
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的時候，我們有非常多的限制。 我們有：
一個需要運營的設計公司
已有的客戶工作
一個七小時的時差（David在丹麥編程序，我們其餘的人在美國）
一個小團隊
沒有外部的資金
我們感受到了“不充足“的憂傷。 所以我們讓我們的盤子保持小。 那時我們只能夠往上方這麼多。 我們選取大任務，把它們分解成我們一時間能夠處理的小任務。 我們一步一步的行動並在前進的過程中分清主次。
”不充足“強迫我們使用創新的方法解決。 我們通過始終構建更少的軟件減少改變的成本。 我們給人們僅僅足夠的特色讓它們以自己的方式來解決自己獨特的問題— 於是我們便不再是障礙。 時差和空間上的距離讓我們在交流中更加有效。 不是人參加會議，我們的交流幾乎毫無例外通過及時通訊軟件和電子郵件，它們強迫我們快速的到達重點。
約束經常是偽裝的優勢。 忘掉風險投資，長發布週期和快速招聘。 代替的是，和你目前擁有的合作。
與枯萎作鬥爭
曾經被稱作“緩慢增長的優雅”可以被更恰當的叫做“特徵枯萎病”，就像植物上的真菌一樣，它節外生枝，模糊了產品的輪廓並吸乾了它的汁液。 特徵枯萎病的解藥是，當然是，“限死的最後期限”。 這導致特徵被按照實現所需時間的比例被拋棄。 經常出現的情況是最有用的特徵需要最長的時間。 於是枯萎和最後期限的結合產生了許多我們知道和喜愛的軟件，包含了充足的沒有用的特徵。
—Jef Raskin,作者(摘自"為什麼軟件是它的方式" )
做你自己
通過親切友善和人性化來把自己和大公司區分開來
大量的小公司犯了試著裝作大公司的錯誤。 就好像他們意識到他們的規模是一個缺點，需要隱藏。 太糟糕了。 小型實際上可以是一個巨大的優勢，尤其是在通訊方面。
小公司享受著更少的形式主義，更少的官僚主義，和更多的自由。 小公司天生和顧客更親近。 那意味著他們可以以一種更加直接和人性化的方式和顧客溝通。 如果你是小公司，你可以用熟悉的語言而不是晦澀的行話。 你的網站和產品可以用一種人類的聲音，而不是操著公司的腔調。 小型意味著你可以和你的顧客在一起談話，而不是居高臨下的方式。
小公司在內部的交流生同樣有優勢。 你可以擯棄形式主義。 所有事情都不再需要繁雜的流程和多重的簽字確認。 參與流程的人都可以開放和誠實的發言。 這個沒有被束縛的思想流是保持小型的巨大優勢。
驕傲地、無所畏懼地做到真實
雖然你可能認為，顧客可以被誇大員工數字或者你的支付能力欺騙，但是精明的，你真正希望的顧客，永遠會知道真相— 無論通過直覺還是推理。 尷尬的是，我曾經參與過這樣的善意謊言，所有謊言都沒有帶來對商業最重要的東西：和真正需要你的服務的顧客建立的有意義的、持久的和互利互惠的關係。 更好的應對應該是驕傲地、無所畏懼地對公司的實際規模和寬度做到真實。
—Khoi Vinh, Subtraction.com
不論何時
不管你在哪個行業，良好的顧客服務應該是所有客戶最大的要求。 我們自已對於服務是這樣要求的，我們的客戶又怎麼會有區別？ 從一開始，我們就做到讓客戶和我們的接觸容易和明晰，不管他們有多少、甚至沒有問題。 在我們的網站上，我們列出了一個免費號碼會轉接到我們的手機；在我們的名片上，每個人都列出了手機號碼。 我們向顧客強調，不管他們有什麼問題，他們隨時可以聯繫到我們。 我們的顧客感謝我們這樣的信任，沒有人濫用過我們的服務。
—Edward Knittel,銷售和市場總監, KennelSource
返回目錄 |
第四章首要任務
什麼理念才是偉大的
明確定義產品的閃光點
竭盡全力將你的軟件定位在一個點上。 你的軟件代表的是什麼？ 它到底是有關什麼的？ 在你開始設計或寫任何代碼之前你必須清楚地知道你做這個產品的目的— 它的前景。 把理想放大些。 為什麼要有它？ 它和其他類似產品不同的地方在哪裡？
這個理念會引導你的每個決定，指引你不偏離航線。 任何時候有比較出格的舉動時，問自己，“我們是不是還在堅守著自己的理念做事？”
你的理念必須是簡潔的。 應該一句話就能把想法傳達到。 以下是我們每個產品的理念：
Basecamp :項目管理即是溝通
Backpack :把生活中的凌亂歸整
Campfire :用及時通訊軟件來開展團體交流太遜了
Ta-da List :和及時貼便條做鬥爭
Writeboard :用不著麻煩微軟的WORD
舉個例，我們Basecamp軟件的理念是，“項目管理即是溝通”。 我們強烈的感覺到對一個項目的有效溝通是引導一系列責任，參與，投資和能量的關鍵。 它把大家統到同一個目標上來增強共識。 我們清楚地知道如果Basecamp能做到這點，那麼其他事情也就會一一水到渠成。
這個理念引導著我們盡可能地保持Basecamp的透明性和開發性。 我們不把溝通局限在公司內部，相反我們向客戶敞開。 我們不考慮太多權限地問題， 相反我們更鼓勵各方的參與。 就是這個理念使我們放棄了圖表，表單，報告，狀態分析和電子表格的功能，相反的我們專注在優先問題的溝通上，如果每日新信息， 評論，該日備忘項目和文件的共享。 把有關你理念的重大決定做在前面，將來其他小的決定就會變得容易多了。
白板上的哲理
有一次Andy Hunt和我編寫一個借記卡的交易開關。 有一個要點就是同一個交易不許向用戶的借記卡二次收費。 也就是說，不管操作過程中怎樣出錯，錯誤都只能發生在交易最終產生前，不能允許出現重複的交易。
因此，我們在共享信息的白板上用大字寫下：要從客戶角度出發，容許客戶犯錯誤的可能。
還有其他大約半打多類似這樣的信條，在我們創建一些複雜的產品，需要下有技巧性的決定時，這些信條給我們指引了方向。 它們使我們的軟件有強大的內部凝聚力和外部的統一性。
—Dave Thomas, 一個實用編程者
編寫座右銘
組織需要指導原則。 需要有一個綱要; 員工每天醒來時應該要知道他們為什麼而工作。 這個綱要最好言簡意賅，富有激情：為什麼你會在這裡？ 是什麼激勵了你？ 我把這看做是座右銘— 一段三或四個字的描述你存在的意義。
— Guy Kawasaki ,作者(摘自編寫座右銘 )
在初期時忽略細節
先粗後細
我們太過痴迷於細節。
兩個原素之間的留白空間
完美的首個字母大寫字形
完美的顏色
完美的用詞
代碼只能四行長，不能七行
90%與89%之差
760px與750px之差
$39/月與$49/月之差
成功和滿意來自於細節
然而，細節中並不只有成功。 細節中你還會遇到停滯不前，意見不合，無數的會議和延遲。 這些東西會掩煞你的信念，降低你成功的機率。
你可有常常一整天被困死在一個設計原素或一個程序代碼上？ 可有不時覺得你今天的進展實在算不上什麼真正進展？ 過早專注於細節就會導致這些結果。 要做完美主義者有的是時間。 但不是現在。
別在第一周就擔心標題字體的大小。 不需要在第二週就搞定什麼是最佳的綠色的色調。 更不用在第三週就要把“提交”按鈕向右移動三個像素。 先把該放的東西放上去。 然後去用它。 保證它是可用的。 最後才去把它調整到完美。
細節是在你使用的過程中才會顯露出來的。 只有在使用中你才能看到什麼需要進一步關注。 在使用中你才會感到缺了些什麼。 常常走路絆倒腳你才會清楚地上什麼坑洼是需要填補的。 那些是當你被迫要留意的時候才需要的細節，不是一想到細節就去搞定它。
魔鬼隱藏在細節中
在選修了幾堂繪畫課後，我徹底擺脫了“馬上投入到細節中”的態度...如果你一開始就畫細節十有八九出來的畫作會不怎麼樣。 事實上，從你一開始那麼做就完全錯了。
你必須一開始把全局的比例分配搞對。 你要從最大的一塊著手，慢慢過渡到最小的。 草稿必須體現模糊的主題。 然後你著手潤色，使整體畫作具有生命力。 著色先從淺，中，深三個色調下手。 這麼一來你的草稿就會有明暗了。 接下來，在你畫作的其他部分都要秉持三個色調的應用原則。 如此反复直到整體成型...
永遠，都要從大到小去做。
—Patrick Lafleur, Creation Objet Inc. (摘自Signal vs. Noise )
當問題成為問題的時候才去擔心
不要把時間浪費在還未成為問題的問題
你真的的需要考慮當用戶到達10萬以上的時候會出現的問題嗎？ 它可能已經是兩年以後的事了。
如果你現在只需要三個程序員你真的有必要雇八個嗎？
你難道真的馬上需要12台高端服務器即使兩台就足以讓你頂一年？
就先掠過吧
人們總是預先花很多時間在還不知道會不會發生的問題上。 靠，我們推出Basecamp的時候還不知道如何向客戶收費！ 因為產品是月付費的，我們知道還有30天的時間來搞定付費方式。 我們把預先省下的時間用在解決更緊急的問題，直到產品推出後，我們才著手付費問題。 結果很順利（它迫使我們用最簡單的解決方案，沒什麼花哨的東西）。
別整天操心還沒成型的麻煩。 別過度開發一個產品。 到適當的時候再添加硬件和系統軟件。 如果進度推遲了一兩個星期，別擔心，還沒到世界末日。 只要誠實: 解釋給你的客戶聽，說你們正經歷著成長的煩惱。 他們也許不會因此無比感動，但他們起碼會贊同你的坦誠。
關鍵是: 如果你已經掌握了你需要的信息就及時做決定。 這樣你就能把注意力集中到需要馬上解決的問題上來。
去網羅對味的顧客
找到你產品的核心市場然後就專注進去
顧客並不總是對的。 現實中你要能分辨出誰是你該針對的顧客，誰是你該放棄的。 慶幸的是，互聯網使得發掘有共識的顧客的過程變得無比容易。
如果你想討好每個人那麼你什麼人也討好不了。
當我們做Basecamp的時候，我們把市場營銷集中在設計公司這塊上。 如此縮小市場範圍，我們就更有可能吸引一些有心的顧客來成為產品的追隨者。 要清楚地知道你的產品是為誰推出的，集中精力去討好這部分人。
我們最成功的一步棋
把Campaign onitor（市場策略觀察）這個產品嚴格地定位在網頁設計這塊市場是我們走得最好得一步棋。 它使我們能很容易地分辨出什麼產品特色才是真正有用，更重要地是，什麼特色是該捨棄地。 這樣一來，我們不僅能靠瞄準一個比較小地目標市場來爭取更多地客人，也因這些客人都有相近的需求使得我們的開發工作更容易些。 在Campaign Monitor中有大量的功能對其他人是毫無用處的完全針對網頁設計者做的。
關注在一個核心市場也便於產品的宣傳。 我們有了這麼一個定位精準的用戶群，就能知道要在他們網上經常出沒的地方做廣告，發布他們可能會感興趣的文章，然後逐步建立一個產品的用戶社區。
—David Greiner,創始人, Campaign Monitor
過後才去做規模調適
你還沒有必要現在就做調整
"我的應用程序能否適應萬人的使用規模?"
等那真發生了再說，明白嗎？ 如果用戶的數量大大超過你的系統負荷那麼恭喜！ 太喜歡這種麻煩事了。 但在現實世界中，超大多數的網絡應用程序從來都沒有到達那一步。 即使你真的開始超負荷了，也不會到馬上就掛了的地步。 你將會有時間反應和調適。 還有一點就是，只有推出產品後你才有機會採集真實的數據指標， 然後你才能用它們來推斷哪些領域需要改進。
舉例說明，推出的第一年我們的Basecamp只是在一台服務器上運作。 因為這樣的一個簡易設置，整個實施只花了我們一周。 我們並沒有一開始就搞個15台服務器的集群或是花好幾個月的時間擔心規模調適的問題。
我們這麼做有碰到什麼問題嗎? 有一些。 但我們也發現大多數我們害怕的問題，比如短暫的系統滯緩，對用戶來說並不是什麼不得了的事。 只要你及時和用戶溝通，誠實地面對問題，他們是會諒解的。 回頭看，我們真的非常高興當時並沒有為了”完美的呈現“而把產品的發布推後數月。
開始階段，要把建造強有力的核心產品做為首要任務，不要過分執迷於需不需要服務器組和是否有能力調整規模應變。 先把一個偉大的產品推出，然後才去擔心它無比成功了以後該怎麼辦的問題。 否則你可能只是把精力，時間和金錢花在一個永遠不會發生的預期上。
信不信由你，最大的問題不是規模調適，而是怎樣達到你不得不需要去調適的那一刻。 沒有第一個麻煩哪來下一個麻煩。
反正你怎麼也得回頭重新審視
事實上，每個人都會有規模調整的問題，當服務人群從零到幾百萬的時候，所有人都必須回過頭去重新審視產品設計架構的方方面面。
—Dare Obasanjo, 微軟 (摘自規模調適和創業公司 )
軟件要有自己的主張
你的軟件應該要有傾向
一些人在論證軟件應該保持中立的問題。 他們說開發者限製或忽視大眾訴求的軟件功能是一種傲慢的表現。 他們說軟件應該總是能隨機應變的。
我們認為那都是扯淡。 偉大的軟件必須要有自己的理想。 偉大的軟件必定是有傾向的。 當人們使用軟件的時候他們不只是在看功能，同時他們也在尋找一個解決方案，一種理想。 決定你的理想而後追求不懈。
同時謹記，如果他們不認同你的理念的話還有無數的其他理念可供選擇。 沒有必要總追逐你永遠無法討好的人。
一個著名的例子就是wiki的最初設計過程。 Ward Cunningham和他的朋友們有意把傳統上認為協作文章不可或缺的許多功能都捨棄不用。 他們不把每次文章的修改歸功於特定哪個人，而把所有權標識都去除了。 這麼一來，內容就不再自我，而成為永恆。 因為他們相信重要的不是誰或什麼時候寫的文章。 這個理念改變了一切。 這個決定孕育了一個以共享己任的社區， 成為Wikipedia（維基百科）日後的主旋律。
我們的軟件走的是一條類似的路。 我們的軟件並不追求成為所有人的寵兒。 我們的軟件是有自己的性格的。 他們找尋的是志同道合的用戶夥伴。 他們是在和有著同樣理想的用戶對話。 你要么上來一起，要么下車。
沒有留言:
張貼留言