怎樣做一個 Program Manager

我個人認為，這是一篇不錯的文章，雖然我不是Program Mananger，但是我幾乎在做著和這個職位很相似的工作。在這裡，我把這篇文章推薦給所有的程式員，我相信，這篇文章會讓你明白，只有技術是遠遠不夠的，因為沒有Program Manager這個角色，程式員們只不過一些手中拿著利器卻不知所措的散兵遊勇。我希望我的導讀和原文能給所有的程式帶來啟示。(本文同步發佈於：酷殼 cocre.com)

 

原文在這裡：
“How to be a program manager”
http://www.joelonsoftware.com/items/2009/03/09.html

 

 

這篇文章的作者叫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主要負責哪些事務：

1. Design UIs （使用者介面的設計）
2. Write functional specs （書寫功能規格說明書）
3. Coordinate teams （團隊協調）
4. Serve as the customer advocate, and （從使用者角度思考問題）
5. 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的一個初始化版本發給Team Dev（Ben Waldman）時，Team Dev非常快地實現出了一個原型，並提供了物件導向的相關介面。但可惜的是，那並不是Program Manger所想要的。
• 作者描述了一個細節如果協助Team Dev解決技術痛點的例子。那是關於把一個Excel中的一個cell的值取出來的例子。當時，developer團隊認為這是一個痛點，因為這個值可能是任意類型的。而VB中卻需要先聲明變數的類型。後來，作者找到了VB的Team Dev，瞭解到了Variants 和IDispatch可以做到這個。

我們可以看到，FS在這樣反覆地和developer 團隊推敲，甚至去協助程式員解決技術難題，之後最終才能確定下來。一旦FS確定後，program manger需要做兩件事：

1. 負責解釋相關的問題。
2. 組織並形成相關的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（公平，正直）。千萬不要搞辦公室政治，或是開私密的經理會，等等。不然的話，你必然受到排擠。

 

推薦讀物

最後作者給大家推薦了一些很不錯的讀物：

Making Things Happen （經理一般都在幹什嗎？）

Don’t Make Me Think  （如果你要寫FS或UI設計，你應該看看這本書）

User Interface Design for Programmers. （作者自己的書，關於UI設計）

How to Win Friends & Influence People （在人際關係方面，需要看看這本書）

 

 

（完）