借用 新創網站這樣開發才夠快 這篇格式，希望不要介意。主要是想闡述 getting real的經驗方法。
1. 用 rails
2. 只做現在小設計
3. 沒 註解
4. 沒 文件
5. 沒 圖
6. 沒 policy
7.沒 PM
8. DRI
9.沒 tune
10. 沒 fancy
PS. xdite version
2012年4月22日 星期日
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
訂閱：
意見 (Atom)