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