「向下」管理的工作術

Scott Adams 因為創造了一個禿頭老闆（用電腦人員的說法，會簡稱為PHB，Pointy-Haired Boss）的圖像，而會使得每一位經理永遠記得這個詆毀他們的人。這個挑剔的老闆形象，說好聽點，是無知；說難聽一點，是壞心與邪惡的丑角。以呆伯特（譯註：Scott於1990年代創造了這個漫畫人物，代表沒有能力的主管）及他的同類做代表，我們不需要討論這個禿頭老闆是什麼；但要了解他不是什麼。

這個禿頭老闆是不被尊敬的，因為他不了解，甚至不想去了解，就像是呆伯特及他的同類的一樣。多年在技術部門服務過經驗，告訴我們那些不瞭解程式設計人員的人，如果想要去管理、指導、或是指揮程式撰寫團隊，往往會造成一片混亂。但是，沒有當過程式設計人員的主管，很少有人知道這個道理。

贏得技術上的敬重
要能成功管理程式設計人員的唯一最大關鍵，就是要贏得你所管理的同仁或同事，對你在技術上的敬重。沒有這層尊敬，你的所有管理意圖，都會被主動或是被動的阻撓。這也就是為什麼那些不了解程式設計人員的主管，會難以有效地管理程式設計人員。這在很多技術領域上都是一樣，但是在程式設計人員的世界裡，更是真理。

贏得技術上的敬重有幾個方向：
● 了解電腦程式撰寫的藝術
● 有很好的職涯記錄
● 在技術上做些值得讚賞的貢獻
● 趕上新技術的趨勢
● 在技術或專業的社團中，扮演積極的角色
● 展現強烈的個人價值

要了解程式設計人員，你對工具、流程、及電腦程式撰寫的藝術必須先要有深刻的認識。你了解越深，你越能與你的同仁有對話，就越能贏得他們的尊敬。有一位微軟的架構師就曾這麼說比爾蓋茲，”蓋茲回答程式設計人員們的問題不過就是在程式碼裡的位元與位元組（譯註：bits and bytes電腦中的數位單位）中打轉。他總是能在技術領域中，站穩他的腳步……他因為可以幫那些部屬解決技術問題，而獲得他們的尊敬。”

由於技術是無影無蹤的，以致於很難對外界用任何形式展現。因此當你在考慮任用一位經理時，你可以請他提供一份在軟體開發展業中可資證明的記錄，而這份記錄最好是會讓他即將要管理的程式設計人員們崇拜。

有很多方法可以建立個人紀錄，最簡單的方法就是在同一個組織中，先成為卓越的程式設計人員/技術組長，再被升遷為經理。這當然有它的難度，但是做為一個卓越的程式設計人員，自然會有足夠的份量，且會得到同事及未來部屬們在技術上的敬重；同時，在尊敬的基礎下，也可以加速建立一個很好的團隊文化。能夠深入了解技術團隊與團隊組織中的經理們也是有好處，可以跟你的團隊容易溝通。

另一個可以增加你的記錄，並得到尊敬方式是開發或管理被你所管理的團隊很熟悉的軟體或是產品。

Mickey個人的管理生涯是從成為Evan & Sutherland公司的主要貢獻人開始；在他的領導下，完成一個圖形資料庫專案，後來被昇為經理。他的部門負責開發公司的下一代圖形產品。之後，因為他在E&S的工作盛名遠播，被Pixar挖角過去。有了E&S及Pixar二家公司在履歷表上後，讓他在未來的職涯中，得到了技術上某些程度的尊敬。

Ron的管理職記錄是從蘋果公司開始；他是當時最新型65816微電腦組合語言使用說明書的共同作者。當蘋果決定採用65816當作Apple IIGS電腦（介於Apple I I及Mac麥金塔之間的產品）的核心，Ron被指定撰寫Apple IIGS的展示程式，擺在全世界的蘋果商店裡，向客戶推銷Apple IIGS。

這使得Ron因此踏上的系統程式設計人員的路，帶領團隊一路發展Apple II 到Mac麥金塔的圖形介面。娛樂產品公司Berkeley System因此找上了他，請他擔任工程部總監。後來又領導其他二家娛樂軟體公司的工程部門。Pixar和Apple對Mickey與Ron來說，是很重要的參考記錄。其實，所有記錄都可以用些力氣去加強或是包裝。在職涯管理中，這是很重要的一環，每一位程式設計人員或是經理，都應該很努力去經營。找機會做些貢獻、在人群中站出來、建立些屬於自己的傳奇。例如可以是很單純的開發自由軟體專案（open source project）、或在自己的部落格分享專業，找到適合你的方法。

