我最近和项目经理谈过。 她告诉我她的故事。
我曾以项目经理的身份为项目团队提供便利。 为什么是项目经理？ 因为项目有一个开始和结束。 我们拥有（并且仍然有）太多的产品，无法长时间保持相同的团队。
对于程序，团队保持团结并转移到其他功能集/内部产品，直到程序完成。 我待在那个团队之前，直到我们所有人都完成了该计划。 现在，我们都有选择。 我们可以迁移到新产品和/或新团队。 一些团队成员四处走动，但许多人留在产品上，并继续进行下一个项目或计划。
当我学会管理程序时，我也同样管理着程序。 我的工作是为人们交付产品铺平道路。
我的工作之一是创建时间表，以便组织对我们将交付的内容和时间有所了解。 这些是“我们认为我们可以尽早实现此功能，而稍后再实现”的时间表。 永远不会有甘特图。 通常，路线图看起来并不像承诺。 我和团队一起使用滚动波计划来完善细节。 我们一直致力于提供功能。 我们每周提供一些东西，效果很好。
然后，我们去了“全Scrum”，所以我的经理称我为“ Scrum Master”。 很好 帮助团队有效发挥作用仍然是我的职责。 我们没有专职产品负责人，因此我帮助采购订单确定了何时可以交付哪些功能。 对于这些程序，他们称我为“首席Scrum Master”（即使我们使用流程），而不是迭代。
现在，他们想称我为产品负责人。 我不是采购订单-我不管理积压订单，也不想这样做。 我有别的 我协助团队交付东西。 我为球队铺平道路。 我应该怎么称呼？
首先，让我们讨论一下同事的工作以及我们如何命名该角色。
Scrum Master还是敏捷项目经理？
如果我的同事在Scrum工作，她可能是Scrum管理员。 但是，她并没有“促进和支持Scrum指南中定义的Scrum。” （您可能喜欢为什么敏捷项目经理不是Scrum Master 。）
Scrum不是她的工作。 她的工作是促进团队尽快交付价值。 速度不快，所以它们会为将来制造垃圾。 不，要尽快。
她是一名敏捷项目经理。 当她管理程序时，她是敏捷的程序经理。 （有关创建成功的敏捷项目的更多信息，请参见该角色。）她通过以下方式帮助团队：
- 促进团队的流程。 这包括帮助团队查看其状态和度量。 （她花了很多时间问这个问题，“这种方法对我们有用吗？我们需要衡量一些东西吗？”）
- 促进团队的工作协议，以及团队如何同意一起工作。
- 与产品负责人一起促进产品的愿景和发布标准。
- 评估，管理和消除团队无法管理的风险和障碍。 她花很多时间与经理一起工作。
- 促进回顾或帮助其他人促进回顾。 她一直在尝试让团队之外的人参与进来，以便她可以参与。
如她所说，她帮助团队交付产品。 她从未告诉人们做什么或如何做他们的工作。 （是否有项目经理在做并且还在做？当然。其中有些甚至是Scrum Master。更改角色名称不会改变一个人的行为。）
她的公司可以随便给她打电话。 但是，他们离促进团队工作越远，他们对每个人的困惑就越大。
而且，在这个组织中，他们现在处于所有可能的情况中最糟糕的情况：团队协作不足，没有产品人员来推广产品的业务价值。 （请参阅何时完全没有产品负责人 。）
产品负责人的工作
如果您使用术语“产品负责人”并且还没有阅读《 Scrum指南》 ，请这样做。 （这是指南中直接指向产品所有者的链接。）
我的项目经理同事是正确的。 她是团队的仆人领袖。 如果团队使用Scrum，则她可能是Scrum Master。 但是，她的团队很少使用Scrum。 他们更经常使用具有各种计划，演示和回顾节奏的流程 。
（为什么？她在组织的一部分中工作，试图尽快获得反馈。他们每两周更改一次工作的频率就超过每两周一次。而且，他们的工作中断是无法预测的。）
我喜欢将产品负责人视为通过团队来发挥产品业务价值的人。 （我写了一个扩展的系列文章，从产品角色开始，第1部分：产品经理，产品所有者，业务分析师 。）
牧羊包括：
- 定义团队需要解决的问题并对这些问题进行排名。
- 为团队提供前瞻性。 （不仅是这批工作，而且是将产品运往何处的产品。
- 了解团队并可能做出外部承诺
PO还需要做更多的工作。 （我在“ 创建成功的敏捷项目和敏捷与精益计划管理”一书中写过更多文章。）
我的同事不是产品负责人。
角色名称有力量
我没有遇到很多自给自足的团队。 我遇到了许多需要某种形式的协助的团队。 即使只是了解团队中更大的组织需要什么。 （作为团队成员，我不想每周参加20次会议只是为了了解。对吗？我希望项目经理这样做。）
而且，我遇到的每个团队都需要产品指导。 我更喜欢将团队协助与产品指南分开。 （现在，我很少看到敏捷文化。也许，如果我看到了敏捷文化，我们就不需要那种分离。）
我鼓励功能小组影响PO来更改工作等级。 并且，如果PO在工作中看到改变产品业务价值的某些内容，则PO应该发表评论。 （而且，我对这些评论响亮而充满活力。）
这是我对角色的定义：
敏捷的项目经理可以帮助并带领团队克服他们的障碍和风险来交付产品。 通常，它们是团队周围的墙，因此组织的其余部分不会阻止团队成功。
再说一次，以我从未有过的愚见，Scrum Masters需要做到这一点而不是“促进和支持Scrum”。 Scrum指南不同意我的看法。 没关系。 （就像敏捷教练一样， Scrum 不是目标 。产品交付是目标。）
敏捷项目经理应对阻碍团队交付产品的障碍。 他们解决了整个组织中阻碍团队交付的问题。 他们管理任何必要的协调。 （请参阅组件团队在产品和组织中创建耦合 。）
产品所有者可以在短期和长期内发挥产品的商业价值。 根据计划或组织的规模，他们可能会使用产品价值团队来进行长期管理。
更改角色名称会增加价值吗？
我的同事提出了一个有趣的问题。 她的组织似乎不想改变她的角色职责。 而且，他们似乎没有意识到为团队提供便利的人和代表客户管理产品积压工作的人之间的区别。
改名后，我的同事在完成自己想要的工作时遇到了更多麻烦，并且看到了需要。
她的经理比团队需要更多的帮助。 他们正在尝试对其他所有人而非自己施加“敏捷”。
无故更改名称不会改变我们的工作。 而且，如果我们选择更改角色名称，让我们解释一下新名称的含义。
我宁愿不要使各种名称重载运算符 ，但是可能就是我。
如果您遭受此名称更改的困扰，请考虑询问您的经理希望您提供什么。 或者，说明您的角色是什么以及您想给自己起什么名字。 但是，不要将任何人的名字都与您的角色相混淆。
翻译自: https://www.javacodegeeks.com/2020/02/agile-project-manager-scrum-master-or-product-owner.html