大衛．海尼梅爾．漢森
David Heinemeier Hansson
Ruby on Rails之父、37signals｜合夥人

在2004年初，大衛．海尼梅爾．漢森將37signals從一家顧問公司轉型為軟體公司，他為這家公司寫了第一套軟體——線上專案管理工具「BaseCamp」，接著又寫了專門支援多人即時訊息服務（Instant Messenger；IM）會談的「CampFire」、網路共享工作清單「Ta-da List」、容易上手的個人資料管理小幫手「Backpack」。

2004年7月，他釋出做為應用程式基礎的軟體框架，也就是開放原始碼的Web應用程式開發框架，名為「Ruby on Rails」（RoR），一推出就廣受Web應用程式開發人員的歡迎，漢森也在2005年獲得OSCON的「年度最佳駭客獎」（Hacker of the Year）。

2006年7月（此次訪談後），37signals總裁傑森．佛萊德（Jason Fried）在公司部落格中宣佈，37signals已經獲得亞馬遜總裁傑夫．貝佐斯（Jeff Bezos）個人的少量資金挹注。

37signals一開始並不是由你創辦，對嗎？
37signals是在 1999年由傑森．佛萊德創辦，當初是網站設計公司，後來因為推出Basecamp而轉型成軟體公司，我是 37signals的web 2.0開發小組成員之一。

所以Basecamp可以說是37signals這家公司轉型的關鍵嗎？
公司轉型並非一蹴可及，當我們開發 Basecamp的同時，手邊還有一大堆客戶的專案要完成，所以我們不能花太多時間在 Basecamp上，畢竟那不是客戶需求，那只是我們為了更有效率管理客戶專案而自行研發出來的工具。

談談當初Basecamp上市以及公司轉型那段時間。
大學畢業後，我到 37signals當約聘人員，其他人負責設計，我負責程式。幾年後，我們發現需要一個工具來管理客戶專案流程，否則彼此之間都不知道工作進度，看起來沒有條理也不夠專業。

於是大夥兒想到可以利用部落格（blogging）的方式來將客戶資料分類，我自己已經有一個 Loud Thinking部落格，而37signals則是在 Signal vs. Noise，所以我們突然想到，何不將部落格概念運用在專案管理上？

專案的部落格是 Basecamp的第一部分，大約在一個月後就完成了，然後我們開始利用它來管理 Basecamp，結果很快就能自己管理，換句話說，是利用 Basecamp來建立 Basecamp。

當我們向同行展示 Basecamp，才知道其他人也有一樣困擾；市面上提供給小型公司使用的專案軟體很少。像微軟的 Project軟體和其他重量級軟體都需要仰賴嚴格的路徑控管，對於兩百人的專案或許能良好運作，但不適用於小公司。於是我們開始思索，這可以解決顧問公司的需要。而且，當我們得到非常熱烈的反應，便發現這是一個很好的時機，可以開始仔細想想如何為 37signals開發這類產品。

你還記得當時的情況嗎？
這不僅是應用軟體蓬勃發展的時刻，我們對其他人的建議也很尊重，我會對他們說：「我也這麼認為！」我們如果故步自封就太自私了。

人們最喜歡 Basecamp的哪些特點？
有趣的是，大部分是對 Basecamp所「沒有」的功能感興趣，因為他們已經習慣那些功能繁多的大型軟體，可是事實上，他們只需要十分簡單的功能。所以我們陷入了進退兩難的境地，不知道是該研發像微軟 Project那種大型軟體，還是像電子郵件一類的軟體來管理專案，兩者間有天壤之別。透過電子郵件往返來管理專案實在不適合，但如果用大型軟體，就要調整處理問題的方法來適應。

研發 Basecamp就是要創造一個比電子郵件更棒的軟體，我們的目標不大，所以做了一些決定，以便讓問題簡單化。我們試著在一開始盡量減少程式撰寫，這是比較明智的地方，因為減少程式設計，所以最後成功設計出簡單的軟體原型。也由於我是唯一程式設計師，一週只有 10小時花在 Basecamp上，只要能開發出簡單的模式就能創造雙贏局面。

