不情愿的产品负责人

在讨论的这一点上，稍微同步一些可能是有意义的。

我们开始寻找所有传统软件开发角色在Scrum中的位置。在这个过程中，我们得出结论，许多角色要么是产品负责人的直接责任，要么是从产品负责人背后的团队中抽象出来的。这个结论既有力又有问题。

产品负责人是一个强大的结构，因为它为团队解决了两个重要问题。由于拥有产品方向的全部所有权，产品负责人设置上下文．它们为团队提供了一个单一的地方，让他们了解需要做什么，以及为什么它对业务很重要。亚博vip9通道产品负责人还提供协调．他们可以设定优先级，并决定团队何时达到目标。

想想如果团队中没有产品负责人会发生什么。我们可能有优秀的技术专家，但对更大的市场前景没有认识。如果我们把产品负责人外包给业务分析师或项目经理，我们就会得到一些亚博vip9通道协调一些上下文但很少看到幻象。如果我们只有一个产品经理，我们会得到更多上下文但我们会失去相当多的协调．

我们失去了单扭脖子。对于一个成功的敏捷团队，我们必须同时拥有环境和协调。

产品负责人在几个方面都有问题。大多数公司都没有招聘到具备该职位所需技能的个人。这些技能属于专家，业务分析师、项目经理和产品经理。亚博vip9通道我们是否将这些人转变为产品负责人?我们能否培训他们成为一名成功的产品负责人所需的新技能?公司会信任这些人吗?

如果我们从外面招人呢?我们如何利用我们的才华，奉献，以及最重要的....知识渊博的传统主义者吗?我们要把他们都放了吗?我们的组织结构是这样的:一个人就能做一切必要的事情吗上下文和协调为团队吗?我们能找到足够多的超级人类产品所有者来驱动我们的关键任务产品吗?在过渡时期我们做什么?

对于小型团队和中型组织来说，这个问题很重要。对于那些想要进行企业敏捷推广的公司来说，它甚至更大。这些地方上下文永远不会由一个人决定协调必须以更大的规模进行。

让我们从小事做起

我们将从一个小团队的背景和协调问题开始，看看当这个团队尝试扩大规模时会发生什么。

这张图描述了我们简单的敏捷场景。我们有一个产品负责人和一个6-8人的小团队，在这个例子中，是一个通才团队。

从团队的观点来看，产品负责人对定义产品负有100%的责任上下文的团队。他们创建产品待办事项列表，确定验收标准，让团队准备好待办事项列表，并与团队每天一起开发新产品。他们拥有整个产品愿景。

在本例中，Product Owner也拥有协调．他们设置待办事项列表的优先级，从而确定构建顺序。如果在sprint期间需要做出任何权衡，产品负责人将进行调用。在“冲刺”的末尾，产品负责人决定该特性是否满足“冲刺”开始时定义的验收标准。他们会告诉我们什么时候结束。

想想我们所描述的组织类型，可能是由一个有远见的领导者和一个开发团队组成的小型初创企业。没有任何时间或金钱的任何不必要的开销，这是所有的产品准备市场。除了单一的利益相关者，对任何人都没有责任。

您可能还会在一个小型的部门IT项目中看到这个模型，该项目不依赖于组织的任何其他部分。这可以是一个小型的部门网站，或者是一个自主开发的会计解决方案。这些场景是最敏捷的，最不受约束的……但是它们反映了大多数组织采用敏捷的现实吗?可能不会。

下一篇文章，我们将增加一些涉众，并开始缩放我们的项目规模。对我们的单点上下文和协调模型有什么想法吗?