我個人認爲，這是一篇不錯的文章，雖然我不是Program Mananger，但是我幾乎在做着和這個職位很相似的工作。在這裏，我把這篇文章推薦給所有的程序員，我相信，這篇文章會讓你明白，只有技術是遠遠不夠的，因爲沒有Program Manager這個角色，程序員們只不過一些手中拿着利器卻不知所措的散兵遊勇。我希望我的導讀和原文能給所有的程序帶來啓示。(本文同步發佈於：酷殼 cocre.com)
原文在這裏：
“How to be a program manager”
[url]http://www.joelonsoftware.com/items/2009/03/09.html[/url]
“How to be a program manager”
[url]http://www.joelonsoftware.com/items/2009/03/09.html[/url]
這篇文章的作者叫Joel Spolsky，在Microsoft做過Program Manager，這篇文章非常值得一讀。下面是我給大家做的一個導讀：
首先，他講了兩個人，一個是負責WYSIWYG 字處理的天才級的Program Manager——Charles Simonyi，第二個是上世紀80年代的負責Mac OS上的Excel項目的程序員Jabe Blumenthal，他發現了程序員和市場人員的代溝，Marketing的人很難通過把MBA-Speaking翻譯成實際的Feature，並且，有太多的和編碼不相關的工作，比如說，和用戶交談，運行usability測試，Reivew競爭者的產品，並且得冥思苦想怎麼能讓事情變得更簡單，而我們的程序員通常來說即不具備這樣的時間，也不具備這樣的能力。於是，Jabe開始了他的Program Manager的生涯。
工作範圍
作者在第二節裏說了一個PM主要負責哪些事務：
- Design UIs （用戶界面的設計）
- Write functional specs （書寫功能規格說明書）
- Coordinate teams （團隊協調）
- Serve as the customer advocate, and （從用戶角度思考問題）
- Wear Banana Republic chinos （Banana Republic是一個服裝品牌，意思是作者在調侃PM需要衣冠楚楚，而不像程序員們只有T恤或牛仔褲）
接下來，作者講述了他第一份Program Manager工作的經歷，非常有意思，那是一個關於Excel 用戶定製化的項目（陳皓注：應該是在Excel中加入VBScript的項目吧，就是所謂的宏）。
第一個階段
- 首先，作者找了很多很多的用戶談論了這個什麼是最有用最合理的實現，這是一個非常巨大的工作，花費了非常多的精力和時間。
- 然後，作者找到了Visual Basic團隊詢問了是否可能給Excel提供一個編譯器和代碼編輯器，以便實現“宏”。
- 接着，作者查看了一下Apple上面的AppleScript這種宏，取了取經。
- 最後，作者同 Word, Access, Project, 和Mail團隊們討論了很多很多。
作者說，這個階段的工作讓他滿是傷痕，他甚至害怕聽到手機鈴響。
第二個階段
- 確定大方向。他開始寫下Visual Baisc應該怎麼樣在Excel裏面工作的文檔。並提供了一些簡單的宏的樣子，這應該是high-level的Functional Spec。
- 當大的方向確定後，他開始了一些更爲細節的功能規格說明的書寫。這就是所謂的Functional Specification. (陳皓注：FS這份文檔應該只是說明從用戶的角度上來看這個產品長成什麼樣，而不是實現)
- 雖然FS並不需要說明怎麼去實現，但這份文檔應該是需要非常詳細地說明整個Excel和VBScript怎麼相互交互的，這是其中最重要的部分。
- 當作者把FS的一個初始化版本發給開發團隊（Ben Waldman）時，開發團隊非常快地實現出了一個原型，並提供了面向對象的相關接口。但可惜的是，那並不是Program Manger所想要的。
- 作者描述了一個細節如果幫助開發團隊解決技術難點的例子。那是關於把一個Excel中的一個cell的值取出來的例子。當時，developer團隊認爲這是一個難點，因爲這個值可能是任意類型的。而VB中卻需要先聲明變量的類型。後來，作者找到了VB的開發團隊，瞭解到了Variants 和IDispatch可以做到這個。
我們可以看到，FS在這樣反覆地和developer 團隊推敲，甚至去幫助程序員解決技術難題，之後最終才能確定下來。一旦FS確定後，program manger需要做兩件事：
- 負責解釋相關的問題。
- 組織並形成相關的design。
也就是說，除了對FS解釋外，需還需要把What needs to do 變成 How to do的設計文檔。另外，Program Manager可能會有下面的工作：
- 測試人員會對FS有很多很多疑問，因爲他們需要知道怎麼樣去測試這些FS中所包含的東西。
- 和文檔團隊商討如何寫一個好的教程或是一個參考文檔。
- 和localization 團隊制定localization 的策略。
- 和市場人員說明VBA的優勢和功能。
我們可以看到，作者有太多，太多的會議和太多的與人溝通的事務，真是一個不簡單的工作啊。
衝突管理
後面，作者着重講了“Conflicts”衝突，這可能是所有的團隊都會有的問題。而我們的Program Manager因爲要和那麼多的人溝通交流，所以，必然會需要有一種超人的能力去管理與人的發生的觀點上的衝突。作者，在這裏說了和程序員發生的很多爭論，因爲Program Manager是從用戶的角度出發，而我們程序員總是從技術和實現的角度出發，不同的角度必然會引發衝突。作者舉了一個例子，他說，用戶們喜歡一個“心靈感應”的界面和一個30英寸的顯示器，而我們的程序員喜歡的只是用Python搞的命令行接口。呵呵。另外，作者引用了一個Excel中的“pivot tables ”所引發的一個歷時最長的爭議作爲案例。
最後，作者討論了，爭論是一個很好的事，就好像法院裏的原告和被告都有自己的辯護律師一樣，這有助於人們逼近事物的真相。對於軟件開發也一樣，良好的爭論其實是對產品有好處的。我們應該在爭論中關注事。
當在討論到和程序相處的過程，作者說到了和程序員相外並不是一件很容易的事，因爲你並不編碼而也沒有技術能力，通常會受到程序員的冷眼。所以在和程序溝通的過程中需要保證兩件事：1）確信自己的正確的。2）讓程序員尊敬自己。而對於第二點，如何讓程序員尊敬自己，作者發表了自己的見解：1）demonstrate intelligence（展示自己的才華），2）open-mindedness（心胸寬闊），3）fairness（公平，正直）。千萬不要搞辦公室政治，或是開私密的經理會，等等。不然的話，你必然受到排擠。
推薦讀物
最後作者給大家推薦了一些很不錯的讀物：
（完）