由於 37signals沒有多餘資金，他們只能以顧問工作的收入來支付我的薪水。而整個開發過程中，我們只能排出 1/4的人手來發展這套軟體，且每位程式設計師最多只能貢獻 1/3的時間。我們體認到，這些艱難重重的過程，對於 Basecamp的發展，其實是一項偉大的禮物。

事實上，由於發展模式的限制，我們不得不將注意力集中在需要的地方，在整個研發過程中盡量減少編寫軟體的工作。同時間，一直有客戶給予：「我喜歡你們的軟體，它簡單易用，擁有我需要的功能，而不是一堆無聊的功能。」這樣的回饋，不過，我們不會因此而志得意滿。

如果一心要開發真正為人所需的軟體，就不會多花力氣去寫用不到的功能，這就是為什麼我不擔心與大公司競爭。如果微軟決定效法 Basecamp開發小型軟體，他們會說：「找 20個人來執行這個案子，我們會給他們六個月的時間完成。」因為在大公司的環境中，都會以大量資源研發專案，但是如果沒有設定條件限制，永遠沒辦法開發出像 Basecamp這樣的產品，什麼功能都做當然吸引人，但是記得不要做得太過頭了。

我們不見得是多麼偉大的程式開發者，因為我們面對「限制」這項嚴峻的考驗，才能成功開發這樣的軟體。如果把我們這群人放在大公司，有充分資源和資金，一定沒辦法寫出 Basecamp這樣的軟體。

你曾擔心過任何競爭對手的產品嗎？
有一些公司曾經嘗試要開發類似的軟體，但大部分都是想要做面面俱到的管理軟體，包括記帳、時間管理等等，我們從來沒有想過要加入這些功能。

我們選擇開發一些簡單功能的軟體像專案部落格、重要事件追蹤、文件和待辦事項共享。除此之外沒有其他功能，我們只想改進這些元素。

Basecamp另一個成功的原因也很有趣，因為它並沒有特別針對某個行業的使用者。我們一開始只是想要為有創新服務的企業開發軟體工具，結果卻從來沒有特別針對創新服務業，反而可以用在各行各業，從婚禮管理、居家裝修以及建教合作。 Basecamp成功吸引那些需要專案管理協助的人，主要是因為它並沒有特別針對某個行業。

這就是為什麼我認為如果我們有更多資金和時間，然後嚴格地只針對創新服務企業所需要的功能增加到 Basecamp上，反而會失去其他更多使用者。

所以你在開發這個專案時，並沒有規劃市場行銷的預算，後來呢？
在它上市時，我們沒有花一毛錢做廣告，雖然 Basecamp採取月租制度，但是一開始註冊不必繳費，如果你只要管理一個專案，就完全免費，所以很多人都選擇先管理一個專案來試用 Basecamp。

一旦他們需要管理更多專案，可以點選到升級頁面去下載付費版本。我們有好幾種等級付費版本方案，從免費到花一點點錢都有，第一種付費版本是一個月 9美元，就能管理三個專案並且上傳檔案，即使最貴的版本，一個月也只要支付99美元。因為我們是採月費制，顧客風險很小，使用者可以註冊使用兩個月，如果不再需要，很容易就可以取消，這個方法成為最強而有力的行銷方式。

此外，公司的部落格「 Signal vs. Noise」在網路開發社群有不少擁護者。 Basecamp最大市場是創新服務的公司，他們都知道 37signals在做什麼，所以我們另闢蹊徑；首先，我們先建立讀者群，然後再了解他們需要的產品。 Basecamp推出前，我們每天在部落格發布有關 Basecamp的新聞，撰寫評論，這種方法讓 37Signals有廣大的讀者群做為基礎，更容易打進市場。

大部分的新客戶都是從其他人或是閱讀部落格而知道我們，他們註冊免費版本，這就是最好的線索。維持這些線索不必花任何錢而且值得，因為他們雖然使用免費版本管理專案，卻由於免費的關係，讓我們累積一大群產品支持者。 30天內試用資格都不會取消，所以一開始我們就和顧客建立很好的關係，對於產品銷售非常有幫助。

有沒有遇到過什麼困難呢？
我們犯了不少錯誤，產品發布時間延遲了一個月，因為我們希望能針對 99美元、 299美元、 499美元等不同方案，一年寄一次帳單，還花很多時間建立收費系統。沒想到，上市三天前，銀行才通知說不准我們以這種方式寄帳單，因為這項服務將要保證一年，萬一我們中途倒閉，對他們來說風險太大，畢竟我們和銀行來往時間很短。

