兩個故事 Two Stories

我要說兩個故事，都是我過去工作時發生的。我認為這兩個故事足以清楚闡明，管理良好的科技公司與一團亂的科技公司間有何差別。最終的差異在於相信員工並讓他們把事情做好，還是把他們視為作業員對待，必須不停監視控制以免偏離主題並造成破壞。

我首次工作是在微軟，第一份任務是要想出一套新的 Excel 巨集語言策略。很快的我就寫出第一份 "Excel Basic" 規格初稿(後來發展成 Visual Basic for Applications，不過那是後話了)。不知怎麼的，微軟裡有個叫「應用架構組」的神秘小組聽到這份規格。由於他們認為自己就是負責集語言策略之類的東西，當然得關心這份文件。於是就要求看看我的規格。

我到處問應用架構組是什麼來頭，不過似乎沒有人認為他們是玩真的。原來這個組只有四個人，是最近才請來的博士(這就微軟而言很罕見)。我把我的規格印了一份給他們，還去跟他們開會看看能否聽到什麼有趣的東西。

其中一個說：「哇啦哇啦！」另一個又說：「哇啦哇啦，哇啦哇啦哇啦！」我不認為他們講得出什麼有意思的東西。他們非常迷戀子類別繼承(subclassing)，似乎認為在 Excel 寫巨集的人會用到大量的子類別繼承。無論如何，最後其中一個人說：「不錯，這些全都很有意思。再來還要做什麼？要找誰批淮你的規格呢？」

我笑了。雖然我在微軟只待了幾個月，也知道沒有什麼「某人批淮我的規格」這種事。慘啊，沒有人有時間讀我的規格，更別提批淮了。程式師每天都在催我多寫出幾頁，讓他們能多寫點程式。我的主管(還有他的)已經講得很清楚，沒有其他人懂巨集或者有時間去做這件事情，所以不管我做出什麼東西，最好是正確無誤的。而在微軟這個怪研究小組工作的博士卻假設事情會更正式一點。

我很快就明白，應用架構組對巨集的瞭解比我還少。至少我還和幾個巨集開發人員和Excel老前輩談過，知道實際上大家是如何用 Excel Basic 的，不外就是每天重新計算某張試算表，或者依照某個模式重新安排資料等等。不過應用架構組認為巨集只是個學校習題，也不知道實際上大家都是用巨集在做什麼。其中一位感受到壓力，就提了一個想法：既然 Excel 已經有底線和雙底線功能，可能會有人想寫一個巨集去做三底線。是啊，真低級。於是我開始儘可能的婉轉地忽視他們。

這似乎惹惱了應用架構組的頭頭 Greg Whitten。Greg 好像是微軟員工代碼六號的元老。他從盤古開天起就在這裡了；沒有人能明確指出他做過什麼事，不過他常常跟比爾蓋茨吃午飯，而 GW-BASIC 是依他的名字命名的。Greg 召開了一個「大」會議，開始抱怨 Excel 團隊(指我啦)如何惡搞巨集策略。我們逼他提出明確的原因，不過他的論點就是沒有說服力。我這個大學剛畢業的菜鳥和六號老員工爭論而且顯然贏了，感覺真是不錯。(你能想像這種事會在那種穿灰法蘭絨西裝的公司發生嗎？)當然很重要的原因是程式團隊(由現在已經是微軟副總的 Ben Waldman 帶領)的全面支持，因為程式團隊負責寫程式，所以他們對於做事的方法有最終的決定權。

我很樂意讓事情到此為止。不過如果應用架構組需要人關心想再吵架也沒關係。他們想要我就會奉陪，只要能讓程式師專心做事就好了。不過後來發生的事情更有意思，而且讓我很感動。我跟幾個同事在 Redmond 的晴空下吃午飯，Pete Higgins 朝我走過來。當時 Pete 是 Office 部門的總經理。我當然知道他是誰，不過不認為他會瞭解我。

「約耳，怎麼回事？」他說：「我聽說你跟應用程式組有點過節。」

「哦，沒有啦。」我回答：「我都可以搞定。」

「不用多說，我瞭解了。」他說完就走了。第二天就有謠言傳回來：應用架構組解散了。還不只這樣，小組的成員都分散到微軟不同的部門，而且離得很遠。我再也沒有聽到他們的事了。

