軟件開發項目經理的起源
在一個軟件團隊里, 不同的人有不同的投入, 我們在 豬,雞和鸚鵡的故事里已經說明了. 不同的人還要在團隊中擔負不同的任務, 我們也要講一下.
開發人員 （大部分內容在: 現代軟件工程講義 2 工程師的能力評估和發展）
項目經理 ( 這篇博客 )
測試人員 ( link)
1. 微軟PM 的來歷
大部分公司的項目經理叫 Project Manager， 微軟的經理叫 Program Manager, 這有什么本質的區別么?
微軟曾經也是一個創業公司, 兩個創始人都是 dev, 招聘的新成員也大多是像他們一樣的開發人員, 這其中就有一個叫 Charles Simonyi的超級程序員 (當然還有像 Steve Ballmer 那樣的超級銷售人員, 這里按下不表)。
1974 年, Charles Simonyi 在Xerox PARC 開發了 WYSIWYG (所見即所得) 的字處理軟件 Bravo, 成為 PARC 的 Alto 個人電腦的重要應用軟件。
(作為時間的參照:
同一年, Steve Jobs 從印度回來, 加入Atari 公司打工, 因為其他員工不能忍受他的傲慢態度和衛生習慣, 他只好上夜班。
同一年, Bill Gate 在哈佛大學讀 2 年級, 他第二年看到了個人電腦的曙光 – MITS Altair 8800， 于是退學創立了 Microsoft.
)
1981 年, Charles 加入了微軟公司, 領導 Word 和其他辦公軟件的開發。 很多開發人員聚集在一起, 怎么工作呢? 如果大伙做的是搬磚的體力勞動 (我很喜歡用搬磚的例子), 那么在一定限度內, 人員的增長和項目復雜度的增長是線性的關系; 程序開發就有些不同, Charles 發現項目管理的復雜度似乎是和人員數量的平方成正比。 一個團隊里有 4 個成員, 就有 6 種雙向依賴和交流的途徑, 然后增加一位新成員, 就要增加 4條新的雙向依賴交流的途徑。 對于 N 個成員的團隊來說交流的途徑總數是 n * (n-1) /2, 這種 N 平方的增長是不可持續的。
怎么辦? Charles 想到了一個辦法 - 他提議把程序員分成 Master Programmer 和 Slave Programmer, MP 和其他成員交流, 了解需求, MP 只寫抽象的偽代碼, 或者對功能的描述; SP 根據MP 的文檔, 實現具體的功能。 SP 只用和 MP 交流。 這樣不就大大減少了交流的成本么?
這個想法在理論上是好的, 但是在實際上, 沒有人想做 Slave Programmer, 剛加入團隊的成員問 - 為什么我們不能當 Master Programmer? 這次改革***不了了之。
但是, 隨著軟件復雜度的提高, 用戶需求的多樣化, 市場競爭的日益激烈, 光有程序員和銷售人員是不夠的。 我們需要專門人才來做下面的事:
怎么讓軟件變得可用 (usable), 有用 (useful)
銷售人員把顧客的需求直接告訴開發人員, 但是開發人員往往聽不懂。 我們需要專人來把市場/銷售人員那一套 MBA 的套路翻譯成程序員能懂的功能說明 (spec)
一個產品團隊要做很多事, 這些事往往是程序員不愿意花時間的:
和客戶交談, 組織用戶調查, 發現用戶需求
了解和比較競爭對手的產品
怎么改進團隊的流程
誰都不愿意做, 誰都沒有能力做好, 大家寧愿盯著屏幕寫代碼。 怎么辦呢? 這時候有另一個聰明人出現了, 一個叫 Jabe Blumenthal 的程序員提出了 Program Manager (PM) 的頭銜, 并成為了微軟***個 PM (1984年). PM 做什么呢?
2. PM做開發和測試之外的所有事情
Program Manager 和一些公司的 Project Manager 的區別:
| Project Manager | Program Manager |
|
是團隊的行政領導, 帶領大家在項目中工作。 |
和大家平等工作, 推動團隊完成軟件的功能。 |
| 通常是團隊和外界打交道的唯一代表 | 一個團隊可以有很多PM |
| 對項目的功能有***的決定權 | 和其他團隊成員一起形成決議 |
| 管事也管人 | 管事不管人 |
| 不一定做具體工作 | 一定做具體工作 |
在別的團隊中, 也有產品經理的職位, 例如這個博客 (和書) http://iamsujie.com.
問: 目前微軟公司有哪幾類的PM?
答: 有做功能設計的PM; 有些需要很深的 Computer Science 的專業知識 (如 Visual Studio, SQL server, Windows Server, Bing Search 等團隊的PM ), 有些需要對商業和客戶很強的了解能力 (如 Office 應用軟件的PM ), 有些需要廣泛的經驗和知識面, 商業拓展能力 (如 MSN 部門的 PM); 有些是驅動流程的PM, 例如推動幾百人的團隊完成一個版本的開發, 又如保證 WP7 在幾十個不同硬件上能發布; 也有專門深入某一領域的 PM (如 localization/globalization); 還有和研究人員合作, 做技術轉化的 PM。
問: 既然PM 這么厲害, 為什么不讓他們領導開發人員和測試人員, 這樣 PM 工作起來不就是更有利了么?
答: 首先, 我們認為好的產品設計是在平等討論 (甚至爭論) 的基礎上產生和完善的, 如果討論的一方同時又是另一方的老板, 則無法進行平等和無拘束的討論。
其次, PM 的產品是 spec (規格說明書), PM 要憑自己的能力, 把用戶的需求展現成 dev/test 能夠了解, 能夠執行的語言, 從而贏得同伴的信任和尊敬。 如果PM 同時又是其他人的老板, 則不必寫太好的 spec, 用命令即可說服別人。 再次, PM 不一定是很好的行政經理, 硬把管理不同專業的 dev/test 的任務加到PM 頭上, 反而會壞事。 關于這個問題, 這里也有一篇討論.
問: PM ***的, 最獨特的貢獻是什么?
答: 保持團隊的平衡。
一個軟件產品幾乎做不到同時又多又快又省。 在別的領域也類似, 中國在大躍進期間提出了 多快好省的要求。 ***只得到一個 “多” - 人多。 （參見 軟件工程的估計）
大部分優秀的團隊可以做到兩個:
多, 快, 但是不省
多, 省, 但是不快
快, 省, 但是不多
PM 要帶領團隊選擇哪兩個是最重要的, 哪一個是可以犧牲的。
還有許多不那么優秀的團隊也許勉強可以做到一個:
多, 但是不快, 不省
省, 但是不多, 不快
快, 但是不省, 不多
當然還有一些團隊一個目標也達不到, 中途作鳥獸散了。
問: 我們團隊有幾個程序牛人, 參加過 ACM 比賽什么的, 他們寫的程序都不用測試, 為什么還要 PM？ 如果PM 也來開發, 是不是項目進展更快?
答: 程序 和 軟件有區別, 請看: http://www.cnblogs.com/xinz/archive/2011/05/22/2053838.html
其次，在下面的圖中, 團隊有很多劃船的牛人, 也有一個拿著話筒的舵手. 如果這個舵手也開始劃船, 后果會怎么樣?
可能小船的速率會快一些, 但是小船的方向, 穩定性會出問題。 你愿意船很快, 但不穩, 而且***到了一個以前沒計劃的地方?
問: PM 文化的盛行有副作用么?
答: 任何方法或文化都有優點和缺點, 由于大部分決定都是經過平等的討論協商折中的到的, 一個后果是 “design by committee”, 一些產品不能很快跟上市場變化, 在需要個人特色的方面, 如設計/UI, “committee”設計出來的東西大多中規中矩, 但是很多方面了無新意。
3. PM 的能力要求和任務
成為一個團隊的PM, 需要哪些能力呢?
學習能力:在一個新領域中能很快上手
觀察理解能力:能理解用戶, 站在用戶的角度上考慮問題, 觀察發現用戶不善于表達的需求, 觀察團隊成員的言外之意, 老板/客戶/利益相關人的弦外之音.
分析管理能力:每天項目中發生的事情千頭萬緒, 能夠分析出重點, 找到優先級, 做決定…
一個項目和個人一樣, 每天都會碰到各種問題:
重要而緊急的 //網站崩了!
//程序員二柱突然說他要離職!
重要而不緊急的 //按照流量和內容的發展趨勢, 三個月后, 目前的架構似乎撐不住, 但是現在還湊合…
//程序員們都不寫文檔, 他們三個月前說等忙過之后會寫的, 但是…
不重要而緊急的 //老板的老板問到了項目的進度! 要寫一個PPT，請若干人征求意見
不重要且不緊急的 //…
PM 如何處理這些事情呢?
交流能力, 處理沖突的能力:其他角色碰到沖突一般會來找 PM. PM 也要鼓勵團隊成員保持斗志。
一定的專業能力: 寫代碼, 玩轉Excel, PPT, Visio, 甘特圖, 會PS, 有文字功力, 能寫有人讀的博客, 總得有幾招絕活吧!
在一個項目中, PM 的具體任務是什么呢?
帶領團隊形成團隊的目標/遠景, 把抽象的目標轉化為可執行的, 具體的, 優美的設計。
管理軟件的具體功能的生命周期 (需求/設想/設計/實現/測試/修改/發布/升級/遷移/淘汰)。
創建并維護軟件的功能說明書 (specification), 讓它成為開發/測試的及時準確的指導, 而不是障礙。
代表客戶和用戶的利益, 主動收集用戶反饋, 預期用戶新的需求。 協調并決定各種需求的優先級。
分析并帶領其他成員形成對缺陷/變更需求的一致意見, 并確保實施。
帶領其他成員確保項目保持 功能/時間/資源 的合理平衡, 跟蹤項目進展, 確保團隊發布讓客戶滿意的軟件。
收集團隊項目管理和軟件工程的各種數據, 客觀地分析項目實施過程中的優缺點, 推動項目成員持續改進, 從而提振士氣。
成功的PM 如果得到團隊成員的支持, 會是什么樣?
成為項目流程的主人 - 驅動流程, 會議, scrum, 進度
代表團隊, 向上級/伙伴團隊/客戶/市場報告項目進展
不用自己寫一行代碼，也同樣可以積極地影響項目和產品
PM 如果得不到到團隊成員的支持, 會是什么樣?
在各種會議或流程中浪費大家的時間, 發一些大家不讀的 “Status Mail”.
不能凝聚團隊, 形成共識
對團隊的狀態不了解, 也不能有效和準確地向有關方面報告團隊的情況, 獲得支持
對項目和產品造成負面的影響。
4. PM 們的故事
講了這么多條條框框, 我們還是講幾個故事吧:
A) 是不是所有的好功能都是由PM 主導, 一步一步根據用戶需求，按照用戶場景設計，然后可用性測試等等步驟之后得來的？
功能本天成，妙手偶得之——一個來自微軟的故事。[注3]
約摸在1985年，微軟的一個叫Steve Hazelrig的工程師正在寫Mac Excel 版本的打印功能，那時候激光打印機很貴，而且離辦公室也不近。他懶得經常跑到打印機那兒取打印紙，檢查打印效果，就寫了一個小程序，把要輸出到打印機的圖像顯示在屏幕上，還有一個放大鏡功能可以把局部放大以檢查每個像素的位置及效果。這時一個PM路過看到了這個小工具，說，這么酷的東西，為啥不做成一個功能呢？
所以后來微軟的編輯軟件都有“打印預覽”這一功能。然而，用戶們并沒有正式地要求這一功能。
B) PM 怎么說服聰明的同事
這個故事在 [注4, 注5] 中都提到了. 在Macintosh 研發的過程中, 由于計算能力的限制, 計算機的圖形顯示非常緩慢. 一位聰明的程序員展示了他的新算法, 能很快地畫圓形和橢圓. 當他得意地展示給 Steve Jobs 看的時候, （作為一個不懂編程技術的 PM，Steve 應該表示仰慕才對…） Steve 看了之后, 反問 - 你能繼續改進, 讓圓角的矩形框顯示速度加快么? 程序員說: 這個太難了, 也沒有必要. 橢圓不是挺好的么? Stevel 為了說服同事, 建議兩人到外面散步, 然后指出現實世界中的各種告示牌都是用 圓角的矩形框 來實現，走了一圈, 同事就被說服了。 過了幾天, 圓角的矩形框也可以很快速地在屏幕上顯示了。
C) PM 的分析能力和韌性
能把市場, 我方的優勢和劣勢, 創新的機會講得頭頭是道, 也是一種能力。 在軟件工程課上我們講過 NABC 方法。 喬布斯在 NeXT 公司時那樣也做過很有說服力的分析:
注意, 這么厲害的 PM, 分析的這么透徹, 但是 NeXT 的產品還是失敗了.
但是喬布斯沒有氣餒, 又投入了另一個公司的運作 – Pixar.
你有這些能力么?
原文鏈接：http://www.cnblogs.com/xinz/archive/2011/11/07/2239150.html
【編輯推薦】
