Charles Simonyi，這位曾與Martha Stewart（譯者注：美國女富豪，作家）拍拖15 年、WYSIWYG字處理技術(shù)發(fā)明人之一、從微軟股票賺得10 億美元（譯者注：Charles Simonyi 曾是微軟Office產(chǎn)品團隊的負(fù)責(zé)人）、到過太空的天才程序員，是試圖解決大型軟件團隊遇到的“人月神話”問題之第一人。他的方法是創(chuàng)立一個新的崗位，由超級天才程序員擔(dān)任，負(fù)責(zé)系統(tǒng)中最重要功能的實現(xiàn)，而其他次要部分則交給一個由低級程序員組成的雜牌團隊。他把這個崗位命名為程序經(jīng)理（program manager）。雖然Simonyi 本人是天才級的，但他的這個想法卻不怎么出彩，我想沒人愿意做一個被人輕視的低級程序員吧。

若需詳細(xì)了解這段歷史， 可以閱讀William Poundstone的《How Would You Move Mount Fuji?》

Jabe Blumenthal，是20世紀(jì)80年代后期在Mac Excel團隊工作過的一名程序員。他撿起了這個頭銜，卻賦予了不同的含義。Blumenthal 發(fā)現(xiàn)軟件開發(fā)已經(jīng)變得日益復(fù)雜，以致沒有哪個程序員有時間去關(guān)心如何真正保證軟件的可用性和實用性。而市場人員又在一旁大談客戶需求，抱怨沒人聽他們的 話，沒人將他們MBA式的天才想法轉(zhuǎn)化為軟件中可用的功能。產(chǎn)品設(shè)計方面不少的工作都需要花費大量時間，比如用戶溝通、可用性測試、競爭對手產(chǎn)品的分析評 估、將復(fù)雜問題化繁為簡等等。但絕大多數(shù)程序員恰恰沒有時間做這些事情（實際上這些往往也不是他們的強項）。于是，Blumenthal 重拾“程序經(jīng)理”，不過完全重新定義了這個職位。

程序經(jīng)理需要做什么工作？

自此以后，一名程序經(jīng)理的工作包括：

• UI 設(shè)計
• 編寫功能規(guī)格
• 團隊協(xié)調(diào)
• 充當(dāng)用戶代言人

還有，穿Banana Republic 牌子的休閑Chino褲

在 小項目中，你有一個程序經(jīng)理就夠了，但對于大型項目，就可能需要配置多位了，每個人負(fù)責(zé)全部功能特性的一個子集。從眾多項目中總結(jié)出來了一個經(jīng)驗法則：每 四名程序員配置一個程序經(jīng)理。那么如何劃分功能集呢，如果你遇到困難，我向你推薦我從Mike Conte那學(xué)到的方法：根據(jù)用戶活動劃分產(chǎn)品功能（http://www.joelonsoftware.com/uibook/chapters /fog0000000065.html）。比如：twitter.com可劃分為四類用戶活動：

• 注冊與登錄
• 發(fā)表帖子、閱讀回復(fù)
• 配置個人賬戶
• 搜索新聞

我的第一份程序經(jīng)理工作是在微軟的Excel團隊，負(fù)責(zé)一個叫做用戶化的用戶活動（比如編寫腳本、宏）。首先要做的事情是搞清楚用戶的需求。于是我與很多用戶交流，直到我長滿繭子的耳朵只能聽到相同的需求、讓人厭煩為止。接下來，需要花很多時間與開發(fā)團隊溝通，弄清在18個月的新版本開發(fā)周期中，些需求是合理的、可以實現(xiàn)的。并和Visual Basic 團隊溝通，確定他們是否可提供編譯器、代碼編輯器、對話框編輯器，否則用戶就不能在Excel中使用宏語言。同時還必須跑去與Apple溝通，他們當(dāng)時正在自己搞一門叫做AppleScript的通用宏語言。此外，我還要和微軟內(nèi)部的其他應(yīng)用團隊，主要包括Word、Access、Project和Mail等打交道，因為他們也在做和Excel團隊差不多的事情。這個過程的絕大部分工作，都是溝通討論——會議、郵件、電話……幾乎無休無止。我被那段生活搞怕了，直到現(xiàn)在，在辦公室的時候還怕聽到 電話鈴響。