我當然是非常的感動。在微軟這家公司裡，如果你是 Excel 巨集策略的專案經理，即使來公司還不到半年也不要緊，你就是 Excel 巨集策略之神，連員工代碼六號的老員工也不能擋你的路。事情就是這樣。

這件事傳遞了一個非常強烈的訊息。比如說它讓大家對自己的工作更有責任感。也不能再用「管理階層批淮了規格」這種想法來當藉口，因為管理階層並不會仔細看他們的規格。管理階層只管雇用聰明人並安排工作給這些人做。另一個意義是表示這裡是個絕佳的工作場所。有誰不想成為所屬領域的王者呢？軟體本質上就很容易分割成小塊小塊的元件，所以總是可能分割出人員間的責任，讓每個人擁有一個領域。這可能正是軟體人喜歡在微軟做事的原因。

---

過了幾年我換去 Juno 工作。這是一個線上服務和免費電郵的供應商。這次的經驗和在微軟工作時正好相反。我底下有兩個程式師對我負責，可是我的直屬主管卻一直在破壞我的(很少的)權力，他跳過我直接分派工作給我下屬，而且常常沒通知我。連休幾天假這種小事，他都認為應該由他決定淮假與否。

進 Juno 幾年後，我去處理新的使用者登入功能。我要負責翻修整個 Juno 3.x(一個重要的改版)的登入流程。當時我已經是技術團隊裡相當資深的成員了；我的考績很好而且主管們似乎也欣賞我的工作成果。不過他們就是沒辦法信任我。大概是命令與控制那套老想法的緣故吧。

登入過程中有個地方要求使用者輸入生日。Juno 的登入程序很長，大約有 30 個畫面，要使用者填收入、喜好運動、有幾個小孩、年紀多大還有其他一百個左右的問題。生日只是其中很小的一部份。為了想讓登入程序再簡單一點點，我想把生日欄改成不限格式，這樣就可以輸入"8/12/74"或"August 12, 1974"或"12 Aug 74"或其他內容。(你曾經用過 Outlook 嗎？這就像 Outlook 一樣，隨便打什麼日期它都可以接受)。

我的主管並沒有深入瞭解就決定他不喜歡這個作法。對他來說這變成自尊心問題。他先吼了處理這個畫面的設計師(根本沒先告訴我)又再罵我。然後每天都提醒我一定要把它改成他要的樣子。接下來他找公司執行長來評估，還開批鬥大會讓執行長批鬥我的新設計。事實上連 Juno 的執行長都非常樂意干預公司最底層完成的工作。真是一脈相傳的標準作業程序啊。

我當然是很生氣。這其實只是件小事，不過是喜好而已。某些人會喜歡我的作法，而某些人喜歡他的。不管怎樣訊息已經很明確的：你他X的照做就是了。這是非常命令與征服式的心態，像是在比誰比較勇而不是在討論使用介面設計。

我並不是說這是我離開 Juno 的原因，不過它的確解釋了我離開 Juno 的理由：不管你多麼努力工作又有多聰明，也不管你是否在「負責」，你對再微小不過的事都沒有權力。把你該死的點子訓練以及聰明睿智放一邊，把那些讓我們付錢請你的一切東西通通都丟到一邊吧。而且 Juno 的經理很多，大概佔總員工四分之一，所以他們有的是時間可以到處亂伸手指，確定他們能掌控。在微軟卻是副總自己從九號大樓出來找你，確定你有權力能把事做完。這對比還真是強烈啊。

就某種程度而言，無能至極的管理流程是 Juno 之所以是一個紐約市公司而非西岸公司的因素之一，所以還不太能深入現代的管理風格。這也是 Juno 經理人經驗極度不足所導致的問題，而源頭則是在最上層，一位只待過 D. E. Shaw 的29歲執行長。他會干預每件能插手的大小事，連出狀況時錯誤訊息的字句也要管；這位執行長會定期大聲責罵敢質疑其睿智的部屬，然後部屬再把氣出在程式師身上，程式師只好回家踢狗發洩。相較之下，在微軟事情都是由最底層完成，大多數經理的工作好像只是到處閒逛，把傢俱搬開不要擋到路，好讓大家可以專心工作。

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.