專案的成功關鍵！賈伯斯：會發布作品才是真正的藝術家

文／堡壘文化

一九八三年九月，蘋果的麥金塔專案進度嚴重落後，團隊已經油盡燈枯，但還剩下很多工作要做。

蘋果的執行長暨該專案充滿遠見的領導者史帝夫．賈伯斯經過團隊辦公室的主要走道，並在附近的黑板上寫下後來他最知名的其中一句名言：「會發布作品才是眞正的藝術家。」

他寫下這句話，是因為他想強迫專案團隊更努力工作、更早結束專案，今日這句話成為許多領域創新人士的口號，但他們都忽略了當時賈伯斯強調的是發布， 而非藝術。

僅僅是發布某個東西，並不會讓你成為藝術家，然而，不管是藝術或是垃圾，世界要理解你創造出的東西唯一的方式，就是當你勇敢到能夠宣布已經做好了，並向全世界展出之時。

賈伯斯的名言讓人很容易忘記沒有人展開一項專案時，是計畫不要發布的。

沒有一整個聰明又努力的部門，心懷深沉又熱情的希望苦幹實幹了好幾個月，卻覺得等他們完成後，他們的成果會被裝進板條箱中，並運送到《法櫃奇兵》裡的倉庫，永遠不見天日。

所有熱情的開發者，都是受到能看見目標受眾使用他們開發成果的渴望所驅策；而且事實還恰好相反，多數擁有偉大創意的人，都會太快跳到發布這件事，並把他們第一個充滿靈感的晚上，花在幻想發布後世界會帶給他們多少榮耀， 即便他們根本就還沒有做任何事。

夢想是免費的，發布則需要自己爭取。發布任何東西都可能很困難，就算只是份大學的期末報告， 或是一頓感恩節晚餐。

現在就有數千名企業家和程式設計師正在空轉，要不是卡在似乎解決不了的問題上，就是執迷於很少用戶會注意到的細節。

在試圖發布的過程中，有很多狡猾的陷阱，這解釋了為什麼有這麼多人迷失在開始和結束之間，開發東西非常困難，不管你的準則是什麼，或你在牆上掛的是什麼格言，大多數專案都會超出時間、超出預算、或是遭到取消。

請你看看生活周遭所有的機器、書籍、工具、應用程式，這些東西能完成到產出根本就是奇蹟。

針對該怎麼克服發布出優質成果背後的挑戰，在這個思辨的核心中有個概念，源自艾瑞克．雷蒙的同名著作《大教堂與市集》。

這本書是有關開發軟體過程的各種觀察，其中提出了一個和所有工作相關的重要問題：要把時間投注在規劃一個精細的大型計畫上，還是直接開始，並在過程中找出辦法比較好？

你想像一下高聳摩天大樓的建築師，或是大成本電影的導演，你的印象很可能會是一名厲害的暴君，擁有詳盡的計畫，規範所有事情該怎麼完成。

這就是大教堂風格的思維，第六章提到的海濱鎭，就是根據一個精細的計畫建造，體現了這種方式。

至於另一種方法，則是請想像一下一個年輕的龐克搖滾樂團剛開始玩團，他們會從小地方開始，寫幾個簡單的和弦，然後很快修改，接著再次修改，每個團員都用自己想要的方式貢獻、借用、實驗、合作，這就是市集模式。

比起恢弘的中央規劃，工作社群會圍繞著某個構想形成並發展，許多知名的開源專案，例如 Linux 作業系統，都是採用市集思維開發，而這也啟發了雷蒙的著作。

然而，世界上有多數地方，包括大多數的軟體產業，相信的都是大教堂模式。

但在實務上，這其實是個錯誤的二分法，多數事物都是結合大教堂和市集模式完成，只不過兩者之間的平衡可能差很多。

不像興建摩天大樓，數位工作比較可以用市集般的態度漸進式改變。比起生產飛機、興建橋樑、甚至是做舒芙蕾，一個小錯誤就可能毀掉所有事，開發軟體的風險很少會這麼高，多數軟體其實是不受規範的。

相較之下，橋樑、醫療器材、汽車則是必須通過安全檢測，產品才能上市，這也導致了這類領域有嚴格標準。

擔心鑄下大錯或是進度落後，是世界上多數專案管理過程背後的動機，管理者經驗越豐富，看過的壞事就越多， 也有越多事必須試著避免， 我將其稱為「防禦性管理」，因為其目的是要防止一長串壞事發生。

防禦性管理很盲目，看不出執迷在防止壞事發生，同時也會遏止好事發生， 有時候甚至導致什麼事都不會發生。