第二步是寫愿景規(guī)劃。這是一個內(nèi)容相當(dāng)寬泛的文檔，比如Visual Basic如何在Excel中工作，用戶可能編寫的宏是什么樣子，需要技術(shù)團隊構(gòu)建哪些模塊，以及它們?nèi)绾谓鉀Q用戶的問題。然后在此基礎(chǔ)上討論修改，直到 沒有太多分歧。至此，便可以開始編寫詳細(xì)規(guī)格書，要描述清楚每個不可再分的細(xì)節(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)細(xì)節(jié)。當(dāng)我將這份功能規(guī)格發(fā)給開發(fā)團隊的頭頭Ben Waldman后，他和他的團隊再坐下來詳細(xì)討論實現(xiàn)工作。最后，他們很聰明地弄出一份精悍的表格，將我定義的面向?qū)ο蟮慕涌谝灰挥成涞?code style="box-sizing: border-box;font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;font-size: 14px;word-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(239, 112, 96);background-color: rgba(27, 31, 35, 0.0470588);word-break: break-all;">Excel內(nèi)部功能。當(dāng)然這不是我的事情，我對Excel內(nèi)部知之甚少，并不知道那些需求應(yīng)該怎么實現(xiàn)。

老實說，我那時候?qū)κ裁炊际且桓[不通。剛從學(xué)校出 來，對代碼開發(fā)、程序測試、文檔撰寫、產(chǎn)品推廣以及可用性測試等，完全沒有經(jīng)驗。幸運的是，微軟在每個崗位都有經(jīng)驗豐富的導(dǎo)師，他們教給了我迄今知道的全 部知識，也是他們真正承擔(dān)了這么大的產(chǎn)品的全部實際工作。舉個我知道的例子說吧，用戶在宏程序里將電子表格中單元格的值復(fù)制給一個變量：

  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由此誕生了，借助鴨式類型識別（duck typing?！叭绻恢圾B，走起來像鴨子，叫起來像鴨子，那我們就可以管它叫鴨子?！保?，于是Basic 搖身一變，成了動態(tài)語言。這個事情說明，我的工作不是自己去解決問題，而是找到用戶需要解決的問題，并保證程序員找出解決這些問題的辦法。

一旦功能規(guī)格完成、技術(shù)團隊開始工作后，我的職責(zé)就有了變化：（1）解決設(shè)計方面出現(xiàn)的問題；（2）負(fù)責(zé)與所有其他團隊的溝通，以便節(jié)省開發(fā)人員的時間。例如，我要向測試人員說明全部功能是如何運轉(zhuǎn)的，并幫助他們設(shè)計測試計劃；確保文檔團隊明白如何為Excel Basic 編寫一份高質(zhì)量的教程和參考手冊；和本地化專家確定本地化策略；向市場人員解釋VBA在市場上的優(yōu)勢；和可用性專家設(shè)計可用性測試方案等。

程序經(jīng)理需參加大量的會議，但其產(chǎn)出基本不超出規(guī)格文檔這個范圍，因此我一個剛畢業(yè)的無用之人也能勝任這份工作。完全沒必要讓一個有14年經(jīng)驗的資深程序員擔(dān)當(dāng)程序經(jīng)理。實際上，有14年的開發(fā)經(jīng)驗，你反而可能因為知道太多，而無法扮演好用戶代言人這個角色。

沖突

如果沒有程序經(jīng)理，聰明的程序員們在一起，可能設(shè)計出讓用戶難以理解的界面，也許只有Vulcan 人（《Star Trek / 星際迷航》中邏輯思維能力超強的外星種族）才會表示“正合吾意”。最好的程序員會聰明到不能理解用戶為何不能記住16 個單字母的命令行參數(shù)。這些程序員往往難以割舍他們的最初想法，尤其是已經(jīng)將自己的想法變成了代碼之后。

程序經(jīng)理給軟件設(shè)計流程帶來的最大益處，是可以引入程序員之外的第二種觀點。而這種觀點恰恰更接近用戶的想法——這些用戶往往既不想閱讀使用手冊，更不想寫什么emacs-lisp函數(shù)，至于在他們大腦里將十進制數(shù)字轉(zhuǎn)化為八進制，那就更不可能了。

一個好的程序經(jīng)理對于UI 的工作方式有他自己的想法，和開發(fā)人員的相比，可能更好，也可能更壞，因此需要雙方進行討論。通常，程序經(jīng)理是站在用戶角度，希望凡事都盡可能簡單易懂， 諸如有心靈感應(yīng)力的用戶界面、大到30″ 而又能放進口袋的屏幕之類；而開發(fā)人員想的是處處盡可能減少要編寫的代碼，支持命令行界面（他們會說“這怎么就不好用了呢？”）和Python綁定。

我記得Excel 5項目中最為經(jīng)典的爭論發(fā)生在一個開發(fā)人員和程序經(jīng)理之間。開發(fā)人員希望數(shù)據(jù)透視表（pivot table）懸浮在電子表格的繪畫層上，而程序經(jīng)理堅持認(rèn)為數(shù)據(jù)透視表應(yīng)位于單元格的右側(cè)。這個爭論持續(xù)了很長時間，最后由程序經(jīng)理勝出。而最終的設(shè)計比 當(dāng)初任何一方的單獨設(shè)計都好出很多。

為確保這種爭論完全以事實為基礎(chǔ)、在參與方間平等地展開，程序經(jīng)理和開發(fā)人員地位對等是必要的。如果開發(fā)人員 負(fù)責(zé)向程序經(jīng)理匯報，那么在爭論過程的任何時刻，程序經(jīng)理只要略感厭倦，就可以說“好了，討論得夠了，現(xiàn)在就按我說的辦”。但如果他們是對等的，這種事情 就不會發(fā)生。就好比在法庭，我們不能允許任何一方的律師同時是法官。只有建立在這個理論之上，真理才最可能通過對等雙方間的爭論而被發(fā)現(xiàn)。只有任何參與方 都不具有不公平優(yōu)勢時，爭論本身才可能是公平的。

這點很關(guān)鍵，如果你剛才還在夢里探究11年級的Sally 現(xiàn)在在哪兒，趕緊醒醒吧。她在Scottsdale做生物醫(yī)學(xué)家，還入了共和黨。我們必須明白，程序員不能是程序經(jīng)理的下屬，換句話說，開發(fā)團隊的頭頭、CTO或CEO，都不應(yīng)是負(fù)責(zé)撰寫規(guī)格書的人。

大多數(shù)公司犯的頭號錯誤，就是讓程序員的上級編寫規(guī)格書、設(shè)計產(chǎn)品。這樣出來的設(shè)計，不能得到真正平等的審查，不能引出沖突與爭議，自然就不會好到哪里去。

要我真正弄懂這個道理，其實并不容易。在Fog Creek 軟件公司，我自己曾承擔(dān)了該程序經(jīng)理做的大量工作，為此我費勁口水，時刻提醒在我說錯的時候，程序員要指出、爭辯。我們不是大公司，但也已經(jīng)到了需要真正 的程序經(jīng)理的時候了——Dan和Jason，程序員喜歡和他們吵。

當(dāng)然，程序員和程序經(jīng)理地位對等的時候，程序員會略占優(yōu)勢。這樣的事曾發(fā)生過幾次：程序員讓我介入他和程序經(jīng)理間發(fā)生的爭議。

“誰寫代碼？”我問。

“是我……”

“那好，誰負(fù)責(zé)將程序簽入版本控制庫呢？”

“我想還是我……”

“既然這樣，那你還有什么問題呢？”我問，“你對最終產(chǎn)品的每個比特都有絕對控制權(quán)，你還需要什么呢，一頂皇冠？”

可見，這種體制將擔(dān)子壓在了程序經(jīng)理肩上，要求程序經(jīng)理能說服程序員，因為在某些時候，程序經(jīng)理會面臨程序員不理會爭議而直接按自己想法行事的風(fēng)險。因此，要成為一名優(yōu)秀、有影響力的程序經(jīng)理，要求你：（1）正確；（2）贏得程序員的尊重，唯此他們才可能承認(rèn)你的正確。

往期精彩

談?wù)勛霎a(chǎn)品、做項目以及標(biāo)準(zhǔn)化相關(guān)的話題

推薦一個非常好的項目管理工具

十種能力指引IT人才走向成功

若覺得本次分享的文章對您有幫助，隨手點[在看]并轉(zhuǎn)發(fā)分享，也是對我的支持。