如何扮演程式經理的角色？
From The Joel on Software Translation Project
製作偉大軟體的秘方之一是：有個好的程式經理。你的團隊裡應該沒有這號人物，因為大部分的團隊都沒有。
Charles Simonyi，那位發明了「所見即所得」(WYSIWYG) 文字處理軟體、跟 Martha Stewart 約會、賺進價值億萬的微軟股票而且上了太空的天才程式設計師，是首位嘗試著組織超大開發團隊來解決人月神話的人。他創造了這樣的制度：由一位超強工程師來設計系統裡最高階、最上層的函式，然後一群菜鳥工程師就根據這些設計來實作較低階的函式與其中的細節。這「超強工程師」的職位就是本文所說的程式經理。雖然 Simonyi 如此的聰明，但是這個方法確不是很高明。我猜，原因是沒有人想當菜鳥工程師。
八經零年代後期，微軟 Mac Excel 團隊的 Jabe Blumenthal 回收「程式經理」這個職稱並拿來作為其它用途。他注意到軟體規模日趨複雜，幾乎沒有工程師有時間搞清楚怎麼做出好用且有用的軟體。但是工程單位卻沒有人有時間和高舉顧客需求的大旗的市場單位做溝通，或是把這些 MBA 專用語言轉換成真正有意義的功能。設計一個產品要做的事真的好多：跟使用者溝通、可用性測試、檢視競爭產品還有努力的讓產品變得更簡單易用。但是大部分的工程師真的沒有時間做這些事情（或是不適合做這些事情）。Blumenthal 重新定義了「程式經理」這個職位的工作內容。
程式經理做些什麼？
此後，程式經理的工作變成：
- 1. 設計使用者操作介面
- 2. 撰寫功能規格書
- 3. 協調開發團隊
- 4. 作為使用者的代言人
- 5. 穿破 Banana Republic 襯衫
小型產品或許只需要一個程式經理，不過在大一些的產品則可能有好幾個，其中每個人都負責一部分的功能。實用的規則是：一個程式經理搭配四個程式設計師。有個我從 Mike Conte 那裡學到的方法可以解決切分系統功能時遇上的困難：依照使用者的活動來拆解系統。比如說，我們可以把 Twitter 拆解成四種使用者活動：
- 1. 註冊與啟用
- 2. 發文、讀取回應
- 3. 設定帳號
- 4. 找新聞
我初次擔任程式經理是在微軟 Excel 產品中負責「自訂」這個使用者活動，例如撰寫腳本或是巨集指令。我要做的第一件事是去釐清使用者需要什麼，所以我盡可能的多做客戶訪談，直到我發覺客戶給的都是一樣的回饋而覺得無聊為止。為了想知道一年半開發週期能做到哪些事，我花了很多時間跟開發團隊溝通。也用了許多時間詢問 Visual Basic 團隊是否能夠提供編譯器、程式編輯器與對話盒編輯器給 Excel 裡的巨集語言功能。我曾經去過當時正在開發 AppleScript 這個通用巨集語言的蘋果電腦。還有微軟裡的許多與 Excel 產品類似的團隊諸如 Word，Access，Project 與 Mail。大多數時候，這個過程大多是由交談、開會、email 與電話所組成。因為被這樣的生活嚇到了，我是縮在辦公室裡害怕電話鈴聲響起。
接下來則是寫下一份願景聲明：這是種概略的高階文件，說明了諸如 VisualBasic 如何在 Excel 裡運作、一些巨集程式的例子、待開發的主要功能以及這些東西解決了什麼問題等。當其他人對這份文件不再有太多異議時，我便開始製作更詳細的規格，連最不起眼的細節都做出解釋、使用者看到的每個東西長什麼樣子等。
這是一份功能規格，不是技術文件。意思是這整份文件都在闡述使用者看到什麼，而不是怎麼實作這些功能（這裡可以找到一切關於功能規格的資訊）；程式經理不關心工程師怎麼實作這些東西。接下來當我把一些章節拿給研發主任 Ben Waldman 時，他和他的團隊坐下來討論並說明將會如何實做這些功能。他們最後得出了相當高明又簡潔的表格，把我當時定義的物件導向使用者介面套進 Excel 的內部實作。不過這不是我的工作，我不太瞭解 Excel 內部細節也不知道怎麼實作這些功能。
老實說，我不是萬能的天神。身為一個剛畢業的新鮮人，我沒有太充分的程式、測試、文件、行銷或可用性測試的經驗。幸運的，微軟在前述每個領域都有經驗極豐富的大師級人物；而這些人成就了今天的我，而且真正動手作出產品正是這些人。例如，當使用者在 Excel 裡想把格子裡的數值複製到某個變數裡：
x = [A1]
問題是這格子的內容可能是數值或字串，但是在Basic裡，陣列的資料型態必須在變數被使用之前就完成宣告。
看來要 Basic 可以動態處理型別才行，但是我沒聰明到曉得該怎麼做。沒關係，Visual Basic 的 Tom Corbett 解決了這個問題。因此，Variants 和 IDispatch 問世了，而且 Basic 變成你們這些小朋友現在所說 "duck typing" 程式語言。不過，重點是我的工作並不需要解決這些問題。我的工作是搞清楚客戶需要什麼，並確定工程師知道怎麼解決這些問題。
當規格底定且開發團隊開工之後，我的職責變成：解決開發過程中出現的規格問題、與其他開發團隊溝通以便讓工程師專心工作。我也向測試人員解釋這些功能該怎麼運作並協助他們作測試計畫。我也確認了文件編輯人員真的瞭解怎麼寫出好的 Excel Basic 教學與參考文件。我還跟 localization 專家研究出 localization 策略。也和行銷部門深入解釋 VBA 能對產品銷售帶來什麼好處。還跟軟體可用性專家安排了一些可用性測試。
好的程式經理一定要開很多的會，但是除了文件之外不會產出太多東西。這就是為甚麼一個菜鳥如我都可以接下這份工作的原因。你不會因為沒寫過十四年的程式而當不成程式經理（事實上，十四年的程式經驗可能會使你因為懂得太多而不適合成為使用者的代言人）。
衝突
如果沒有程式經理，那些天才程式設計師會做出讓你五體投地的操作介面，不過前提是：如果你是瓦肯星人的話。我們都知道，最優秀的程式設計師通常無法想像竟然有人記不住十六種命令列參數。這些程式設計師也傾向在寫完程式以後就堅守已經做好的結果。
程式經理為軟體設計過程所能做的最棒的事情是「對於該怎麼設計一個功能提出不同的意見」，希冀能讓人們用同理心來看待使用者：那些令人討厭的傻瓜。他們要求在不閱讀說明書之前就能順利使用軟體、用 lisp 自訂 emacs 函式、或是轉換為八進位的心算。
好的程式經理會提出她覺得使用者介面該怎麼運作的想法，可能比開發人員想到的要好、甚至較差，然後就是冗長的爭論了。通常程式經理的方向是讓使用者容易上手的設計，像是能感知使用者意向的操作介面、一個能塞進口袋的三十吋螢幕。而工程師想做的則是整合 Python 的文字操作介面（哪裡不好用了？）。
在我的記憶中，Excel 5 專案裡最重要的一次辯論是關於樞紐分析表的顯示。程式設計師想讓樞紐分析表浮在試算表上方的繪圖層，而他的程式經理則堅持要讓分析表顯示試算表中的格子裡。這個爭論真的持續了非常久。終於，程式經理占了上風。不過最後的設計比兩人各自主張的都好上了許多。
讓程式經理和工程師處於相等地位絕對是確保辯論過程相互尊重並持續以理性、事實為基礎的重點。如果工程師歸程式經理管轄，則在爭得昏頭的程式經理很容易就會丟下一句：「好了，討論得夠多了，就照我說的作吧。」，這樣的事情在雙方地位平等時則不會發生。這有點像是法院法裡的：「我們不允許某方律師變成法官，所以我們致力於『當雙方地位平等之時的辯論最能夠揭發真相』的理論」。一場辯論只有在沒有一方具有不公平優勢的狀況下才可能公平。
這一點很重要，如果你剛作了想知道就讀十一年級時的莎莉現在在哪的白日夢，醒醒吧。她現在是個住在 Scottsdale 的生物學家兼共和黨員。注意了：程式設計師不能是程式經理的下屬。此外，開發主任，技術長或是執行長都不該是決定規格的人。
大部分公司最大的錯誤是讓程式設計師的經理來寫規格與設計產品。為甚麼這是個錯誤呢？因為這樣的設計過程裡沒有公平的審視，也沒有經過衝突與辯論，所以結果不會像它該有的那麼好。
我之前是那樣一路跌跌撞撞走過來的。而我自己在 Fog Creek 公司也作很多程式管理的工作，我必須不斷地提醒同事必須在我說錯事情的時候跟我爭論。Fog Creek 不是個大公司，但是現在也大到需要有程式經理了，他們是 Dan 與 Jason，程式設計師很愛跟他們辯論。
當然，當程式設計師跟程式經理處於平等狀況下，常常是程式設計師佔上風。曾經有好幾次，程式設計師要我干預他們跟程式經理之間的辯論：
「這個程式是誰要實做的？」，我問道
「我…」
「好吧，然後是誰把程式碼commit進版本管理呢？」
「我猜，是我吧…」
「那到底有什麼問題？」，我問道：「產品任何一個 bit 的長相你都有絕對的控制權，你還需要什麼？讓你當教宗嗎？」
明白了吧，這個系統把壓力擺到程式經理身上，讓他們設法去說服工程師。因為一個絕望的程式設計師可能會憑自己的感覺做事，這樣的結果對程式經理是有風險的。因此，要成為有效率的程式經理，你必須要 1)正確，2)贏得工程師的尊敬，然後他們才會認同你的看法。
怎麼得到工程師的尊敬？
無論對方有多聰明，程式設計師通常更尊重會寫程式的人。所以有個方法是：程式經理本身很能寫程式。但是這並不公平，因為程式經理並不被期待是個程式設計師。所以能幹的程式經理可以不會寫程式，但是這樣要贏得程式設計師的尊重會難上一些。
另一種讓程式設計師尊敬你的方法是展現你的智慧、開放的心胸與公平處理每次的爭論。當程式經理講了傻話，程式設計師就會把他標示成「傻瓜」。如果程式經理一意孤行，作了不合理的事情，就會失去他人的信任。程式經理特別需要在爭論中屏除個人情緒，並樂於將證據納入考量，根據事實改變看法。最後，如果程式經理為了贏得爭論而去搞政治手段，例如私底下找老闆、搞各個擊破等，則他們終將失去程式設計師的信任。
程式經理若失去程式設計師的信任，那一切就完了。這團隊將不再是有效率的團隊。程式設計師開始不把程式經理當一回事，並且搞他們自己想要的東西。結果就是浪費時間又產出一堆爛程式碼而已。這時候你除了支付薪水給這個沒用的程式經理之外，這個人還會把大家拉去開會並耗光大家的時間，但是結果終究不會變得更好。
規格？這樣實在很不Agile
「不寫文件」的想法正在許多撰寫規格書形同具文的研發單位裡如雨後春筍般的冒出來。其實，這些人都被誤導了。撰寫功能規格是敏捷軟體開發的核心之一，因為它讓我們在動手寫程式之前有機會迅速的審視多種設計的可行性。跟修改寫好的程式比起來，修改一份文件實在是容易多了。認真撰寫規格文件強迫我們仔細去思考自己腦袋裡的設計並迅速發現其中的問題，所以我們可以嘗試更多的設計。採用功能性規格設計的團隊能產出設計較好的軟體，因為他們有機會發掘更多可行的方案。而這樣子寫起程式來也快了許多，因為工程師在開始寫程式的時候已經很清楚接下來需要做什麼。「沒規格就不寫程式」是 Fog Creek 公司的一個不能妥協的原則。
功能規格書並沒有一定的形式。所有規格必須做的是去解釋程式的行為而非程式如何運作之類的事情。我們從最高階的「願景描述」開始，使用少於一頁的篇幅來描述這個新功能的重點。願景確定之後就開始作分鏡，也就是仿製使用過程的畫面原型，並詳細標示這些東西如何運作。對於許多功能，尤其是與使用者操作介面高度相關的功能，這些分鏡完成就大致代表工作完成了，這就是你的規格。Jason Fried，滾吧。
你必須為分鏡裡沒有提到的複雜功能所伴隨的隱藏行為寫下更多的細節。無論如何，寫文件能讓你在開始寫程式之前就發現問題、衝突與設計上的缺陷。所以當你真正開始寫程式的時候，遭遇未曾思考過的問題而導致程式重寫的機會就比較低了；更慘的則是，較差的設計。
怎麼學習當個程式經理？
大多時候，作為程式經理是一種學習：學習技術、了解人性、搞懂怎麼在組織政治裡有效率的做事。好的程式經理能把工程師的想法整合到設計裡，並像政治家一樣把人聚在一起並建立共識。當你在做這些事情的時候，可以讀一讀這些書：
就我所知，Scott Berkun 的「Making Things Happen」是唯一一本內容涵蓋了程式經理所要做的事情的書。所以從這一本開始吧。Scott 曾經在 Internet Explorer 團隊擔任多年的程式經理。
程式經理的一大部分工作是設計使用者操作介面。首先可以讀 Steve Krug 的「Don’t Make Me Think」，然後是我寫的「User Interface Design for Programmers」。
最後，我知道這聽起來很俗氣，不過 Dale Carnegie 在 1937 年寫的「How to Win Friends & Influence People」真的是的超棒的人際關係入門書。這是我所指定的在 Fog Creek 裡受訓的經理人要閱讀的第一本書。這些人一開始總是在私底下竊笑，不過大家在讀完之後都會愛上這本書。