參與相關的技術社團或組織，對你的記錄有幫助。任何一個都可以提昇你的技術能力。參加任何一個組織的年會或是地方分會活動，都有助於與技術先進們學習，且可以增加你個人的人脈。

其他可以在技術上得到尊敬的方法還有：取得更進一步的技術學位、擁有專業證照、發表技術論文、開發軟體、申請專利、寫書、建立自己專業網站、開自己的公司、成為有名氣論壇（如：Slashdot）的貢獻者……等等。

當Ron還在管理蘋果Macintosh團隊，發展桌面圖形介面Finder時，他開發了分享軟體，像是生日提醒等小程式。Ron知道有些官方文件是錯誤的，他寫了二本蘋果技術小冊子，讓蘋果的開發工程師可以更容易把事情做對。他也曾把這事和他的技術主管做過深入討論，他們把Finder的相關程式碼拿出來審查，也因此改正了Finder的幾個錯誤。這些都有助於得到團隊成員對你在相關技術領域上的尊敬。

管理不同型態的程式設計人員
我們的經驗告訴我們，如果你管理不同型態的程式設計人員，可以有一些不同，那會比較容易成功。

系統程式設計人員/架構師（system programmer/architects）
例如，系統程式設計人員/架構師（system programmer/architects）是典型的最大型公貓──最敏感及最個人主義的；這也是個人表現差異會最大的一個群組。少數”優秀系統程式設計人員”可以把十分複雜的系統，架構成非常高雅，但在概念上是相形簡單。唯有這樣的設計，才能使得其他程式設計人員的工作會簡單許多。

Mickey想起他在Broderbund公司時，就有這麼一位優秀的系統程式設計人員：”這位程式設計人員建立了一個系統，可以跨平台（支持各種版本的windows與MacOS）的開發幾乎公司所有的產品。他把應用軟體程式設計人員從各種作業系統與硬體平台中獨立開來，不再需要擔心聲音、圖形、動畫在不同平台中的問題，也解決了各種硬體效能的問題。他稱此系統為Mohawk（Most heinous applications writing kit，最令人髮指的應用程式撰寫工具包），不是真的因為系統難以使用，而是說萬一有了問題，你就必須用它來處理，而是它，可能很難打交道。”

“ 為了能夠讓應用軟體程式設計人員工作，他又發展了一套系統，用來創造動畫故事書，只要使用說明性質的腳本，完全不需要撰寫程式，就可以直接由動畫家、聲音設計師、及技師合作創造出更節省成本的動畫故事書。這些動畫故事書太成功了，以至於引發了Broderbund與Random House成立合資企業，與著名的童書作者出版一系列兒童動畫故事書。”

“ 我把大部分Broderbund公司早期至90年代中期的成功，歸功於這位真正偉大的系統程式設計人員的單人貢獻。這不是說要抹煞其他人傑出的表現，只是這位程式設計人員一個人的貢獻，使得其他所有人的工作變簡單了，也才能創造出更好的產品。”

“ 然而，對那些需要直接與他一起工作的人來說，他們一定不會同意他把他們的工作也變簡單了。他可能很自大傲慢，防禦心也很強。如果有人對他的系統提出問題，他會讓對方十分悲慘，直到證明問題真的是他的錯為止。然後，他會把問題修復，通常是既快又輕鬆就做完了。”

“ 因為他是向我報告，所以，我也感到頭痛。但是我肯定他真正是位有才能的人，而且獎勵他的貢獻──雖然比不上他給公司帶來的效益，但也夠好了。這是一個兩相權宜的行動，一方面獎勵他，一方面引導他不要跟同事相處不合。我花了很多力氣在裡面，但是值得。”

這種稀有的天賦只能比喻成其他的偉人，像是鋼琴家、美術家、詩人、及其他。也因為稀少，筆者相信應該給這些優秀的系統程式設計人員更大的空間。這常常是需要信任，可以不要一路監控的極度信任。筆者曾花很多管理時間去找理由再繼續投資由優秀系統程式設計人員所領導的專案，它沒有必要或足夠的需求審查、沒有時程、也沒有里程碑。長期來看，這種對稀有傑出個人的信任，很少會有錯。他們總是會有結果產出，雖然幾乎不會準時或在預算內；但是，最後的產出絕對值得多花的那些時間與金錢。