結果，為了一年寄送一次帳單而製作的大型收費系統完全無用武之地，我們必須改成每個月寄送帳單。不過這麼做也有好處，產品延後推出一個月，我們改為每月收費，但是費用增加一倍。原來的方案是一年 99美元，現在則是一個月 19美元，一年就等於是 224美元。所以，實際上是提高價格，並且幫小公司提供風險比較低的付費方式，有的小公司其實不需要買一整年的方案。

在早期開發階段，技術方面還有一個錯誤，因為當時我們一直認為 Basecamp是專為創意服務公司所開發的軟體。假設你的公司擁有一位客戶，兩者之間是一對一的關係，例如，在資料庫中有一個客戶 ID和公司 ID，彼此可以透過這兩個ID建立關係。但如果一位客戶要和兩家公司往來， Basecamp就無能為力。為了這個錯誤的假設，我們花了大約一年半的時間處理這個問題，這實在不是一件好事。

另一個有趣的失誤是我們沒有考慮到時區。 Basecamp以每位用戶都使用中央標準時間（ Central Standard Time）來運作，即使和芝加哥（ Chicago）有時差七小時的哥本哈根（ Copenhagen）也用中央標準時間。所以在澳洲的用戶會慢一天。因為我們通常沒有期限壓力，都是做自己想做的事，早兩小時或是晚兩小時沒差，所以不太在意時間，但並不是每家公司的作業流程都是這樣。

而且 Basecamp標示時間的地方很少，只有在意見欄標示時間，發表意見時會標示時間和重要記事。除非你在中央時區，否則不會注意到這個問題。例如丹麥（ Denmark）凌晨七點時，系統還是顯示前一天的日期，這樣對於講求時間精確的企業會是個大問題，尤其是澳洲，相差整整一天的時間，我們也必須設法解決。

你是唯一的程式開發人員嗎？
是的，直到 2005年二月才有第二位程式開發人員加入。整整一年時間，我是 Basecamp唯一程式開發者和系統管理員。

除了負擔這些責任，你還要開始研發 Rails專案，你如何管理這麼多事情呢？
當你必須做類似 Basecamp這樣的專案，可是一星期只有 10個小時，就不可以把時間花在沒有意義的事情上。所以，當你發現手邊工具對提升生產力沒幫助，就必須尋找其他工具。

這就是我為什麼要使用 Ruby，這對我是很好的經驗， Ruby對生產力的確有很大幫助。我用過 PHP語言、 Java和其他環境，都不能讓我這位唯一的程式開發人員交出成果。

所以我在 Ruby上面建立 Rails，讓我可以開發 Basecamp，並且以我們想要的方式開發 Basecamp。因為我們不想找其他程式開發者，想保留既有限制，這樣就只要開發自己需要的功能，我想這是 Rails成功的原因。它是在需要提升生產力的環境下，同時也在重重限制下產生的，我是在開發 Basecamp的時候一邊設計 Rails，讓它變得更完善。

為了進行開發 Basecamp，後來發現可以把 Basecamp所做的東西打包起來放到 Rails工具箱裡。隨著時間過去，這個看起來普通的工具箱卻越來越豐富，變成很有用的工具箱。從這段研發過程中我發現，其他人也可以用我們在 37signals開發軟體的方式——用最少的資源寫出簡單的軟體。

發布 Basecamp的時候，它的程式是由 4000行的程式碼組成，並不是很多。一位目前研究 Rails的人告訴我，他們在編寫一個 XML文件的過程，就用了 5000行的程式碼！

我們在 2005年二月發布 Basecamp，當時我也想把 Rails公諸於世。不過發布 Basecamp後實在太忙了，因為我們繼續推出一大堆新功能。

每次推出一個新產品，我們都會在 30天內進行更新，因為這樣可以讓使用者感受到產品的確有所幫助。如果他們在購買產品兩周後，發現產品有更新版本就會很高興。所以我們在市場上的成功祕訣之一，就是並不認為產品推出後就完成一切任務，我們從來不會說：「我已經把所有工作都做完了。」然後拍拍屁股度假去。為了證明這個產品一直很有活力，我們仍然繼續前進。

