我对这个主题进行了少量的研究，并且惊讶地发现没有很多有用的内容来解释项目和产品之间的差异以及由此产生的角色。所以我把这篇文章放在一起，根据经验我的想法，并希望它对某人有所帮助。

根据维基百科，项目一词是一个涉及研究或设计的协作企业，经过精心策划以实现特定目标。

来自拉丁语projectum的词语意为“在行动之前”，最初采用英语意味着行动的计划，而不是行动本身。

在现代商业中，项目通常被用来表示计划，执行和交付。当用于交付的过程是非敏捷方法（例如瀑布）时，更经常使用软件开发中的术语，并且通常指的是一组连续的专家阶段，其中管理者需要跟踪许多相关部分，财务，风险和交付时间。

在我看来，如果组织设计过于专注于技能或架构组件的专业化（Conways Law），那么任何计划都需要项目经理，敏捷与否。过度专业化是一种局部优化，假设如果您围绕特定技能组（例如DBA或BA）或架构组件（例如代码库或服务）对人员进行分组，则可以提高成本或质量。遗憾的是，在实践中这种情况很少发生，而且这种优化在系统层面具有反面性，产生高水平的交接，正在进行的工作，缺乏所有权和质量差。您可以在我的博客文章中了解更多相关信息，以获取更多容量，而无需雇佣任何人，以及Craig Larman去年在Adventures with Agile上发布的演示文稿。

在这种情况下，项目经理是唯一的所有权点，以某种方式将整个计划带到预期的结论。

通常，项目的资金来源于具体目标和商业案例。由于时间有限，预期价值和成本有限，通常会将人员或团队聚集在一起，以便规划，执行，测试和发布项目成果。这些团队通常会在项目结束时解散。

然后，项目经理职能是创建一个计划，通常称为基准计划，项目将遵循该计划，然后驱动参与项目的人员尽可能少地改变计划。如果计划存在偏差，那么项目经理的角色是限制这些偏差并尽可能将执行恢复到原始基线。如果这超出了可接受的差异并且无法恢复，项目经理必须向原始利益相关者或投资者解释并获得接受，或者在最坏的情况下，告诉他们如何。有时，这种偏离基本计划可能会导致资金从项目中撤出。

产品负责人反过来没有基线计划。产品所有者角色是不断评估继续执行交付的可行性。产品所有者可以选择生成高级路线图而不是详细计划。路线图通常仅提前几周详细说明，然后随着时间跨度的增加逐渐变得不那么精致。

最终，在许多情况下不需要估算和预测，因为每个人都知道团队在任何特定时刻都在处理最重要的项目。

简单看板董事会敏捷中的产品组通常由长期存在的团队组成，有时持续多年。产品负责人有两个责任;这些是优先次序和澄清。通过不断确定工作的优先顺序，并确保交付团队尽可能优先地开展工作，利益相关者知道无论结果如何，团队都会以尽可能少的工作量来实现正确的目标。

在敏捷开发中，每次发布或更快地获得反馈。在Scrum中，这是在sprint结束时，在Kanban中，有时是Scrum，每次完成一个工作项。

然后，这些反馈指导进一步工作的优先顺序，确保团队正在构建正确的事物（降低业务风险），并且他们每隔几周持续交付（降低交付风险）最长时间。

由于批量交付周期较大而导致团队中出现的压力（通常是在项目中确定时间，范围和成本），通常会导致团队走捷径，导致缺乏掌握的动力降低。项目成功的主要衡量标准通常是交付团队在预算内按时交付一系列功能。这种关注，消除了团队提出问题为什么的能力，并使团队关注什么和如何。由于团队失去了目标感并且仅仅成为Project机器的扩展，因此缺乏动力。由于固定的范围和如何操作的自主权的丧失，复杂的低动机也来了。在危机中最有效的执行方式是经理告诉团队究竟做什么和何时做什么。当危机成为通常的运作模式，并且自治被消除时，动机和不满就会相应增加。

随着动力的减少，人们离开，使按时交付的问题更加复杂。

相反，在产品交付团队中，没有这样的压力。时间和成本可能是固定的，但范围不是。通过可变范围，通过与利益相关者的反馈和协作，经理/领导者/ Scrum Master能够消除这种压力，并创造一个个人达到更高潜力并自主运作的环境，从而更好地解决问题，提高所有权结果，更快的上市时间。

简而言之，项目经理，无论他们是否具有敏捷的职位，都是一个止步缺口的角色，同时该组织消除了阻碍团队自我管理和优化产品交付的障碍。

这通常是：

• 引入概括专家（系统优化）和减少过度专业的孤岛团队和瓶颈人（局部优化）
• 自动化测试的引入和成熟，允许跨团队共享代码所有权和自动集成

显着减少了对人员级别协调的需求，而是将依赖性问题转移到代码级依赖性

• 取消长期固定范围计划，而不是基于价值/风险的优先排序
• 从理论X到理论Y的管理风格转变

删除任意截止日期

即使在短时间内删除开发者承诺的想法

删除被锁定的互联网网站

取消奖金作为激励手段

增加透明的财务管理

增加短期滚动预算资金优先积压和持续的产品可行性反馈

领导力的提升和管理的减少

发生这种情况时，项目经理的需求就会消失。对于以纯粹敏捷方式工作的团队而言，不需要高水平的协调和虚假动机。

进一步阅读

协调混乱。感谢Ari Tikka的分享。

感谢Ram Srinivasan分享以下链接：

项目与产品

没有项目 - 项目有缺陷

超越项目