The Joel on Software Translation Project:兩個故事

From The Joel on Software Translation Project

Jump to: navigation, search

兩個故事

作者:周思博 (Joel Spolsky)
譯:Paul May 梅普華
Sunday, March 19, 2000
屬於Joel on Software, http://www.joelonsoftware.com

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

Microsoft_Campus.gif

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

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

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

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

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

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

Cactus.jpg

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

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

「哦,沒有啦。」我回答:「我都可以搞定。」

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

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

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


Times_Square.jpg

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

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

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

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

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

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

Hanging_Tree_in_Jaffa.jpg

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

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


Personal tools