應用軟體程式設計人員
應用軟體程式設計人員比起系統程式設計人員來說，就要簡單管理多了。一般來說，他們沒有系統程式設計人員那麼敏感，他們的進展也比較容易看得到。那是因為大多數的應用程式都有介面，一個好的經理可以很容易評估進度。

筆者的經驗是，應用軟體程式設計人員通常需要與應用軟體的使用者有很多的互動，這會使他們對使用者的需求更加敏銳；在管理上也不會很那麼多問題。

資料庫程式設計人員（Databaseprogrammers）

資料庫程式設計人員（Databaseprogrammers）比其他人都要不透明，雖然一部分的不透明是來自於他們所使用的特殊語言，他們說：schemas、tables、queries及其他。若要有效的管理資料庫程式設計人員，需要協助他們像電腦科學家一樣的思考──而不要像表格的受託人一樣的思考，只會狹隘的在SQL指令所存取的行與列之間打轉（譯註：資料庫是以表格table為單位，由行column與列row所組成，外界需透過SQL指令，進行存放或擷取資料庫中的資料）。

筆者的經驗是硬體正嘗試把資料庫程式設計人員從優化資料庫（database optimization）的功能中抽離，那本來是關聯式資料庫中資料庫管理員該做的事情。其實，筆者認為資料庫程式設計人員應該要考慮到優化的問題。我們太常聽到一句話”有了今天快速的硬體，我們根本不需要考慮優化的問題了。”對小型的系統來說，也許是對的；但是，對大型資料庫或是上線系統來說，如果想要隨時做彈性擴充，就必須要從一開始就要好好的設計與優化，以便充分利用到硬體的效能。

Ron回憶到他在Forensic Logic時所遇到的問題，當時線上系統的資料庫急需做執行速度的調整，希望能有倍數以上的成長。單靠資料庫管理員的調整，很難可以達到倍數的效果。Ron問他的資料庫管理員是否會組合語言，他說他會。於是，Ron帶著他直接調整記憶體的行列，而不是用高階的SQL指令作表格層的優化。結果很顯著的加速了好幾倍，當時那位資料庫管理員帶著”啊哈”的表情說：”你讓我的想法超越了原有的框架了。”

另一個資料庫程式設計人員常常被傳統想法所限制的例子是發生在Gracenote，對資料庫團隊而言，從合作夥伴中注入與比對元資料（譯註：metadata，描述資料的資料）的流程，是一件持續性的艱鉅挑戰。Mickey回憶說，”我們有以「打」計算的資料需要持續更新，每當合作夥伴一有新唱片發行，就會需要輸入到龐大的資料庫裡。這流程中需要作大量的文字比對，而這項比對又不要求完全一致的比對，因為一樣的元資料，可以用不同的方式表達（例如：披頭四的唱片可能出現為the eatles、Beatles, The、或拼錯為The Betles、）。

“ 絕大部分資料庫管理系統的時間是花費在文字比對上，資料庫程式設計人員一直在調整文字比對的演算式，但卻一直達不到我們要的目標。這個解決方式也是一個超出框架的想法，就是把文字比對的功能從資料庫中完全移除，改在一個專屬的伺服器去處理。在專屬機器上調整文字比對的演算式，直到滿足我們的期望為止。這個解決方式不會出自於資料庫程式設計人員的腦中，必須要我們協助他們，擴展他們的想法。”

如同優秀的系統程式設計人員，優秀的資料庫程式設計人員也很在乎在他們資料庫上執行的系統；會注意資料庫所在的硬體及處理器；資料庫上儲存的大批資料；連結到資料庫上的方法；還有其他與該資料庫有關的環境細節。

Mickey回想起在Gracenote時，有一次升級行動造成了好幾個月的嚴重問題，因為升級前，沒有考慮好檔案系統的細節：”就如同許多次的更新，為了改善效能而執行升級。這次也是，Gracenote需要更新它的網路檔案儲存系統，期待會有更強的線上能力及更好的整體績效。當系統測試與正式初期看起來都不錯，且預期的效果也都達到。然而，當所有的資料庫應用程式全部上線以後，整體的效率比起剛被換下的舊有檔案儲存系統還要差。詢問過系統整合工程師、廠商、硬體系統供應商（昇陽Sun及Net App），還是百思不得其解，只能猛抓頭。測試再測試，但是這個問題依然存在未解，即便過了幾週甚至幾個月。

