作者:周思博 (Joel Spolsky)
譯:Paul May 梅普華
Thursday, January 18, 2001
屬於 Joel on Software, https://www.joelonsoftware.com/2001/01/18/big-macs-vs-the-naked-chef/
真是不可思議,為什麼某些全世界最大的 IT 顧問公司會做出最糟的成果?
為什麼那些最酷的暴發顧問公司剛開始時都有一連串成功的事績,成長的非常快,然後卻急速化為平凡?
我曾經想個這個問題,也思考 Fog Creek Software(我自己的公司)應該要如何成長。而我能找到最好的教訓是從麥當勞來的。是的,我就是在說那個可怕的漢堡連鎖店。
大麥克的秘密在於它們並不是怎麼好,不過每個漢堡不怎麼好的程度是完全一樣的。如果你願意忍受不怎麼好的食物,吃大麥克時絕對不會感覺任何絲亳意外的。
大麥克的另一個秘密是即使智商介「白痴」到「低能」之間,還是能生產出和全世界其他大麥克一模一樣的漢堡。因為麥當勞超大本的操作手冊才是它真正的秘方。手冊裡不厭其詳的說明每個授權店製作大麥克時必須確實遵循的步驟。如果大麥克的漢堡肉在阿拉斯加的安克雷奇要煎 37 秒,那麼在新加坡也會煎 37 秒,不是 36 秒也不是 38 秒。要做大麥克就是得遵循這該死的規則。
這套規則是由一些相當聰明的人(在麥當勞的漢堡大學)仔細的設計,讓笨蛋能和聰明人一樣照著做。事實上這套規則裡有各種的防呆設計(比如薯條在油裡炸太久會有鈴聲),就是要補償人的弱點。到處都有馬錶和各種計時裝置。還有一個方法是要確保管理人每半小時會檢查廁所是否清潔。(提示:他們不會的。)
這個制度基本上假設每個人都會犯一堆錯誤,而做出來的漢堡必須始終如一,而你單點漢堡時總是會被問到要不要加點薯條。
純粹好玩,讓我們比較麥當勞廚師(完全不懂食物只會確實循遵規則)和英國原味主廚Jamie Oliver 那種天才。如果你選擇現在離開本站,點那個連結去看原味主廚羅勒蒜泥蛋黃醬的 MTV 風格短片,我絕對贊成並祝身體健康。畢竟拿麥當勞和美食主廚相比實在是荒謬無比,不過請暫時壓下懷疑,因為這裡面有些道理可學。
原味主廚並不照什麼亂七八糟的操作手冊,也不會量任何東西。在他做菜的時候,你會看到各種食材到處亂飛。「我們只要多放一點點迷迭香,不會有事的,然後好好的搖一搖,」他說:「把它壓碎。真完美。然後灑在上面就好了。」(是啊,看起來他的確只是隨便灑上去。問題是我來灑的話就是不行。)只要 14 秒左右,他就即興創作了一道美食,海鱸片塞香草放在蘑茹和馬鈴薯上烤再加一點 salsa-verde。真是美味。
嗯,我認為原味主廚的食物顯然比麥當勞的東西好很多。雖然這聽起來像個笨問題,不過還是值得花一分鐘來問為什麼。這問題並沒有那麼笨。為什麼一家有著規模極鉅又有龐大資源的大公司,可以獲得最佳食材,現金多到不行,卻無法生產出一道好菜?
想像一下原味主廚「電視節目」做膩了改去開餐廳。當然啦,由於他是個名主廚菜又很棒,所以餐廳門庭若市,錢好賺得不得了。
當你擁有一家很賺錢的餐廳,很快的就會瞭解即使每天都客滿,即使一道前菜開價 19 美元而一杯可樂開價 3.95,利潤還是有限。因為一個主廚就只能做出這麼多菜。所以得再請另一個主廚,或許再多開幾家分店,或許還可以去其他城市開。
現在漸漸浮現一個問題,我們在技術業界稱為可調性(scalability)問題。當你想要複製一個餐廳,必須決定是要另外請一個能力與你相當的大主廚,還是要找一個沒那麼好但也沒那麼貴的年輕廚師。不過大主廚師可能會想自己多賺一點,沒必要替人打工;請年輕廚師的話,老顧客很快就會發現菜變差了,以後也不會再去分店了。
處理可調性問題的一般作法是雇用什麼都不懂的年輕廚師,然後讓他照著精確到絕不出錯的規則做菜。只要照著這些規則做,你也可以做出好菜!
問題是這方法不太行得通。好廚師即興創作所牽涉的事非常多。好的廚師在農市看到上等的芒果,就會即興做一道胡荽沙沙醬配當天的魚料理。馬鈴薯不夠時也會用芋頭片頂替。只會跟著指令的機械式主廚或許能在一切正常時生產出指定的菜餚,不過由於缺乏真正的才能和技巧,不可能真的即興創作。所以在麥當勞絕對不會有球根牽牛的沙拉。
麥當勞需要一種特定品種的馬鈴薯。他們在世界各地都有種這種馬鈴薯,還會照規格切好大量冷凍儲存以免短缺。預切及冷凍作業表示這些炸薯條不如新鮮的好吃,不過卻保證始終如一也不需要大廚手藝。事實上麥當勞有數百個預備作業,確保任何廚房裡請得到的笨蛋都能生產出品質一致的產品,不過是「稍微差一點」的品質。
到目前為止的總結:
你在 IT 顧問業可以看到完全一樣的情節。下面這個故事你聽過多少遍了?
我不需要在這裡指名道姓,這個循環已經發生過很多遍。所有 IT 服務公司都會貪心,希望成長的速度能超過找到優秀人員的速度,於是發展一層又一層的規則和流程來,幫助製作出「一致」但算不上一流的成果。
不過規則和流程只有在一切正常時行得通。前幾年到處都出現各種「資料庫(data-backed)網站」顧問公司,拿些「建立資料庫網站的十四項須知」之類的東西教出一堆生手來填公司職缺。(「小朋友,這個叫 select
敘述,去架個網站吧」)。不過現在網路泡沫破滅,而高階 GUI 程式設計和 C++ 技術還有真正的電腦科學需求突然起來,這些口袋裡只有 select 敘述的小伙子就面臨嚴峻的學習曲線,完全無法跟上。不過他們還是一直照著第 17 章資料庫正規化的方法在試,不過突然間這些方法已經不適合這個新世界了。這些公司出色的創辦人應該都能適應新世界,畢竟他們都是有才能的電腦科學家,什麼東西都學得會。不過他們所建立的公司是變不了的,因為公司用規則手冊取替了才能,而規則手冊無法適應新時代。
這個故事的教訓是?小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度,不過同時也會產生很多約束而激怒更多的聰明人。就我而言,有才華的廚師顯然不會樂於在麥當勞做漢堡,原因正是麥當勞的規則。是否如此 IT 顧問才如此吹噓他們的方法論呢?(來打我啊。)
這對 Fog Creek 有什麼意義?嗯,我們從來沒有把成為大顧問公司視為目標。我們一開始就把顧問工作視作一種手段,真正的長程目標是成為一直有利潤的軟體公司,而我們得做一些顧問工作來補軟體收入的不足。經過幾年的經營,我們的軟體收益已經成長到相當程度,顧問工作相對成為分心的低收益業務,所以現在只做對我們的軟體有直接幫助的顧問合約。你也知道,軟體非常地容易複製。每多一個人購買 FogBUGZ,我們就不用花任何成本就能多賺到一些錢。
更重要的是我們堅持雇用最好的人,如果找不到夠好的人,我們很樂意維持小局面(不過一年有六週休假,找人似乎不構成問題)。而且在找進來的人還不足以成為教導新人之前,我們拒絕再擴充。
這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.