當大家討論到「專案管理」以及「開發流程」時，不免俗地會重啟敏捷式開發（Agile Development）和瀑布式開發（Waterfall Development）的辯論。尤其被美式新創文化渲染的今天，很多人已經深信，只要採用敏捷式開發，整個專案的管理和執行就不會出問題了。
這樣的辯論其實不是非常重要的命題。因為敏捷式開發和瀑布式開發，本來就沒有互斥的概念。
多數企業組織看待「專案管理」時，常從工程師的角度想事情，實際上只有不到一半的考量是技術考量，剩下的都是其他營運層面的疑難雜症。因此，並不是所有產業和業務，都能夠塞入兩個禮拜的sprint（進程衝刺）去處理，也不是所有問題都能等到「跑完整個開發流程」才會去面對。
「敏捷式」和「瀑布式」的命題，要說是管理方法的革新，不如說是一個科技進步的副作用：當軟體不再藉由光碟片銷售，軟體的開發和更新流程自然就會縮短，這不代表任何「瀑布式」的長期計畫已經過時，也不代表所有「敏捷式」的即時連動模式都是好事。
其實，所有的科技公司都不可能達到，純粹以敏捷式或瀑布式開發去進行管理，反而是依照自己產業所需的採購流程、品管流程和跨領域分工模式去量身訂做，畢竟管理是沒有「尚方寶劍」的，一定是隨環境而改變。
沒有恰當的Stakeholder，PM就跟「打雜工」一樣
敏捷式開發在台灣鼓吹也將近10年了，但客觀而言，台灣的軟體開發團隊效率並沒有跟上美國的腳步。為什麼呢？
我們的工作和產業文化中，並沒有「Stakeholder」的完整概念，直譯就是「利害關係者」，在一專案開發流程中，扮演的角色是確保究責（Accountability），明確溝通並確保專案的目標、時程和結果的期望值。
大家會覺得這種責任應該是落在PM（專案經理）身上嗎？還是老闆、抑或工程師？
「為成果負責」的事，台灣人常認為應由PM或老闆來擔。其實不是，Stakeholder的責任落在誰身上，跟一個人的職務功能無關，是跟專案的專業性質有關。
Stakeholder的工作不是在告訴大家「怎麼做、何時做哪些事情？」而是提供專案所需的專業判斷能力，來協助定義專案的方向、範疇，並在最後主導結案流程。
打個比方，如果今天公司內部有個「提升行銷自動化」的專案，按常理來說，很有可能會牽涉行銷、PM、工程等跨部門職務的人才。專案的時程、人力配置和風險，自然是需要由PM來評估，但是該專案的Stakeholder則應該由主要專業——行銷來擔任，因為對最終成敗，最能感同身受和最能夠裁判的，也是行銷部門。
但在台灣，公司大都是一條龍囑咐下來，老闆吩咐給PM，PM負責按部就班、分配工作，並且負責監督作業。
坦白說這種作法是相當拙劣粗糙的企業管理方式：一位PM怎麼可能去檢查所有人，督促不同部門完成工作？
分工與究責明確，才能拯救企業效率
也正因為我們的企業中，常常執行端（PM）和監督端（Stakeholder）的職責沒有明確分開，該有的各種專業，Stakeholder沒有指派，才搞得PM跟打雜工一樣什麼都得管、什麼都得做，而且做很多都是自己專業度不足以應付的「鳥事」。
這更是企業效率一直很難再提升的主要原因之一。
如此現象當然其來有因，在華人歷史中，相較起中亞和歐洲，幾乎沒有發展「分權」和「共議」的觀念。即使空有執行與監督分權的制度，東亞社會仍多會回歸單極的獨裁決策結構。
Stakeholder無論在敏捷式或瀑布式開發，都是相當核心的觀念。 在瀑布式開發，Stakeholder常指派給產品經理，因此跟PM的工作是分開的。在敏捷式開發，Stakeholder的角色統稱為Product Owner（產品負責人），是根據每個專案的專業需求，去尋找最能夠裁決專案方向的人來擔任。
PM雖然負責管理時程表，但是其評估時程所需的專業能力，卻是仰賴Stakeholder。缺少了正確的Stakeholder，PM估出來的時程，到最後一定和現實情況會有很大的差距。
Stakeholder也不應該是老闆，因為老闆的角色應該是「負責策略性決策和規畫」，不可能在每種專業的執行面都瞭若指掌，多數的情況下不適合擔任Stakeholder。
故此，當我們在思考說，到底PM是否要懂技術？或是要懂特定專業才能管理時程？其實真正的問題不在PM的能力，而是在於組織的專業分工和究責制度。
責任編輯：陳建鈞
