当大家讨论到“项目管理”以及“开发流程”时，不免俗地会重启敏捷式开发（Agile Development）和瀑布式开发（Waterfall Development）的辩论。尤其被美式创业公司文化渲染的今天，很多人已经深信，只要采用敏捷式开发，整个项目的管理和执行就不会出问题了。
这样的辩论其实不是非常重要的命题。因为敏捷式开发和瀑布式开发，本来就没有互斥的概念。
多数企业组织看待“项目管理”时，常从工程师的角度想事情，实际上只有不到一半的考量是技术考量，剩下的都是其他运营层面的疑难杂症。因此，并不是所有产业和业务，都能够塞入两个礼拜的sprint（进程冲刺）去处理，也不是所有问题都能等到“跑完整个开发流程”才会去面对。
无论敏捷式或瀑布式开发，Stakeholder的角色都至关重要。
“敏捷式”和“瀑布式”的命题，要说是管理方法的革新，不如说是一个科技进步的副作用：当软件不再借由光盘片销售，软件的开发和更新流程自然就会缩短，这不代表任何“瀑布式”的长期计划已经过时，也不代表所有“敏捷式”的即时联动模式都是好事。
其实，所有的科技公司都不可能达到，纯粹以敏捷式或瀑布式开发去进行管理，反而是依照自己产业所需的采购流程、品管流程和跨领域分工模式去量身订做，毕竟管理是没有“尚方宝剑”的，一定是随环境而改变。
没有恰当的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的能力，而是在于组织的专业分工和究责制度。