原文地址： http://www.joelonsoftware.com/items/2009/03/09.html
以下爲譯文：
有一個好的項目經理是開發真正偉大的軟件的祕方之一。可能你的團隊現在還沒有好的項目經理，因爲大多數團隊都沒有。
Charles Simonyi，一個傑出的程序員，WYSIWYG文字處理的共同發明者，曾經通過微軟股票賺了上十億美金併到過太空，第一次嘗試解決管理項目團隊的難題時，使用的方法是：由一個資深的程序員來寫上層接口，而將其具體的實現交給一些初級的程序員來完成，他將這個資深程序員稱爲項目經理。Simonyi是傑出的，但是這種項目管理方法值得商榷，我想沒有人願意成爲一個繁瑣的初級程序員。
同樣的例子，請閱讀William Poundstone的《你如何移動富士山》？
Jabe Blumenthal，80年代末MAC Excel開發團隊中一名程序員，現在使用了一個不同的頭銜。他注意到，軟件開發變得如此複雜，以至於程序員都沒有時間去搞清楚如何使軟件可用。營銷團隊抱怨客戶需求以及沒有人有時間和他們交談並將其轉化爲實際的產品功能。有一些產品設計元素，花了很多時間和用戶交談，運行可用性測試用例，檢視競爭性的產品，並思考如何使事情變得更容易，但大多數程序員沒有時間去做。Blumenthal現在的頭銜是項目經理，但是做的是和以前一樣的工作。
那麼項目經理應該做什麼呢？
今後，項目經理應該：
設計用戶界面
寫功能規格
協調團隊
像真正的客戶一樣提供服務
在小的產品開發中，可能只是一個項目經理，但對於較大的產品，可能需要多個項目經理。每個項目經理負責其中的一部分功能。一個好的經驗法則是，每四個程序員需要一個項目經理 。如果你劃分功能的時候遇到困難，有一個方法是根據用戶活動來劃分。例如，Twitter可以分爲4個用戶活動 ：
註冊和入門
發佈信息和閱讀回覆
配置您的帳戶
搜索新聞
我在微軟的第一份項目管理工作是在Excel上實現定製功能，即定製腳本和宏。我第一步要做的事情是瞭解用戶需求，方法是和儘量多的客戶交流直到厭煩，因爲同樣的東西聽了太多遍，而那些就是真正的用戶需求。然後我花了很多時間和開發團隊交流，並指出哪些應該在18個月內實現，同時也花了很多時間和VB團隊交流，看他們是否可以提供一個編譯器，代碼編輯器以及對話框編輯器，可以在Excel中供宏語言使用。除此之外，還要和Apple以及微軟的其他應用團隊交流。大多數的交流工作包含了交談，會議，郵件以及電話交流等方式。
我第二步做的事情是寫一個願景：通過排序來說明，VB是如何工作在Excel中的，一些示例宏看起來是什麼樣，我們需要構建哪些主要部分以及是如何解決客戶問題的。當沒有太多的反對意見時，我就開始編寫詳細的規格，這是功能性的規格，而不是技術規格，也就是說，描述用戶看到的，而不是具體如何去實現。一個項目經理不需要關心具體內部是如何實現的。
說實話，我經驗並不豐富。大學畢業後，我並沒有足夠的經驗來開發代碼，測試代碼，寫文檔，營銷產品或做可用性測試。幸運的是，微軟在這些職位上都有經驗豐富的大師，他們教會了我這一切而且他們在做真正很棒的產品。
例如，我知道，用戶希望電子表格單元格的值複製到一個變量：可以用X = [A1]，但麻煩的是，一個單元可以容納一個數字或字符串，但BASIC語言是早期綁定的... ...也就是說，你在使用x前，必須使用DIM X將其聲明爲一個整數，浮點數或字符串。
BASIC必須要獲取一些動態類型，可我不知道如何處理。不過不要緊，Tom Corbett，VB團隊的程序員，給出瞭解決方法。於是，Variants和IDispatch誕生了，而且Basic也變成了一個動態語言。我的工作不是必須解決問題，而是要弄清楚客戶的需求，並確保程序員想出瞭如何解決這些問題。
一旦規範編寫完成並且開發團隊開始工作，我還有兩個職責：解決任何設計上的問題，同時還要代替開發人員和所有的團隊進行溝通。我要和測試人員解釋應該如何工作，並幫助他們做測試計劃。我會和文檔團隊交流，確保他們瞭解如何寫一個好的用戶手冊。我會和本地化專家一起制定本地化戰略。我還要和營銷團隊解釋VBA的好處並和可用性專家一起建立可用性測試。
項目經理會參加很多會議，但不會有比書面規範更多的產出，這也就是爲什麼作爲一個剛走出學校的我仍然能夠勝任工作。作爲一個項目經理，你不必是一個擁有14年經驗的程序員（事實上，有14年的編程經驗的程序員，你可能知道了太多細節而不適合做一個好的用戶支持者。）
衝突
缺乏一個項目經理，這些聰明的程序員會開發出完全令人費解的用戶界面。最好的程序員都非常聰明，但有時候會遇到一些麻煩，想象
一下當不能記住16個命令行參數時會是什麼場景。這些程序員通常會傾向於他們的第一想法，特別是當他們已經編寫了代碼。
項目經理可以添加到軟件設計過程中最好的事情之一是，提供第二個關於該如何設計的意見，去考慮那些弱智的用戶，他們要求不需要用戶手冊，不需要定製Emacs-Lisp函數或不需要在腦海中轉化八進制就可以使用應用程序。
一個好的項目經理對於UI應該如何工作會有自己的想法，這可能是比開發人員更好或更差的想法，然後需要經過一個長期的討論。通常情況下，項目經理想要一些簡單，易於用戶理解的界面，而開發者想要的是實現的簡單，提供命令行界面或Python綁定。
在Excel 5開發中，我記得的最具歷史意義的爭論是關於一個開發人員和項目經理之間的。這個開發人員想要數據透視表浮在電子表格之上的繪圖層，而項目經理堅持數據透視表應該在電子表格中。這次爭論持續了很長的一段時間，最後，項目經理贏了，而且最終的設計遠比一個單獨的設計要好。
爲了確保爭論發生在一個合理的事實基礎上，關鍵的一點是項目經理和開發人員需要結對。如果開發人員報告給項目經理，在某些時候，在爭論的某些點上，項目經理有意見時但只是說，“OK，討論很充分了，現在可以各自行動了。”當他們在結對的工作時，這種情況可能不會發生。這有點像法院：我們不容許任何一方的律師是法官，而且真相最有可能通過公平的辯論而發現。這一點非常重要，開發人員不需要向項目經理報告，除其他事項外，意味着，項目領導者，CTO或CEO都不應該是寫規格的人。
大多數公司的一個錯誤是由項目經理來寫規格和設計文檔。這是錯誤的，因爲設計沒有得到公平評審，不是從爭論中得來的，所以並沒有想象中那麼好。
我很艱難才瞭解到這些。在Fog Creek軟件公司，我做了很多項目管理工作，這是一個持續的工作，需要不斷的提醒開發人員，當我說錯了的時候要和我爭論。這不是一家大公司，但因爲有了真正的項目經理最後也變得足夠強大，而且程序員喜歡和他們爭論。
當然，當程序員和項目經理結對時，程序員往往佔據上風。這樣的事情發生了好幾次：程序員問我關於他和項目經理的一些爭論。
“誰去寫代碼呢？”我問。
“我... ...”
“好，誰去合代碼呢？”
“我想還是我... ...”
我問：“那麼，到底問題是什麼呢？”。“你已經擁有了到最終產品的絕對控制權。你還要求什麼呢？“
你看，事實證明，項目經理的負擔更大，他需要去說服程序員，因爲在某些時候，項目經理會冒些風險，程序員可能會放棄或者自己做自己的而不管項目經理怎麼想。因此，要成爲高效的項目經理，意味着你有（A）是正確的，和（b）獲得程序員的尊重，使他們承認你說得對。
那麼如何獲得程序員的尊重呢？
作爲項目經理，自己編碼是能幫助自己贏得尊重的。這是不公平的，項目經理不應該寫代碼。但是，相對於非程序員來說，程序員往往要更尊重程序員一些，而不管那些非程序員有多麼聰明。非程序員也可以作爲一個高效的程序員，但是要贏得程序員的尊重需要付出更多的努力。
贏得尊重的另外一種方式是在爭論中證明自己的才智，開放的胸襟以及公平的態度。如果一個項目經理做了愚蠢的事，程序員可能認爲項目經理是個笨蛋。如果項目經理在做事的過程中摻雜了太多的感情的因素，將會被認爲不可靠。最後，如果項目經理玩弄政治，通過與老闆的私人會議或者試圖分而治之而去贏得一場爭論，那麼他們會失去程序員的信任。
而當一個項目經理失去開發團隊的信任，就意味着遊戲結束。程序員們將不再高效，而且按照自己的想法去做。這樣會導致更糟糕的代碼和時間的浪費，因爲除了要付給無效的項目經理薪水外，這些項目經理還會浪費開發人員的時間。
規格文檔？這是不靈活的，真的是這樣嗎？
在很多開發團隊中，規範是形式化的產物，整個團隊會瀰漫着不寫規範的想法。這些人是錯誤的，寫功能規格是敏捷開發的核心，因爲它可以讓你在編碼前在可能的設計上進行快速迭代。相較於代碼，書面的規範是很少會改變的。寫規範的過程會使你思考整個設計過程，而且會幫助你找到設計中的缺陷並嘗試其他解決方案。使用功能規格的團隊，其產品會設計的更好，因爲他們有機會快速探索更多可能的解決方案。同時，他們編碼會更快，因爲他們有一個清晰的架構。功能規格是如此重要，在Fog Creek的硬性規則之一就是“沒有規格就沒有代碼。”
功能規格所需要的確切形式可能會有所不同。功能規格所要做的是描述程序應該如何運行，而不是說代碼在內部應該如何工作。你開始寫規格時工作在最高層，用不超過1頁紙來描述特性的要點，一旦明確了，就可以開發故事板(story boards)-在屏幕上顯示進展以及詳細解釋它們是如何工作的。對於許多類型的功能，尤其是沉重的UI功能，一旦你有這些故事板，你就大功告成了，這就是你的規格。
要學習如何編寫良好的功能規格，請閱讀我寫的由四個部分組成的系列文章。如果你想看到我寫的一個典型規格，你可以下載完整的Fog Creek Copilot規範。
對於更復雜的功能，其中一些故事板有隱藏的行爲而且並不表示UI中，這種情況你需要寫下更多的細節。在任何情況下，寫功能規格會幫助你發現衝突和設計問題，所以當你寫代碼時，就只會遇到很少的非預期的問題，而這些問題可能會導致重寫，或者更糟糕的是，一個不理想的設計。
你需要學習什麼來成爲一個項目經理呢？
大多數情況下，成爲一個項目經理需要：學習技術，學習與程序員交流，並學習如何在一個組織中高效工作。一個好的項目經理結合了工程師的設計能力以及政治家的能力，同時還需要將人們團結在一起。如果你正在學習做好項目經理，這裏推薦幾本書可以閱讀：
我可以告訴大家的是，Scott Berkun的書《Making Things Happen》是唯一一本幾乎涵蓋所有一個項目經理應該做的事情，所以從這本書開始吧。Scott是一個多年的IE團隊的項目經理。
項目經理的工作的另一個重要組成部分，是用戶界面設計。可以閱讀Steve Krug的《Don't Make Me Think》以及我自己的書《User Interface Design for Programmers》。
最後，我知道這聽起來很俗氣，但Dale Carnegie在1937年的《How to Win Friends & Influence People》是一個夢幻般的教你如何提升人際關係的書。在Fog Creek，這是我讓所有學員在做任何事之前閱讀的第一本書，當我告訴他們去讀時，他們總是竊笑，但是當他們讀完後就都喜歡上這本書了。