文/Joel Spolsky 譯/羅小平
指派一名優(yōu)秀的程序經(jīng)理，是團隊產(chǎn)出優(yōu)秀軟件的重要前提之一。你的團隊里可能沒有這樣的人，其實絕大多數(shù)團隊都沒有。
Charles Simonyi，這位曾與MarthaStewart（譯者注：美國女富豪，作家）拍拖15年、WYSIWYG字處理技術(shù)發(fā)明人之一、從微軟股票賺得10億美元（譯者注：CharlesSimonyi曾是微軟Office產(chǎn)品團隊的負責人）、到過太空的天才程序員，是試圖解決大型軟件團隊遇到的“人月神話”問題之第一人。他的方法是創(chuàng)立一個新的崗位，由超級天才程序員擔任，負責系統(tǒng)中最重要功能的實現(xiàn)，而其他次要部分則交給一個由低級程序員組成的雜牌團隊。他把這個崗位命名為程序經(jīng)理（program manager）。Simonyi本人是天才級的，但他的這個想法可不怎么出彩，我想沒人愿意做一個被人輕視的低級程序員吧。
若需詳細了解這段歷史，可以閱讀William Poundstone的《How Would You Move Mount Fuji?》（http://www.amazon.com/gp/product/0316778494?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=9325&creativeASIN=0316778494）。
Jabe Blumenthal，是上世紀80年代后期在MacExcel團隊工作過的一名程序員。他撿起了這個頭銜，但賦予了不同的含義。Blumenthal發(fā)現(xiàn)軟件開發(fā)已經(jīng)變得日益復雜，以至沒有哪個程序員有時間去關(guān)心如何真正保證軟件的可用性和實用性。而市場人員又在一旁大談客戶需求，抱怨沒人聽他們的話，沒人將他們MBA式的天才想法轉(zhuǎn)化為軟件中可用的功能。產(chǎn)品設計方面不少的工作都需要花費大量時間，比如用戶溝通、可用性測試、競爭對手產(chǎn)品的分析評估、將復雜問題化繁為簡等等。但絕大多數(shù)程序員恰恰沒有時間做這些事情（實際上也往往也不是他們的強項）。于是，Blumenthal重拾“程序經(jīng)理”，不過完全重新定義了這個職位。
程序經(jīng)理需要做什么工作？
自此以后，一名程序經(jīng)理的工作包括：
UI設計
編寫功能規(guī)格
團隊協(xié)調(diào)
充當用戶代言人
還有，穿Banana Republic牌子的休閑Chino褲
在小項目中，你有一個程序經(jīng)理就夠了，但對于大型項目，很可能需配置多名，每個人負責全部功能特性的一個子集。從很多項目總結(jié)出來了一個經(jīng)驗法則：每四名程序員配置一個程序經(jīng)理。那么如何劃分功能集呢，如果你遇到困難，我向你推薦我從Mike Conte那學到的方法：根據(jù)用戶活動劃分產(chǎn)品功能（http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html）。比如：twitter.com可劃分為四類用戶活動：
1. 注冊與登錄
2. 發(fā)表帖子、閱讀回復
3. 配置個人賬戶
4. 搜索新聞
第二步是寫愿景規(guī)劃。這是一個內(nèi)容相當寬泛的文檔，比如VisualBasic如何在Excel中工作，用戶可能編寫的宏是什么樣子，需要技術(shù)團隊構(gòu)建哪些模塊，以及它們?nèi)绾谓鉀Q用戶的問題。然后在此基礎上討論修改，直到?jīng)]有太多分歧。至此，我可以開始編寫詳細規(guī)格書，要描述清楚每個不可再分的細節(jié)呈現(xiàn)在用戶面前時的樣子。
這是一份功能而不是技術(shù)規(guī)格書。也就是說，它的全部內(nèi)容都用于描述用戶所見所為，而不是程序如何實現(xiàn)。若需進一步了解功能規(guī)格，請閱讀http://www.joelonsoftware.com/articles/fog0000000036.html。程序經(jīng)理不關(guān)心開發(fā)團隊的內(nèi)部實現(xiàn)細節(jié)。當我將這份功能規(guī)格發(fā)給開發(fā)團隊的頭頭BenWaldman后，他和他的團隊再坐下來詳細討論實現(xiàn)工作。最后，他們很聰明地弄出一份精悍的表格，將我定義的面向?qū)ο蟮慕涌谝灰挥成涞紼xcel內(nèi)部功能。當然這的確不是我的事情，我對Excel內(nèi)部知之甚少，也真的不知道那些需求應該怎么實現(xiàn)。
老實說，我那時候?qū)κ裁炊际且桓[不通。剛從學校出來，對代碼開發(fā)、程序測試、文檔撰寫、產(chǎn)品推廣以及可用性測試等等，我完全沒有經(jīng)驗。幸運的是，微軟在每個崗位都有經(jīng)驗豐富的導師，他們教給了我迄今知道的全部知識，也是他們真正承擔了這么大的產(chǎn)品的全部實際工作。舉個我知道的例子說吧，用戶可能需要在宏程序里將電子表格中單元格的值復制給一個變量：
x = [A1]
問題是單元格的值可能是數(shù)字，也可能是字符串；而Basic語言是早期綁定的，你必須首先用DIM將x定義為Integer、Float或String等確定類型，然后才能使用。
要解決這個問題，Basic必須支持某種動態(tài)類型，但我沒那么聰明，想不出什么解決辦法。不要緊，Visual Basic團隊的程序員Tom Corbett想出來了（http://www.patentstorm.us/patents/5689709/description.html）。Variants和IDispatch由此誕生了，借助“鴨式類型識別”（ducktyping?！叭绻恢圾B，走起來像鴨子，叫起來像鴨子，那我們就可以管它叫鴨子。”），Basic搖身一變，成了動態(tài)語言。這個事情說明，我的工作不是自己去解決問題，而是找到用戶需要解決的問題，并保證程序員找出解決這些問題的辦法。
一旦功能規(guī)格完成、技術(shù)團隊開始工作后，我的職責就有了變化：（1）解決設計方面出現(xiàn)的問題；（2）負責與所有其他團隊的溝通，以便節(jié)省開發(fā)人員的時間。例如，我要向測試人員說明全部功能是如何運轉(zhuǎn)的，幫助他們設計測試計劃；確保文檔團隊明白如何為ExcelBasic編寫一份高質(zhì)量的教程和參考手冊；和本地化專家確定本地化策略；向市場人員解釋VBA在市場上的優(yōu)勢；和可用性專家設計可用性測試方案等。
程序經(jīng)理需參加大量的會議，但其產(chǎn)出基本不超出規(guī)格文檔這個范圍，因此我一個剛畢業(yè)的無用之人也能勝任這份工作。完全沒必要讓一個有14年經(jīng)驗的資深程序員擔當程序經(jīng)理。實際上，有14年的開發(fā)經(jīng)驗，你反而可能因為知道太多，而無法扮演好用戶代言人這個角色。
沖突
如果沒有程序經(jīng)理，聰明的程序員們在一起，可能設計出讓用戶難以理解的界面，也許只有Vulcan人（《Star Trek /星際迷航》中邏輯思維能力超強的外星種族）才會表示“正合吾意”。最好的程序員會聰明到不能理解用戶為何不能記住16個單字母的命令行參數(shù)。這些程序員往往難以割舍他們的最初想法，尤其是已經(jīng)將自己的想法變成了代碼之后。
程序經(jīng)理給軟件設計流程帶來的最大益處，是可以引入程序員之外的第二種觀點。而這種觀點恰恰更接近用戶的想法——這些用戶往往既不想閱讀使用手冊，更不想寫什么emacs-lisp函數(shù)，至于在他們大腦里將十進制數(shù)字轉(zhuǎn)化為八進制，那就更不可能了。
一個好的程序經(jīng)理對于UI的工作方式有他自己的想法，和開發(fā)人員的相比，可能更好，也可能更壞，因此需要雙方討論。通常，程序經(jīng)理是站在用戶角度，希望凡事盡可能簡單易懂，諸如有心靈感應力的用戶界面、大到30″而又能放進口袋的屏幕之類；而開發(fā)人員想的是處處盡可能減少要編寫的代碼，支持命令行界面（他們會說“這怎么就不好用了呢？”）和Python綁定。
我記得Excel 5項目中最為經(jīng)典的爭論發(fā)生在一個開發(fā)人員和程序經(jīng)理之間。開發(fā)人員希望數(shù)據(jù)透視表（pivottable）懸浮在電子表格的繪畫層上，而程序經(jīng)理堅持認為數(shù)據(jù)透視表應位于單元格的右側(cè)。這個爭論持續(xù)了很長很長時間，最后程序經(jīng)理勝出。但最終的設計比當初任何一方的單獨設計都好出很多。
為確保這種爭論完全以事實為基礎、在參與方間平等地展開，程序經(jīng)理和開發(fā)人員地位對等是絕對必要的。如果開發(fā)人員負責向程序經(jīng)理匯報，那么在爭論過程的任何時刻，程序經(jīng)理只要略感厭倦，就可以說“好了，討論得夠了，現(xiàn)在就按我說的辦”。如果他們是對等的，這種事情就不會發(fā)生。就好比在法庭，我們不能允許任何一方的律師同時是法官。只有建立在這個理論之上，真理才最可能通過對等雙方間的爭論而被發(fā)現(xiàn)。只有任何參與方都不具有不公平優(yōu)勢時，爭論本身才可能是公平的。
這點很關(guān)鍵，如果你剛才還在夢里探究11年級的Sally現(xiàn)在哪兒，趕緊醒醒吧。她在Scottsdale做生物醫(yī)學家，還入了共和黨。我們必須明白，程序員不能是程序經(jīng)理的下屬，換句話說，開發(fā)團隊的頭頭、CTO或CEO，都不應是負責撰寫規(guī)格書的人。
大多數(shù)公司犯的頭號錯誤，就是讓程序員的上級編寫規(guī)格書、設計產(chǎn)品。這樣出來的設計，不能得到真正平等的審查，不能引出沖突與爭議，自然就不會好到哪里去。
我真正弄懂這個道理，并不容易。在Fog Creek軟件公司，我自己曾承擔了該程序經(jīng)理做的大量工作，為此我費勁口水，時刻提醒在我說錯的時候，程序員要指出、爭辯。我們不是大公司，但也已經(jīng)到了需要真正的程序經(jīng)理的時候了——Dan和Jason，程序員喜歡和他們吵。
當然，程序員和程序經(jīng)理地位對等的時候，程序員會略占優(yōu)勢。這樣的事曾發(fā)生過幾次：程序員讓我介入他和程序經(jīng)理間發(fā)生的爭議。
可見，這種體制將擔子壓在了程序經(jīng)理肩上，要求程序經(jīng)理能說服程序員，因為在某些時候，程序經(jīng)理會面臨程序員不理會爭議而直接按自己想法行事的風險。因此，要成為一名優(yōu)秀、有影響力的程序經(jīng)理，要求你：（1）正確；（2）贏得程序員的尊重，唯此他們才可能承認你的正確。
如何贏得這種尊重？
若已是編程高手，當然對你擔任程序經(jīng)理很有幫助。但這個要求并不公平。我也不建議程序經(jīng)理去寫代碼。不過，程序員通常首先尊重的是同是程序員的人，而不是非程序員，無論他們多聰明。不會寫程序而要成為一個受人尊重的程序經(jīng)理是可能的，但往往要付出更多努力才行。
贏得開發(fā)人員尊重的另一個方法，是能在出現(xiàn)爭議的時候充分展示你的才華、開明和正直。如果程序經(jīng)理凈說傻話辦蠢事，程序員就會在心里給他們打上笨蛋標記。程序經(jīng)理武斷、情緒化地固執(zhí)己見，不可理喻，也會大丟信譽分。所以雙方，特別是程序經(jīng)理，一定要避免在爭論中帶入個人情緒，事實已證明自己犯錯時，要樂于、勇于改變老觀點，考慮新問題。最后要說的一點是，如果程序經(jīng)理被發(fā)現(xiàn)玩弄權(quán)術(shù)、向老板打小報告，或試圖依靠分而治之的陰謀手段而不是事實在分歧中勝出，都會在程序員那里大失信任。
一個失去了程序開發(fā)團隊信任的程序經(jīng)理，將寸步難行。程序員會無視程序經(jīng)理的存在，直接按照自己意愿行事。其結(jié)果是出現(xiàn)大量錯誤、浪費大量時間，你不但要付給低效率的程序經(jīng)理薪水，他們還要召集會議、占用其他很多人的時間，而程序質(zhì)量又沒有因此得到提高。
規(guī)格化是否是不敏捷的代名詞？
當然，功能規(guī)格書的具體格式，可依情況而定。但其必須遵守一條原則：它是用來說明程序在用戶面前如何運行的。它無需解釋程序內(nèi)部代碼如何工作。具體來說，你應首先從頂層開始：愿景描述（visionstatement），用不超過一頁紙的篇幅，說明新特性、新功能的要點。這步工作完成，就可以開發(fā)情景圖（storyboard）——用戶在應用程序中行進的各種場景圖，并詳細說明每個場景中，程序如何工作。對于很多類型的功能而言，尤其是UI級的功能，一旦你完成了這些情境圖，也就可以描述清楚了。這就是你的功能規(guī)格。Jason Fried，現(xiàn)在該你發(fā)言了（http://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.php）。
若要學習如何編寫高質(zhì)量功能規(guī)格書，可閱讀我的文章《功能規(guī)格四部曲》（http://www.joelonsoftware.com/articles/fog0000000036.html）。若需要我編寫規(guī)格書范本，可從http://www.joelonsoftware.com/articles/AardvarkSpec.html下載。
在一些復雜的功能中，可能還包含著不在UI展示的隱藏行為，這時候你也應該寫清楚這些細節(jié)。無論如何，編寫規(guī)格書本身就有助于在寫下第一行代碼前發(fā)現(xiàn)問題、沖突和設計漏洞，這樣在你真正寫代碼的時候，可能導致設計混亂、質(zhì)量低下、甚至重新設計這類不可預知問題的出現(xiàn)概率要低很多。
如何學做程序經(jīng)理？
要成為一名合格的程序經(jīng)理，主要就是學習：學習技術(shù)、學習做人、學習如何在組織中產(chǎn)生影響力。一個好的程序經(jīng)理，要同時具備工程師的技術(shù)設計方法、政治家構(gòu)建共識、團結(jié)民眾的能力。這方面可讀的書不多，若你從事這項工作，我還是盡我所知推薦幾本：
Scott Berkun的《Making Things Happen》（http://www.amazon.com/gp/product/0596517718?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596517718），這是唯一一本非常準確說明了程序經(jīng)理必須做哪些事情的書，就從它開始吧。Scott曾長期在Internet Explorer團隊擔任程序經(jīng)理。
Another big part of the program manager’s job is user interfacedesign. Read Steve Krug’s Don’t Make Me Think, then my own book UserInterface Design for Programmers.
程序經(jīng)理的另一大塊工作是用戶界面設計。這方面可閱讀Steve Krug的《Don’t Make Me Think》（http://www.amazon.com/gp/product/0321344758?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321344758）和我自己的《User Interface Design for Programmers》（http://www.amazon.com/gp/product/1893115941?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=1893115941）。
最后，我知道聽起來可能有點老套，但Dale Carnegie在1937年出版的《How to Win Friends & Influence People》（http://www.amazon.com/gp/product/0671027034?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=0671027034）確實是一本講人際交往技巧的好書。它是我要求Fog Creek所有初級管理人員閱讀的第一本書。我每次告訴他們閱讀這本書時，他們都會竊笑；等到讀完，他們都會愛上這本書。
作者簡介：
Joel Spolsky：Fog Creek 軟件公司（http://www.fogcreek.com/）創(chuàng)始人，曾在微軟Excel團隊工作。FogCreek位于紐約，這是一家以實踐證明可以很好對待程序員，而又能獲得不錯利潤的公司。程序員有私人辦公室、免費午餐，每周工作40個小時。用戶滿意后才需為軟件支付費用。公司主要產(chǎn)品包括：FogBugz，幫助大型團隊開發(fā)高水平軟件的項目管理系統(tǒng)；Fog CreekCopilot，讓遠程桌面變得輕而易舉。
聯(lián)系客服