WordPress.com 每天都會發布某個東西，常常是某個小東西，比如修復某個錯誤，或是細微的調整，但仍然是新東西沒錯。

我在二○一○年八月受聘進入公司時，WordPress.com 總共更新了兩萬五千次，而我二○一二年離開時，則是已經來到超過五萬次。

東尼．史奈德便用「持續部署」一詞來形容這個不斷進行小型調整的哲學， 所有點進使用 WordPress.com 主機網頁的訪客，看到的永遠都會是最新版本，很可能才剛發布幾秒鐘而已，程式設計師和系統設計師想多常發布，就多常發布。

這通常代表他們一完成就會發布，不用排隊測試、也不用互相檢查，不需要時程表或大計畫，因為根本不需要死線、日期、其他協調，也不需要什麼管理，因為根本沒有什麼要防禦的。

就算在最糟糕的情況下，搞不好某個版本不小心用該死的殭屍香蕉照取代了所有部落格，也可以回溯，讓軟體回到先前的版本，不過回溯程式碼頗為罕見，公司鼓勵程式設計師直接進行其他調整以修復問題，並規定所有發布了某個東西的人，都必須待在線上幾個小時，保證一切運作順暢。

缺少宏大的時程表，也移除了許多專案創造出來擔心進度會落後的恐懼，並以微小卻高頻率的成果取代。

我們讓狀況越來越好，工作感覺比較像是在吃一頓西班牙下酒菜，每隔幾分鐘就會有小盤小盤的美味食物送上桌，你不需要排隊，或是等到下一餐的時間，用戶也不需要等，不管他們在做什麼，使用的永遠都會是最新版本。

而且所有員工也都能在 IRC 上，看到程式設計師之間互相分享新的調整，我們通常稱之為修正檔，以便在發布前協助測試。

有時候光是一天就有可能發布二十五個修正，在忙碌的日子中，IRC 會充滿程式設計師彼此協調他們的發布，確保不會互相衝突，在旁觀察這些總是相當有趣。

相較之下，我一九九○年代在微軟開發 Windows 時，我們每隔幾年才會發布一個新版本，而同年代的瀏覽器戰爭期間我負責開發 IE 時，頂多也只是每個月發布一次。

由於我先前參與大型專案的經驗，讓我許多朋友都覺得在 WordPress.com 的混亂中工作， 對我來說會是件很困難的事。

結果調整起來還蠻簡單的，當時微軟的 IE 團隊有個相同的東西，叫作「每日開發」。

我們每天都會發布軟體的新版本，但只限於在公司內部流通，每一天都會彙整前一天所有的調整發布，也鼓勵每個人都安裝來用用看，以此為開發品質提供固定回饋。

加入新功能的過程中有珍貴的歡笑，也有悲慘的時刻，在日子好時開發品質非常好，我們就會將這些版本稱為「自行運作」，也就是「能夠安全在你的電腦上運作」；

品質普通的版本叫作「自行測試」，也就是建議你只安裝在測試用的電腦上就好，或是趁同事不注意的時候裝在他電腦上；

品質最糟糕的版本則叫作「自行燒焦」，表示你要是敢安裝，那不管裝在哪台電腦上都會報廢。

只要我們連續三天發布的版本都是自行燒焦，就會暫停所有開發工作，直到我們讓開發品質恢復到正常水準，這是個防止專案品質爛到谷底的方法。

在 WordPress.com 這邊的發布也是依據同樣準則，只是過程加速，而且也向用戶開放而已，我不覺得缺少大型計畫或時程表是個問題，事實上，我大多時候都感到自由。

對任何曾經參與過大型專案的人來說， 這一切聽起來都超瘋狂的，沒有時程表要怎麼做事？怎麼能沒有安全措施？事情為什麼不會直接爆炸，或是從頭到尾都互相衝突？

這種方式之所以可以運作，主要原因便在於 Automattic 信奉一套反直覺的準則：安全措施不會讓你安全，而是會讓你懶惰。

大家在駕駛有防鎖死煞車系統的車子時，會開得更快，而不是更慢；美式足球員因為他們的防護，也會承擔更多風險，而非更少。

在 Automattic，打安全牌的陷阱會受到抵制，大家比較是受到自主感驅策，而不是什麼宏偉的工作原則，基本概念是如果大家都聰明又彼此尊重、不會把事情搞砸，那麼過多安全措施反而會擋路。

相較之下，員工在此受到信任，更擁有權力可以快速發布成果。

本文摘錄自《不穿褲子工作的一年》，堡壘文化出版。

瀏覽 935 次