“ 最後，一位系統管理員想到了，新的檔案儲存系統的段落長度（block size），沒能和昇陽機器上之虛擬記憶體的頁長度（virtual memory page size） 相配合好，以致於當資料在檔案儲存系統與記憶體之間轉換時，會引發一些延遲時間。這一個小小的參數設定，影響了整個系統的整體效能。”

雖然這是個特例，但也指出了缺乏對資料庫所處環境細節的了解，可以對資料庫整體效能產生巨大的影響。只有少數的資料庫程式設計人員會強迫自己更廣泛地接觸今天資料庫管理系統所組成的各個環節。

鼓勵你的資料庫程式設計人員去深究，勇於獎賞少數願意伸展觸角到資料庫管理系統世界的資料庫程式設計人員。

使用者介面與網頁工程師（UI and Web developers）

使用者介面與網頁工程師（UI and Web developers）如同其他程式設計人員一樣，但通常只用高階語言及工具開發。這使得他們的技術性比較低，而較為仰賴他們所使用工具的效能──他們太常被他們的工具所綁架了。這些程式設計人員所面臨到的反覆變動，會比我們所討論過的都要多許多。這表示你必須確保你有對的員工，他們可以接受尚未確定的需求，很快的回應給客戶，然後反覆的接受使用者快速變動的需求。

Ron回想起”在Apple 時期，我會用報紙版面來比喻使用者介面。當我還在報社當記者及編輯時，我常跟版面美編一起工作。他會很小心的把需要的內容設計好，但是只要我們之間有一個人認為不妥，他就會毫不遲疑的丟掉，重新設計過。”同樣的，好的使用者介面與網頁工程師也必須要有相同的認識，當不適用時，只要是測試者或是產品經理有意見，就要願意修正，甚至整個重新來過。

就所有型態的程式設計人員而言，優秀的程式設計人員的表現可以超出同事好幾倍。無論是在我們的經驗，還是發生在業界都有無數的例子，可以清楚證明優秀的程式設計人員是如何有效率的完成工作。例如：之前提過在Broderbund的系統工程師。

但是如果你有一個都是優秀的程式設計人員的團隊，我想你也不會願意去管理吧！優秀的程式設計人員需要有一群適任的程式設計人員圍繞。他們負責日常業務，並產出可以預期的系統或產品。就像是美式足球隊裡站在前排負責阻擋與擒抱的隊員，是他們使得優秀的球隊更優秀。適任的程式設計人員，才是優秀團隊中的主要成員。

不論專案是如何組織，管理程式設計人員都不是一件簡單的事情。通常很難知道他們的進展到哪裡了，因為不像是製造業有可見的產出。就算可以，你也只能看到整個軟體系統的一部分，就如同冰山一角。因此，你必須仰賴其他可見的替代品，如：進度報告、專案時程、主要指標、及口頭回饋。最有效率的經理會有一群員工不怕說實話、遇到難解的問題會主動求救，不必等經理提醒。最有效率的經理總是保持開放的心胸、隨時接見員工、並仔細聆聽他們的任何意見及問題。（摘錄整理自第五章）

知人善用：IT主管一定要會的馭才管理術

Mickey W. Mantle、Ron Lichty／著；鍾文武／譯
博碩文化出版
售價：450元
 

Mickey W. Mantle

從事軟體開發超過40年的時間。在任職於3D電腦繪圖的Evans & Sutherland （E&S） 公司時，他參與了3D繪圖函式庫的開發；此項專案奠定了後來發展Silicon Graphics'GL的基礎，也促使OpenGL標準規格的制訂。自此之後，他開始接任管理職；工作經驗包含監督遍及全球的研發小組，以及管理含有多項專門領域的工作團隊。

Ron Lichty

從事軟體開發超過30年的時間。在1988年，他被Apple公司延攬，負責蘋果開發工具的生產管理，之後帶領專司於Apple II及麥金塔產品線的Finder及Applications兩大工作團隊，負責開發Apple特有的使用者介面。

最有效率的專案經理，能夠培養出一群「不怕說實話、遇到難解的問題會主動求救，不必等經理提醒」的員工；他也總是保持開放的心胸、隨時接見員工、並仔細聆聽他們的任何意見及問題。