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