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

文/堡壘文化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

瀏覽 938 次

覺得不錯的話就分享出去吧!

發佈留言

Back to top button