那年二月，我已經完成了 Rails的大部分框架，但是還不打算釋出，因為我想為它寫說明文件。長久以來，我一直習慣使用開放原始碼的軟體，很討厭那些可怕的說明文件，所以我不希望同樣的事情發生在 Rails上。我又花了兩個月的時間寫說明文件，直到 Basecamp推出三、四個月後才發布 Rails。

你曾經懷疑自己有辦法完成這些工作嗎？
有時候會，但一旦產生這種想法，就證明工作量太繁重了，我們就會換一種思考方式，看要怎麼做，才能以少一點的程式完成某一項功能，後來就可以寫出不錯的程式。所以，只要想研發新功能，就會腦力激盪，尋找如何把工作量減到最少的方法。

在開發 Rails的時候也是一樣，你會發現想要百分之百滿足所有人的需求是非常不容易的事，如果可以滿足 80%就已經很不錯了。

所以， Rails可以滿足 80%的需求，剩下的就只能透過其他專業軟體完成。釋出 Rails的時候，只有 1000行程式。因此，儘管我們已經做了所有事情，不過，還是沒使盡超人般的力量。我們的軟體程式比別人少，但每一行都比別人更有價值。

所以你大部分發明都是因為自己需要而非客戶需要？
正是如此。就意義上來說，以市場為導向是很好，這樣你才會知道市場的發展方向，但是不能讓客戶來主導產品開發。你必須是為了客戶需求而激發創新研發的能力，不過他們通常不知道自己想要什麼。對程式開發者也是一樣。如果你問他們希望有什麼樣的軟體架構，他們通常無法給出滿意的答案。你必須從各種資源中找到客戶的建議，然後以自己的專業來判斷產品發展方向。

你必須對軟體架構和產品發展有很強的判斷力，不能害怕拒絕別人的要求。我們並不排斥對客戶說：「也許 Basecamp不適合你，如果你有其他某某方面的需求，應該去找別的軟體。」

現在你們已經獲得一致好評，是否有投資者願意來投資呢？
很多創投公司已經表達極大的興趣，但是我們不想透過這種方式籌錢。因為我們看到太多公司因為籌到太多錢反而沒有好產品的例子，我們認為很少的資金反而比較能研發出很棒的產品，這樣才能專注於開發一項產品。

所以，我們很堅定地對自己說， 37signals不需要任何外來資金，甚至不需要擴大團隊。我們只希望以目前的產品好好為消費者服務，所以透過「 Signal vs. Noise」這個部落格，向那些打算籌措大筆資金並雇用大量員工來完成產品的公司傳達我們的信念：「如果你認為研發一款產品需要 100萬美元的成本，那你應該重新考慮這個構想，搞不好花更短的時間、更少的成本就可以完成。」本來要花一年時間，如果只用了一個月的完成？

當然並不是每一家公司都能這麼做，但是在網路時代，越來越多公司正朝著這個目標努力。


你們是不是曾經有被收購的機會？
我們從來不注意這種事情，不過，我們也不是對周遭一無所知。因為這家公司很賺錢，並沒有被收購的迫切性。如果明天有人要用一億美元買下這家公司，我會很愚蠢地說：「不，絕對不賣。」

最令你意想不到的事是什麼？
能依照最初的價值理念一直發展，這讓我相當驚訝。我們在開發 Basecamp過程中，即使成長快速，卻只增加過一個人手。所以我非常驚訝，我們不必寫許多軟體也能持續發展，有所成就。

37Signals的團隊成員住在不同地方，對你們是否也具有挑戰性？
其實我們覺得這樣反而是優勢，因為我們的位置有七小時的時差，可以分別獨立工作。如果在同一個辦公室工作，大家在一棟大樓裡走來走去，彼此間很容易互相干擾。像我們分散在不同地方、不同時區，就不會受到干擾，可以順利完成工作。

另一方面，我們主要是透過即時通訊（ IM）來溝通，這個方式占用的頻寬很低，所以不會干擾別人，除非有重要事情要當面溝通。不過和人面對面談事情，很容易就超過 30分鐘，但真正交換到的訊息有多少呢？所以，用即時通訊溝通其實就很足夠了。