OEM 這個名詞在亞洲人中非常普及，但在歐美卻相對陌生。許多歐美人難以想像，一個品牌的產品竟然是由另一家公司製造的。從產品本身來看，品牌公司 很難控制其他公司生產的產品質量；從設計角度來看，這樣一來設計理念和技術不都被學走了嗎？從OEM公司的角度來看，沒有理由辛苦製造一個產 品，最終利潤卻被品牌公司賺走。

亞 洲人都知道上面質疑的問題的答案，我就不再多做解釋了。今天我想談論的是PM和PMO之間的關係。

過 去，所有專案都是由PM一肩扛起。因此，PM們都是公司最重要的資源。大家都知道，PM需要對產品非常熟悉；了解並處理專案中所有問題和產品 與專案走向；還要帶領團隊完成專案。因此，PM的角色大多數都是由對產品非常熟悉的資深工程師升任。

但 是，產品的專業技術（理科）和專案管理（文科）是完全不同的領域。要找到一個同時具備產品專業知識和專案管理特質的工程師非常困難。這有點像 要找一個同時精通繪畫和音樂的人。

PMO 的誕生讓我們想到，我們是否有機會把產品生產技術和專案管理本身分離出來，變成兩個專業的工作。PM作為產品交付的最終負責人，致力於產品需 求和製作方法本身。然而，像那些專案內部溝通、資源分配、問題管理、專案執行方法（methodology）等PMP專業工作，例如解決內部 爭執、追蹤進度、工作事項佈達等，就可以交由PMO處理。

就 像OEM不會搶走品牌公司的品牌一樣，PMO也不會也沒有能力爭奪PM的功勞。PM仍然擁有最終決定權和決定產品走向的權力。PMO只是幫助 專案更順利地進行而已。由於沒有產品專業知識的負擔，PMO可以把專業能力致力於提升專案管理能力，在未來可以服務更多不同類型的產品。

很 多人在學習敏捷方法論時常常會問PMP中PM角色應該是產品經理還是Scrum教練。我不打算加入這場論戰（其實我聽到大部分人說是產品經理 比較多）。但我認為，在專案管理專業化的今天，確實應該把專業能力和管理能力拆分成不同的兩個角色，這樣對專案本身是最好的。

就 像台灣通過幾十年努力把OEM這個觀念傳播到全世界一樣，也期待PMO的觀念能傳播到每一家企業。正如我常說的，專案管理本身就是一門專業！

敏 捷與套裝軟體

近年來Agile  methethology的風潮席捲全世界軟體業，弄得好像哪個公司不懂Agile就落伍了一樣。我的公司現在也讓很多專案用Agile的方法做。我本人也是Agile methodology的信奉者。

最近有人問我說，為什麼大型套裝軟體的案子不能用Scrum (Scrum是Agile 的重要核心觀念)做。一個簡單的回答，就是依照Stacy matrix module, 套裝軟體的專案大部分都屬於simple, 頂多是complicated等級的案子。所以不適合用Scrum，比較適合以傳統PMP 方法為主的water fall 作法。

我舉一個組隊爬山的例子。如果有一個山從來沒有任何團隊爬過。爬山過程中不知道哪裡有懸崖哪裡有危險動物，我建議就用Agile (scrum) 去多方嘗試。但是即使再高的山(像是玉山富士山)，其他人都已經爬過了，還把感想寫在FB上了，那我就建議用傳統water fall的方法，依照前人的路線(lessoned learn)來爬山。

之前SAP的導入為了搭上Agile的風潮並想要更快的導入SAP，就提出一個water fall和scrum混和的Activate的methodology。結果蠻失敗的，原因之一是專案範疇(scope)混亂。如今的商業環境不太能允許一個專案因為Scope不清楚而讓公司預算無法控制。

我們公司也有用Agile成功的案例，例如很多AI的案子，因為一開始不知道要用哪一套演算法(Algorism)所以透過Scrum一次次的sprint去找到對的方法來執行。這種案子不需要外部顧問協助；也沒有硬體支出。所以成本相對低廉，即使預算不可控也不會花太多錢。

台灣PMI創始人在一次演講中說，只懂PMP而沒有Agile的精神是觀念落後。但是什麼專案都拿Agile來套的話會是災難。

Agile methodology強調專案人數必須要控制在5-20之間的團隊的原因就是因為Agile可以做那種AI應用；小型自動化開發的案子。但不適合做ERP, MES等級的大專案。

我拿蓋房子為例，要讓Agile做室內裝修會是好工具；但是如果連土建架鋼筋都要透過一次次sprint來調整就沒辦法做了。在舉打仗為例子，agile像是五人一對的海豹特種兵部隊，可以執行各種困難的任務。但是你不能把這種部隊放在烏克蘭這種都是平原的戰場跟人家坦克飛機對打。

在技術日新月異需求越來越多元的今天，Agile絕對是有別於傳統Water fall的新的專案手法。但是ERP, MES這類套裝軟體這種在專案開始以前就很清楚專案scope的專案，就不可以用Agile來執行。