For the first version of your app, start with only three people.
^O^
2012年7月30日 星期一
2012年7月17日 星期二
2012年7月5日 星期四
story, UI, html
Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it's too complex. This process shouldn't take more than one day.
Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.
Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and "feeling" before you start worrying about back-end code. Get yourself in front of the customer experience as much as possible.
2012年6月3日 星期日
2012年5月7日 星期一
2012年4月22日 星期日
新創網站這樣 *getting real* 開發才夠快
借用 新創網站這樣開發才夠快 這篇格式，希望不要介意。主要是想闡述 getting real的經驗方法。
1. 用 rails
2. 只做現在小設計
3. 沒 註解
4. 沒 文件
5. 沒 圖
6. 沒 policy
7.沒 PM
8. DRI
9.沒 tune
10. 沒 fancy
PS. xdite version
1. 用 rails
2. 只做現在小設計
3. 沒 註解
4. 沒 文件
5. 沒 圖
6. 沒 policy
7.沒 PM
8. DRI
9.沒 tune
10. 沒 fancy
PS. xdite version
2012年4月12日 星期四
Getting Real 中文 繁中版 下載儲存 (總結 Conclusion)
第十六章總結
Start Your Engines
A few closing thoughts
完成了！
完成了！ 希望您已經躍躍欲試，急不可待地在您的軟件上開始Getting Real。 但是想用最少的資源來創造偉大的軟件，決不是那麼簡單。 您需要有正確的點子、激情、時間與能力——決定著您最終所能達到的高度。
最後一些收尾的想法：
執行力
每個人都能讀書，每個人都能想到好點子，每個人都可以是網頁設計師，每個人都會寫博客，每個人都能夠僱傭程序員寫程序。
但您和其他人的差別在於您如何將他們變成現實。 成功取決於偉大的執行力。
以軟件來說，這就意味著很多事情要做得正確。 您不能只有好的寫作水平卻無法實現文章中的承諾；乾淨的界面設計不能拯救糟糕的代碼；一個優秀的軟件要是沒有好的宣傳，沒有人知道，仍然是不值分文的。 如果要有所成就，就必須綜合前述的所有元素。
其關鍵在於平衡能力。 如果你向某一方面傾斜了，這就意味著你正走向失敗。 應該不斷試著找出並且專注於最弱的一環，直到所有要素達到平衡。
人
創造一個成功的Web應用最重要的，也是值得我們再次強調的一點——參與其中的人。 如果沒有合適的人來實現，那麼諸如印度教箴言、中心設計、更小的軟件、以及其他精采的概念將沒法發揮他們應有的作用。
你 需要對工作有激情的人。 這些人在乎他們的技術——他們真的會認為這是種藝術。 這些人對他們的作品感到驕傲，而不關心所獲得的報酬有多少。 這些人會在細節上揮汗如雨，即使95% 的人不知道這些細節間的差別在哪裡。 這些人想要創建偉大的作品並且不與劣質品妥協。 這些人需要其他人，可能不止一個，但我們也很難不想多來上幾個。 總而言之，當你找到上面所述的這些人，留住他們。 再怎麼說，產品的成敗——也是公司的成敗——掌握在團隊的成員手中。
Conclusion
發動引擎Start Your Engines
A few closing thoughts
完成了！
完成了！ 希望您已經躍躍欲試，急不可待地在您的軟件上開始Getting Real。 但是想用最少的資源來創造偉大的軟件，決不是那麼簡單。 您需要有正確的點子、激情、時間與能力——決定著您最終所能達到的高度。
最後一些收尾的想法：
執行力
每個人都能讀書，每個人都能想到好點子，每個人都可以是網頁設計師，每個人都會寫博客，每個人都能夠僱傭程序員寫程序。
但您和其他人的差別在於您如何將他們變成現實。 成功取決於偉大的執行力。
以軟件來說，這就意味著很多事情要做得正確。 您不能只有好的寫作水平卻無法實現文章中的承諾；乾淨的界面設計不能拯救糟糕的代碼；一個優秀的軟件要是沒有好的宣傳，沒有人知道，仍然是不值分文的。 如果要有所成就，就必須綜合前述的所有元素。
其關鍵在於平衡能力。 如果你向某一方面傾斜了，這就意味著你正走向失敗。 應該不斷試著找出並且專注於最弱的一環，直到所有要素達到平衡。
人
創造一個成功的Web應用最重要的，也是值得我們再次強調的一點——參與其中的人。 如果沒有合適的人來實現，那麼諸如印度教箴言、中心設計、更小的軟件、以及其他精采的概念將沒法發揮他們應有的作用。
你 需要對工作有激情的人。 這些人在乎他們的技術——他們真的會認為這是種藝術。 這些人對他們的作品感到驕傲，而不關心所獲得的報酬有多少。 這些人會在細節上揮汗如雨，即使95% 的人不知道這些細節間的差別在哪裡。 這些人想要創建偉大的作品並且不與劣質品妥協。 這些人需要其他人，可能不止一個，但我們也很難不想多來上幾個。 總而言之，當你找到上面所述的這些人，留住他們。 再怎麼說，產品的成敗——也是公司的成敗——掌握在團隊的成員手中。
Getting Real 中文 繁中版 下載儲存 (5 6 chapters)
挑選功能 第五章
挑選功能第五章
部分，而不是殘缺不全
構建一半產品，而非產品有一半缺陷
小心“所有東西除了廚房水池”的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裡加上一個“會議標籤”。 如果不仔細權衡這看上去好像很簡單。 但是想想“會議標籤”需要的不同元素：地點、時間、房間號、人員、郵件邀請、日曆的整合、支持文檔等等。 這還不包括修改推廣活動中的截圖、用戶預覽頁、常見問題及幫助頁、服務條款以及更多。 在你還沒搞清楚它是怎麼回事之前，一個簡單的想法就像滾雪球一樣弄得你大傷腦筋。
對於每一個新功能你需要……
1. 對它說不
2. 強迫它證明自己的價值
3. 如果得到否定的答案，就此打住。 如果是yes，繼續往下……
4. 為界面繪製草圖
5. 設計界面
6. 編寫代碼
7-15. 測試，改進，測試，改進，測試，改進，測試，改進……
16. 檢查幫助文字是否需要修改
17. 更新產品預覽流程（如果有必要的話）
18. 更新用於銷售的拷貝（如果有必要的話）
19. 更新服務條款（如果有必要的話）
20. 檢查是否違背之前的任何許諾
21. 檢查價格體係是否受影響
22. 上線
23. 深吸一口氣
你能把握住它麼?
構建你有把握的
如果你發布一個會員程序，你的系統能夠處理帳戶和支付問題麼？ 可能你應該只讓用戶根據會員身份通過信用卡支付，而不是讓他每個月撰寫，簽名，並且郵寄一張支票。
你能承受得起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
Feature Selection
操作 第六章Process
挑選功能第五章
部分，而不是殘缺不全
構建一半產品，而非產品有一半缺陷
小心“所有東西除了廚房水池”的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裡加上一個“會議標籤”。 如果不仔細權衡這看上去好像很簡單。 但是想想“會議標籤”需要的不同元素：地點、時間、房間號、人員、郵件邀請、日曆的整合、支持文檔等等。 這還不包括修改推廣活動中的截圖、用戶預覽頁、常見問題及幫助頁、服務條款以及更多。 在你還沒搞清楚它是怎麼回事之前，一個簡單的想法就像滾雪球一樣弄得你大傷腦筋。
對於每一個新功能你需要……
1. 對它說不
2. 強迫它證明自己的價值
3. 如果得到否定的答案，就此打住。 如果是yes，繼續往下……
4. 為界面繪製草圖
5. 設計界面
6. 編寫代碼
7-15. 測試，改進，測試，改進，測試，改進，測試，改進……
16. 檢查幫助文字是否需要修改
17. 更新產品預覽流程（如果有必要的話）
18. 更新用於銷售的拷貝（如果有必要的話）
19. 更新服務條款（如果有必要的話）
20. 檢查是否違背之前的任何許諾
21. 檢查價格體係是否受影響
22. 上線
23. 深吸一口氣
你能把握住它麼?
構建你有把握的
如果你發布一個會員程序，你的系統能夠處理帳戶和支付問題麼？ 可能你應該只讓用戶根據會員身份通過信用卡支付，而不是讓他每個月撰寫，簽名，並且郵寄一張支票。
你能承受得起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
2012年4月11日 星期三
How to read RoR Tutorial easily
sec:the_model_file
because simple less,
forget heroku !
because quick win,
forget TDD syntax !
Just know what TDD check !
because simple less,
forget heroku !
because quick win,
forget TDD syntax !
Just know what TDD check !
2012年4月7日 星期六
夠就好 good enough is fine
I like * 夠就好 good enough is fine *
看看競選廣告, 當有重大議題出現, 通常短時間就有相關文宣回應.
這類文宣的製作品質普通, 用的是照片, 不是現場影像, 標題是靜態, 純文字的, 而不是花俏的動態影像.
唯一的聲音是幕後配音.
儘管如此, 這種文宣已經夠好了.
如果花上幾個星期的時間, 把文宣作的盡善盡美再推出, 那就太遲了,
***在這種情形下, 時效性比文字精練更重要. ***
看看競選廣告, 當有重大議題出現, 通常短時間就有相關文宣回應.
這類文宣的製作品質普通, 用的是照片, 不是現場影像, 標題是靜態, 純文字的, 而不是花俏的動態影像.
唯一的聲音是幕後配音.
儘管如此, 這種文宣已經夠好了.
如果花上幾個星期的時間, 把文宣作的盡善盡美再推出, 那就太遲了,
***在這種情形下, 時效性比文字精練更重要. ***
2012年4月5日 星期四
rework: full list of essays
FIRST
- The new reality
TAKEDOWNS
- Ignore the real world
- Learning from mistakes is overrated
- Planning is guessing
- Why grow?
- Workaholism
- Enough with “entrepreneurs”
GO
- Make a dent in the universe
- Scratch your own itch
- Start making something
- No time is no excuse
- Draw a line in the sand
- Mission statement impossible
- Outside money is Plan Z
- You need less than you think
- Start a business, not a start-up
- Building to flip is building to flop
- Less mass
PROGRESS
- Embrace constraints
- Build half, not half-ass
- Start at the epicenter
- Ignore the details early on
- Making the call is making progress
- Be a curator
- Throw less at the problem
- Focus on what won't change
- Tone is in your fingers
- Sell your by-products
- Launch now
PRODUCTIVITY
- Illusions of agreement
- Reasons to quit
- Interruption is the enemy of productivity
- Meetings are toxic
- Good enough is fine
- Quick wins
- Don't be a hero
- Go to sleep
- Your estimates suck
- Long lists don't get done
- Make tiny decisions
COMPETITORS
- Don't copy
- Decommoditize your product
- Pick a fight
- Underdo your competition
- Who cares what they’re doing?
EVOLUTION
- Say no by default
- Let your customers outgrow you
- Don’t confuse enthusiasm with priority
- Be at-home good
- Don’t write it down
PROMOTION
- Welcome obscurity
- Build an audience
- Out-teach your competition
- Emulate chefs
- Go behind the scenes
- Nobody likes plastic flowers
- Press releases are spam
- Forget about the Wall Street Journal
- Drug dealers get it right
- Marketing is not a department
- The myth of the overnight sensation
HIRING
- Do it yourself first
- Hire when it hurts
- Pass on great people
- Strangers at a cocktail party
- Resumes are ridiculous
- Years of irrelevance
- Forget about formal education
- Everybody works
- Hire managers of one
- Hire great writers
- The best are everywhere
- Test-drive employees
DAMAGE CONTROL
- Own your bad news
- Speed changes everything
- How to say you’re sorry
- Put everyone on the front lines
- Take a deep breath
CULTURE
- You don’t create a culture
- Decisions are temporary
- Skip the rock stars
- They’re not thirteen
- Send people home at 5:00
- Don’t scar on the first cut
- Sound like you
- Four-letter words
- ASAP is poison
CONCLUSION
- Inspiration is perishable
RESOURCES
- About 37signals
- 37signals products
2012年3月27日 星期二
2012年3月26日 星期一
Think different
強調更多一層的冷戰競爭思維是行不通的死胡同。
這種思維方式告訴我們，不管競爭對手做什麼你總是要比他們加多一些。 如果他們有4個特色功能，你就需要做出5個（或15個，或25個）。 如果他們花了x，你就該花xx。 如果他們有20，你就得有30。
如此創造產品的方式是昂貴的，是做不到前瞻性思維的，那怎樣才是有效的方法呢？
Think different !!!
這種思維方式告訴我們，不管競爭對手做什麼你總是要比他們加多一些。 如果他們有4個特色功能，你就需要做出5個（或15個，或25個）。 如果他們花了x，你就該花xx。 如果他們有20，你就得有30。
如此創造產品的方式是昂貴的，是做不到前瞻性思維的，那怎樣才是有效的方法呢？
Think different !!!
2012年3月25日 星期日
* Rails Tutorial *
I'm learning Ruby on Rails with @railstutorial! http://railstutorial.org/
DoItYourself 自己先動手做 get busy living or get busy dying
DoItYourself 自己先動手做 get busy living or get busy dying
2012年3月24日 星期六
get it out there現在就推出吧
Fix Time and Budget, Flex Scope
Launch on time and on budget
Here's an easy way to launch on time and on budget: keep them fixed. Never throw more time or money at a problem, just scale back the scope.
Launch on time and on budget
Here's an easy way to launch on time and on budget: keep them fixed. Never throw more time or money at a problem, just scale back the scope.
2012年3月19日 星期一
2012年3月17日 星期六
google "getting real中文" 的結果
約有 2,900,000 項結果
=========================================================
當網路行銷回歸現實(Getting Real) (Mr. 6)
mr6.cc/?p=5671 - 頁庫存檔
2011年1月27日 – 這個廣告片來得正好，我們明天（周五）下午1:30將舉辦的《Mr.6過年前行銷報告會》，主題是(借用知名美國暢銷書名)：「Getting Real」，中文就翻作「回 ...
您已造訪這個網頁 2 次。上次造訪日期：2012/3/9
Getting Real by 37signals
gettingreal.37signals.com/GR_chn.php - 頁庫存檔 - 轉為繁體網頁
Getting Real能够交付更好的结果，是因为它强迫你处理真正要解决的问题，而不是关于那些问题的空想。它迫使你面对当下。 Getting Real更注重实际的用户界面，而 ...
Getting Real中文版.pdf_免费高速下载_新浪爱问共享资料
ishare.iask.sina.com.cn › ... › 经济管理 › 战略管理 - 頁庫存檔 - 轉為繁體網頁
2010年9月25日 – Getting Real中文版.pdf,《Getting Real中文版》，37 Signals 团队作品。 在中国，不知有多少创业者跟我说过他想做成中国的37 S.
【荐书】Getting Real - Apple4.us
apple4.us/2010/09/getting-real.html - 頁庫存檔 - 轉為繁體網頁
2010年9月25日 – 今天推荐其中一本，Getting Real 的中文版（点击此处下载）。非常抱歉我没找到译者是谁。 推荐语来自一名我激赏的创业者：. 总结一下这本书的思想 ...
Getting Real 一本不談技術性的開發精髓參考書- 精粹資源- Rails Fun ...
railsfun.tw › 精粹資源 - 頁庫存檔
2009年5月4日 – Rails Fun!! 基本上簡單的來說......就我對CFC說得那句如果Rails是宗教，這本書將會是宣傳單......X"D okay，以下(英文版) ...
Getting Real 中文版- CNBorn|我不是大牛
cnborn.net/.../getting-real-ch... - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
Getting Real 中文版. 整理Getting Real 的中文翻译，保留原翻译者版权的情况下进行整理集合，同时在进行进一步修订。 Getting Real. 第一章 引言; 第二章 起跑线 ...
您於 2012/2/21 造訪這個網頁。
超軟之家: 想開發自己Web 站嗎？ 不容錯過Getting Real 一書！
ben6.blogspot.com/2011/06/web-getting-real.html - 頁庫存檔
2011年6月21日 – 推薦原文線上電子書Getting Real，比較喜愛中文可參考正在翻譯中的簡中線上電子書。 讀了本書， 深深感受37 signals 編輯群的用心與字字珠璣， ...
Getting Real 中文版電子書~ Android应用v1.20 顺次gasolin | 图书与 ...
cn.androlib.com › 应用 › 图书与工具书 - 轉為繁體網頁
2010年12月26日 – Getting Real 中文版電子書- Android应用- gasolin - ★★★★☆ - 图书与工具书.
《Getting Real》中文Beta版发布- 心灵的自由- ITeye技术网站
dongbin.iteye.com/.../59635 - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
经过James, 吴江, tarkus和我的努力，《Getting Real》中文版的翻译现在完成了一半。 ... 现在由herock(http://herock.net)发起的Getting Real 中文版协同翻译项目 也 ...
Getting Real (豆瓣)
book.douban.com/.../35678... - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
去年，我先读了中文版Getting Real，然后选择的看了英文版。 很受启发。所谓的启发，是指你会从文中找到自己想像的事物和灵感，我于是一边看一边记下自己脑子里 ...
11-20
=========================================================
《Getting Real》中文版- 创业故事- python.cn(news, jobs)
simple-is-better.com/news/462 - 頁庫存檔 - 轉為繁體網頁
2011年6月26日 – 久看不厌，37signals.com 你知道的哇？ 整理Getting Real 的中文翻译，保留原翻译者版权的情况下进行整理集合，同时在进行进一步修订。
又说敏捷：推荐getting real 中文版| 谁与我煮老酒@cuteyejun 叶军 ...
www.yejun.cn/?p=597 - 頁庫存檔 - 轉為繁體網頁
又说敏捷：推荐getting real 中文版. 发表于 2010年04月26日 由 yejun. http://cnborn.net/docs/getting_real/index.html. 正好前几天发布出现了两次回滚，逼我再次看起 ...
Getting Real中文版- Joe's Weblog
foobar.me/.../getting-real-zh... - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
2010年9月7日 – Getting Real中文版. 每次读Getting Real都颇有收获.只可惜官方的中译版残缺不全,部分章节仍然是英文,每每读到这些章节我便匆匆扫过,理解上也 ...
Getting Real中文版.pdf_免费高速下载_新浪爱问共享资料
ishare.iask.sina.com.cn › ... › IT资料 › IT书籍 - 頁庫存檔 - 轉為繁體網頁
2012年1月11日 – Getting Real中文版.pdf,Getting Real是关于省略所有表达现实（图表，曲线，矩形，箭头，统计图），而构建现实。 Getting real 是.
Getting Real中文版.pdf_免费高速下载_新浪爱问共享资料
ishare.iask.sina.com.cn › ... › IT资料 › IT书籍 - 頁庫存檔 - 轉為繁體網頁
2011年8月1日 – 浏览此页的网友还喜欢 查看此上传者的其他资料 · Getting+Real中文版.pdf; 5分; liuyang · About.Face.3：The.Essentials.of.Interact....pdf; 5分 ...
《Getting Real》中文PDF版(beta) | Cliff Woo's Blog
blog.cliffwoo.com/?p=28 - 頁庫存檔 - 轉為繁體網頁
2008年12月15日 – 如何让团队变得敏捷？如何开发出让用户满意的Web应用？ 《Getting.
《Getting Real》：回归现实| 标点符
www.biaodianfu.com/getting... - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
2011年2月23日 – Getting Real简介： Getting Real是关于省略所有表达现实（图表，曲线，矩形，箭头，统计图），而构建现实。 Getting. ... Getting Real官方中文在线 ...
《Getting Real》中文Beta版发布- Tech - ITeye论坛
www.iteye.com/topic/59635 - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
2007年3月14日 – 经过James, 吴江, tarkus和我的努力，《Getting Real》中文版的翻译现在完成了一半。今发布Beta版，希望大家多提宝贵意见。本次翻译活动完全是 ...
Getting Real 中文版.pdf - OPEN开源文档
www.open-open.com/.../9c6... - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
2012年2月24日 – 想构建一个成功的Web应用么? 那么正是时候Getting Real. Getting Real 是一种更小规模，更快速，更高质量的软件构建方法。Getting Real能够 ...
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
TX5day: Getting Real 中文繁中版
tx5day.blogspot.com/2012/02/getting-real_16.html - 頁庫存檔
2012年2月16日 – Getting Real 中文版最後修訂： 2010年5月25日， CNBorn 第一章引言第二章起跑線第三章保持精益第四章首要任務第五章挑選功能第六章操作第七 ...
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
=========================================================
當網路行銷回歸現實(Getting Real) (Mr. 6)
mr6.cc/?p=5671 - 頁庫存檔
2011年1月27日 – 這個廣告片來得正好，我們明天（周五）下午1:30將舉辦的《Mr.6過年前行銷報告會》，主題是(借用知名美國暢銷書名)：「Getting Real」，中文就翻作「回 ...
您已造訪這個網頁 2 次。上次造訪日期：2012/3/9
Getting Real by 37signals
gettingreal.37signals.com/GR_chn.php - 頁庫存檔 - 轉為繁體網頁
Getting Real能够交付更好的结果，是因为它强迫你处理真正要解决的问题，而不是关于那些问题的空想。它迫使你面对当下。 Getting Real更注重实际的用户界面，而 ...
Getting Real中文版.pdf_免费高速下载_新浪爱问共享资料
ishare.iask.sina.com.cn › ... › 经济管理 › 战略管理 - 頁庫存檔 - 轉為繁體網頁
2010年9月25日 – Getting Real中文版.pdf,《Getting Real中文版》，37 Signals 团队作品。 在中国，不知有多少创业者跟我说过他想做成中国的37 S.
【荐书】Getting Real - Apple4.us
apple4.us/2010/09/getting-real.html - 頁庫存檔 - 轉為繁體網頁
2010年9月25日 – 今天推荐其中一本，Getting Real 的中文版（点击此处下载）。非常抱歉我没找到译者是谁。 推荐语来自一名我激赏的创业者：. 总结一下这本书的思想 ...
Getting Real 一本不談技術性的開發精髓參考書- 精粹資源- Rails Fun ...
railsfun.tw › 精粹資源 - 頁庫存檔
2009年5月4日 – Rails Fun!! 基本上簡單的來說......就我對CFC說得那句如果Rails是宗教，這本書將會是宣傳單......X"D okay，以下(英文版) ...
Getting Real 中文版- CNBorn|我不是大牛
cnborn.net/.../getting-real-ch... - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
Getting Real 中文版. 整理Getting Real 的中文翻译，保留原翻译者版权的情况下进行整理集合，同时在进行进一步修订。 Getting Real. 第一章 引言; 第二章 起跑线 ...
您於 2012/2/21 造訪這個網頁。
超軟之家: 想開發自己Web 站嗎？ 不容錯過Getting Real 一書！
ben6.blogspot.com/2011/06/web-getting-real.html - 頁庫存檔
2011年6月21日 – 推薦原文線上電子書Getting Real，比較喜愛中文可參考正在翻譯中的簡中線上電子書。 讀了本書， 深深感受37 signals 編輯群的用心與字字珠璣， ...
Getting Real 中文版電子書~ Android应用v1.20 顺次gasolin | 图书与 ...
cn.androlib.com › 应用 › 图书与工具书 - 轉為繁體網頁
2010年12月26日 – Getting Real 中文版電子書- Android应用- gasolin - ★★★★☆ - 图书与工具书.
《Getting Real》中文Beta版发布- 心灵的自由- ITeye技术网站
dongbin.iteye.com/.../59635 - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
经过James, 吴江, tarkus和我的努力，《Getting Real》中文版的翻译现在完成了一半。 ... 现在由herock(http://herock.net)发起的Getting Real 中文版协同翻译项目 也 ...
Getting Real (豆瓣)
book.douban.com/.../35678... - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
去年，我先读了中文版Getting Real，然后选择的看了英文版。 很受启发。所谓的启发，是指你会从文中找到自己想像的事物和灵感，我于是一边看一边记下自己脑子里 ...
11-20
=========================================================
《Getting Real》中文版- 创业故事- python.cn(news, jobs)
simple-is-better.com/news/462 - 頁庫存檔 - 轉為繁體網頁
2011年6月26日 – 久看不厌，37signals.com 你知道的哇？ 整理Getting Real 的中文翻译，保留原翻译者版权的情况下进行整理集合，同时在进行进一步修订。
又说敏捷：推荐getting real 中文版| 谁与我煮老酒@cuteyejun 叶军 ...
www.yejun.cn/?p=597 - 頁庫存檔 - 轉為繁體網頁
又说敏捷：推荐getting real 中文版. 发表于 2010年04月26日 由 yejun. http://cnborn.net/docs/getting_real/index.html. 正好前几天发布出现了两次回滚，逼我再次看起 ...
Getting Real中文版- Joe's Weblog
foobar.me/.../getting-real-zh... - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
2010年9月7日 – Getting Real中文版. 每次读Getting Real都颇有收获.只可惜官方的中译版残缺不全,部分章节仍然是英文,每每读到这些章节我便匆匆扫过,理解上也 ...
Getting Real中文版.pdf_免费高速下载_新浪爱问共享资料
ishare.iask.sina.com.cn › ... › IT资料 › IT书籍 - 頁庫存檔 - 轉為繁體網頁
2012年1月11日 – Getting Real中文版.pdf,Getting Real是关于省略所有表达现实（图表，曲线，矩形，箭头，统计图），而构建现实。 Getting real 是.
Getting Real中文版.pdf_免费高速下载_新浪爱问共享资料
ishare.iask.sina.com.cn › ... › IT资料 › IT书籍 - 頁庫存檔 - 轉為繁體網頁
2011年8月1日 – 浏览此页的网友还喜欢 查看此上传者的其他资料 · Getting+Real中文版.pdf; 5分; liuyang · About.Face.3：The.Essentials.of.Interact....pdf; 5分 ...
《Getting Real》中文PDF版(beta) | Cliff Woo's Blog
blog.cliffwoo.com/?p=28 - 頁庫存檔 - 轉為繁體網頁
2008年12月15日 – 如何让团队变得敏捷？如何开发出让用户满意的Web应用？ 《Getting.
《Getting Real》：回归现实| 标点符
www.biaodianfu.com/getting... - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
2011年2月23日 – Getting Real简介： Getting Real是关于省略所有表达现实（图表，曲线，矩形，箭头，统计图），而构建现实。 Getting. ... Getting Real官方中文在线 ...
《Getting Real》中文Beta版发布- Tech - ITeye论坛
www.iteye.com/topic/59635 - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
2007年3月14日 – 经过James, 吴江, tarkus和我的努力，《Getting Real》中文版的翻译现在完成了一半。今发布Beta版，希望大家多提宝贵意见。本次翻译活动完全是 ...
Getting Real 中文版.pdf - OPEN开源文档
www.open-open.com/.../9c6... - 中華人民共和國 - 頁庫存檔 - 轉為繁體網頁
2012年2月24日 – 想构建一个成功的Web应用么? 那么正是时候Getting Real. Getting Real 是一种更小规模，更快速，更高质量的软件构建方法。Getting Real能够 ...
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
TX5day: Getting Real 中文繁中版
tx5day.blogspot.com/2012/02/getting-real_16.html - 頁庫存檔
2012年2月16日 – Getting Real 中文版最後修訂： 2010年5月25日， CNBorn 第一章引言第二章起跑線第三章保持精益第四章首要任務第五章挑選功能第六章操作第七 ...
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-) ***** ^^;-)
Getting Real 中文 繁中版 修訂：VampireNeo
Getting Real 中文 繁中版
繁體中文版修訂：VampireNeo
English Ver.
Getting Real
Here are the 16 chapters and 91 essays that make up the book.
Introduction chapter 1
What is Getting Real?
A smaller, faster, better way to build software
About 37signals
Our small team creates simple, focused software
Caveats, disclaimers, and other preemptive strikes
Responses to some complaints we hear
The Starting Line chapter 2
Build Less
Underdo your competition
What's Your Problem?
Build software for yourself
2012年3月15日 星期四
promotion web host
Welcome to my promotion website ^^
moodle is so big(80+MB)
it costs 12+hours to setup ;-p
==================================
==================================
web software: Moodle
==================================
This is Signal vs. Noise, a weblog by 37signals about design, business, experience, simplicity, the web, culture, and more.
Why 為什麼要 Getting Real 中文 繁中版
Getting Real table of contents
因為 internet 沒有
而我喜歡 Getting Real
且讀 繁中版 必較快 (會讀很多次)
也使有這樣需要的你們
能有舒服的學習享受 ;-)
plz enjoy ^^
如果你們喜歡, 請加入書籤 (如果會讀很多次)
If u like, u can bookmark it
If u like, u could share it
如果你們喜歡, 請分享其他人
感恩
2012年3月14日 星期三
好萊塢推廣(Hollywood Launch)
第十三章推廣
好萊塢運作
Hollywood Launch
Go from teaser to preview to launch
從挑逗到預演到開幕
如果你的應用選在森林中發布，沒人會去使用， 它弄出動靜了麼？ 關鍵一點是，如果你在發布應用之前沒有一些事前吹噓，人們根本就不知道有這回事。
為了鬧出個大動靜和引起期待， 學學好萊塢風格的運作： 1） 挑逗， 2） 預演， 3）上演
挑逗
提前幾個月要開始不斷透露些暗示。 讓人們知道你在幹什麼。 發布一個徽標。 在你的博客中發布一下進展。 保持神秘，但是要播下種子。 同樣，建立一個網站，好讓你可以從那些感興趣的人那裡收集電子郵件。
這個階段， 你也要開始引誘專業和業內人士。 這些傢伙站在前沿。 他們是引領時尚潮流的人。 他們的虛榮心和其作為時尚領導者的地位,使其容易被吸引。 告訴他們，要安排他們參加秘密進行的內部預演。 如果有一個像Boing Boing， Slashdot 或者Digg 這樣的站點鏈接了你的（Web）應用，你就會有大量的瀏覽訪問量跟進。 另外，你在Google的網頁評級也會水漲船高。
預演
發布前的幾週， 開始預演特徵。 給人們幕後入口。 描述產品的主題。 對於Basecamp ， 我們發布了屏幕截圖和高亮度的提示條， 里程碑和其他一些特性。
同樣， 告訴人們此應用背後的思想和原則。 例如Backpack ， 我們在上線前公佈了產品宣言。 這使得人們去思考並且談論這個應用。
你也可以給少數人發放一些特殊“金元券”，讓他們可以提早開始使用這個應用。 這些自我感覺提前被選中，享受了特殊榮耀的人其實充當了你的beta版測試人員，你從中獲益。
同理， 一旦上線發布，鼓勵人們來註冊，你因此可以得到大量的電子郵件用來發起閃電般的宣傳攻勢。 當我們的應用正式發佈時，成千上萬的電郵向我們湧來，這對賺取眼球幫了大忙。
上線（開演）
正式上線時間到了。 現在人們可以真正地去“劇院”看你的應用了。 發郵件給那些註冊的用戶。 發布你的全面營銷網站。 盡力到處散佈你的信條。 讓博客都鏈接到你。 公佈你的進步： 已註冊了多少用戶？ 已經進行了那些更新/調整？ 顯示你的成長勢頭並且保持住。
好萊塢運作
Hollywood Launch
Go from teaser to preview to launch
從挑逗到預演到開幕
如果你的應用選在森林中發布，沒人會去使用， 它弄出動靜了麼？ 關鍵一點是，如果你在發布應用之前沒有一些事前吹噓，人們根本就不知道有這回事。
為了鬧出個大動靜和引起期待， 學學好萊塢風格的運作： 1） 挑逗， 2） 預演， 3）上演
挑逗
提前幾個月要開始不斷透露些暗示。 讓人們知道你在幹什麼。 發布一個徽標。 在你的博客中發布一下進展。 保持神秘，但是要播下種子。 同樣，建立一個網站，好讓你可以從那些感興趣的人那裡收集電子郵件。
這個階段， 你也要開始引誘專業和業內人士。 這些傢伙站在前沿。 他們是引領時尚潮流的人。 他們的虛榮心和其作為時尚領導者的地位,使其容易被吸引。 告訴他們，要安排他們參加秘密進行的內部預演。 如果有一個像Boing Boing， Slashdot 或者Digg 這樣的站點鏈接了你的（Web）應用，你就會有大量的瀏覽訪問量跟進。 另外，你在Google的網頁評級也會水漲船高。
預演
發布前的幾週， 開始預演特徵。 給人們幕後入口。 描述產品的主題。 對於Basecamp ， 我們發布了屏幕截圖和高亮度的提示條， 里程碑和其他一些特性。
同樣， 告訴人們此應用背後的思想和原則。 例如Backpack ， 我們在上線前公佈了產品宣言。 這使得人們去思考並且談論這個應用。
你也可以給少數人發放一些特殊“金元券”，讓他們可以提早開始使用這個應用。 這些自我感覺提前被選中，享受了特殊榮耀的人其實充當了你的beta版測試人員，你從中獲益。
同理， 一旦上線發布，鼓勵人們來註冊，你因此可以得到大量的電子郵件用來發起閃電般的宣傳攻勢。 當我們的應用正式發佈時，成千上萬的電郵向我們湧來，這對賺取眼球幫了大忙。
上線（開演）
正式上線時間到了。 現在人們可以真正地去“劇院”看你的應用了。 發郵件給那些註冊的用戶。 發布你的全面營銷網站。 盡力到處散佈你的信條。 讓博客都鏈接到你。 公佈你的進步： 已註冊了多少用戶？ 已經進行了那些更新/調整？ 顯示你的成長勢頭並且保持住。
推薦 *** Ruby on Rails 實戰聖經 ***
推薦
Ruby on Rails 實戰聖經
使用 Rails 3.2 及 Ruby 1.9.3
本書介紹Ruby on Rails這套開放原始碼的網站開發框架
個人在 March 2012
學習 Part 1: 入門導覽
Ruby on Rails 實戰聖經
使用 Rails 3.2 及 Ruby 1.9.3
本書介紹Ruby on Rails這套開放原始碼的網站開發框架
個人在 March 2012
學習 Part 1: 入門導覽
2012年2月28日 星期二
三個火槍手=The Three Musketeers
三個火槍手=The Three Musketeers
用三人小組構建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 )
2012年2月20日 星期一
GettingReal將帶給你...
這本書將帶給你...
信仰之重要
為什麼小是好事情
怎樣構建更少
怎樣從現實世界中快速找到創意
怎樣培養團隊
為何要由內到外的設計
為什麼寫作至關重要
為什麼要比對手少做
如何升級你的應用和散播文字
成功維護的秘訣
發布後能夠持續保持後勁的秘訣。
其他...
本書關注於理論高度。 我們不會使你陷入代碼片段細節，或者是CSS竅門。 我們會堅守在驅動Getting Real過程的主要思想和價值觀上。
本書適合你麼？
你是管理者，設計師，程序員，或者市場人員。
信仰之重要
為什麼小是好事情
怎樣構建更少
怎樣從現實世界中快速找到創意
怎樣培養團隊
為何要由內到外的設計
為什麼寫作至關重要
為什麼要比對手少做
如何升級你的應用和散播文字
成功維護的秘訣
發布後能夠持續保持後勁的秘訣。
其他...
本書關注於理論高度。 我們不會使你陷入代碼片段細節，或者是CSS竅門。 我們會堅守在驅動Getting Real過程的主要思想和價值觀上。
本書適合你麼？
你是管理者，設計師，程序員，或者市場人員。
從概念到實施
從概念到實施
從靈感，到草稿，到HTML，到代碼
以下是我們Get Real（求實）的過程:
腦力激盪
先要有個點子。 這產品要給我們帶來什麼？ 以Basecamp來說, 我們是要滿足自己的需要。 我們想要用它來發布項目的一些更新信息。 我們希望能讓用戶一起參與。 我們知道項目都有里程碑。 我們希望能有個集中歸檔的地方讓大家能回過頭去溫習一些舊的東西。 我們想要有個全局觀，從一定的高度來鳥瞰所有項目的進度。 歸結起來，這些假想和一些其他設想打下了我們日後著手的基礎。
這個階段並不是有關一些實施的具體細節。 這是一個大方向。 軟件需要為我們做什麼？ 什麼時候才能知道它有用？ 確切的說我們要做出個什麼東西來？ 這是高階的理念，不是像素階段（細節）的推敲。 在這個階段，那些細節是沒有意義的。
紙上草稿
草稿是迅速的，實用的和便宜的，這就恰恰是你想要開始的方式。 塗些東西，畫些東西，方塊，圓圈，線條，什麼都行。 把你腦子裡的想法搬到紙上。 這階段的目標是把概念轉成一個界面設計的粗稿。 這個階段完全是試驗性的。 不存在什麼答案是錯誤的。
創建HTML頁面
做一個HTML版本的功能界面（或一個區間界面或流程界面，如果這麼做更合適的話）。 發布一個實在的東西，這樣一來大家就都可以看到它出現在屏幕上的樣子。
以Basecamp而言，我們先做“發布一條信息”的界面，然後是“編輯信息”的界面，然後一步步下去。
先別寫任何程序代碼。 只把HTML和CSS的框架搞出來。 有關細節實施是後面的事。
上代碼編程
當模型框架看起來過得去又兼具一些足夠必要的功能時，就是開始上代碼編程的時候了。
在這整個過程中要記住保持機動彈性，要有多次反复的思想準備。 應該隨時有這個意識：捨棄某些已完成的步驟重新來過，如果成品看起來醜陋不堪。 數次重複這個過程是很自然的。
從靈感，到草稿，到HTML，到代碼
以下是我們Get Real（求實）的過程:
腦力激盪
先要有個點子。 這產品要給我們帶來什麼？ 以Basecamp來說, 我們是要滿足自己的需要。 我們想要用它來發布項目的一些更新信息。 我們希望能讓用戶一起參與。 我們知道項目都有里程碑。 我們希望能有個集中歸檔的地方讓大家能回過頭去溫習一些舊的東西。 我們想要有個全局觀，從一定的高度來鳥瞰所有項目的進度。 歸結起來，這些假想和一些其他設想打下了我們日後著手的基礎。
這個階段並不是有關一些實施的具體細節。 這是一個大方向。 軟件需要為我們做什麼？ 什麼時候才能知道它有用？ 確切的說我們要做出個什麼東西來？ 這是高階的理念，不是像素階段（細節）的推敲。 在這個階段，那些細節是沒有意義的。
紙上草稿
草稿是迅速的，實用的和便宜的，這就恰恰是你想要開始的方式。 塗些東西，畫些東西，方塊，圓圈，線條，什麼都行。 把你腦子裡的想法搬到紙上。 這階段的目標是把概念轉成一個界面設計的粗稿。 這個階段完全是試驗性的。 不存在什麼答案是錯誤的。
創建HTML頁面
做一個HTML版本的功能界面（或一個區間界面或流程界面，如果這麼做更合適的話）。 發布一個實在的東西，這樣一來大家就都可以看到它出現在屏幕上的樣子。
以Basecamp而言，我們先做“發布一條信息”的界面，然後是“編輯信息”的界面，然後一步步下去。
先別寫任何程序代碼。 只把HTML和CSS的框架搞出來。 有關細節實施是後面的事。
上代碼編程
當模型框架看起來過得去又兼具一些足夠必要的功能時，就是開始上代碼編程的時候了。
在這整個過程中要記住保持機動彈性，要有多次反复的思想準備。 應該隨時有這個意識：捨棄某些已完成的步驟重新來過，如果成品看起來醜陋不堪。 數次重複這個過程是很自然的。
Getting Real 中文 繁中版 (1 2 3 4 chapters)
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（維基百科）日後的主旋律。
我們的軟件走的是一條類似的路。 我們的軟件並不追求成為所有人的寵兒。 我們的軟件是有自己的性格的。 他們找尋的是志同道合的用戶夥伴。 他們是在和有著同樣理想的用戶對話。 你要么上來一起，要么下車。
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（維基百科）日後的主旋律。
我們的軟件走的是一條類似的路。 我們的軟件並不追求成為所有人的寵兒。 我們的軟件是有自己的性格的。 他們找尋的是志同道合的用戶夥伴。 他們是在和有著同樣理想的用戶對話。 你要么上來一起，要么下車。
訂閱：
意見 (Atom)