产品负责人和学习，第4部分

第1部分介绍了PO如何看待全局并开发排名靠后的订单。 第二部分是关于小故事的学习。 第三部分是关于排名。 在这一部分中，我将讨论产品所有者价值团队，以及如何花时间做“所有事情”，尤其是如何改变故事。

假设您在开始使用敏捷之前就开始开发产品。 您的产品负责人（他们可能是产品经理和业务分析师的结合）为您提供了功能，问题列表以及知道发行版本的其他内容。 他们几乎从未与您讨论过您的技术债务。 以我的经验，除非非常重要的客户需要解决问题，否则他们很少讨论缺陷。 现在，他们应该为您提供所有产品的排名积压。 这是一个很大的挑战。

让我们讨论产品经理和产品所有者之间的区别。

产品经理面朝外，会见客户，问他们想要什么，讨论日期甚至收入。 产品经理的工作是将客户的意愿引入产品中，以增加产品的价值。 在我的世界中，产品经理负责产品路线图。

产品负责人面向内，与团队合作。 采购订单的工作是增加产品的价值。 在我的世界中，采购订单与产品经理（如果有BA，则与BA一起）一起创建和更新产品路线图。

业务分析师可能会采访内部和外部人员，以了解他们想要的产品。 BA可能会与PO或产品经理一起撰写故事。

产品经理，产品所有者和所有BA是产品所有者价值团队的一部分。 产品负责人价值团队共同创建和更新产品路线图。 在一个大型组织中，我见过一位产品经理，几位产品所有者和一些BA在整个产品生命周期内工作。 （我也已经看到，BA在产品之间转移，以在任何可用的地方提供帮助。）

那些在IT部门工作但不向公司外部发布的人又如何呢？ 您还需要一名产品经理，除了运气好的话，产品经理可以走下走廊讨论客户的需求。

如果您在小型组织中工作，是的，您很可能只有一个人来完成所有这些工作。 注意：同时也是产品所有者的产品经理是重载操作员 。 超负荷工作的人很难完成“所有”工作。 为什么？ 因为产品管理更具战略意义。 产品所有权更具战术性。 您不能持续地在不同级别上工作。 无论是战术工作还是战略工作，都是有好处的。 （有关此问题的更多讨论，请参见雇用适合的极客 。）

当一个人尝试完成所有工作时，可能还会遭受很多其他事情的困扰：团队的反馈，故事的破裂和排名。

产品负责人价值团队从客户/赞助商那里获取外部学习信息，从产品开发团队（编写和测试产品的人员）那里获取内部学习信息，并制定路线图以定义产品方向。

在敏捷中，您有多种发布选择：连续交付，在某些时间点交付（例如在迭代结束时或每个月或每当完成“足够”的功能时交付），或每月/每季度/其他某个时间段。

这是采购订单和变革的关键：故事越小或团队发布故事的频率越高，每个人获得的知识就越多。 该学习为PO的变更选择提供了依据。

在此示例路线图中，您可以在第一次和第二次迭代中看到部分功能集。 （我之所以使用迭代，是因为它们很容易在图片中显示，并且因为人们经常希望发布节奏，除非您进行连续交付。）

如果产品开发团队完成了部分功能集，例如Admin，第1部分，则PO可以决定该团队下一步是Admin，第2部分还是Diagnostics，第1部分。 实际上，如果PO创建了很小的故事，那么说“请从Admin和Diagnostics来做这个故事”确实很容易。 PO的问题是，当前最有价值的是什么：广度还是深度？

如果PO具有产品经理的外部信息以及BA和团队的内部信息，则PO可以做出决定。 除非有产品所有者价值团队，否则采购订单可能不了解宽度或深度或某种组合。

以下是您的采购订单需要一切时的一些问题：

• 什么对我们的客户更有价值：产品各部分的宽度或深度？
• 什么对我们的学习更有价值：广度或深度？
• 是否有人需要从任何广度或深度学习一些东西？
• 我们需要我们，客户，其他任何人的交货节奏吗？
• 帮助我们学习并取得进步的第一步是什么？

这些问题有助于对话。 该路线图可帮助每个人查看“产品所有者价值”团队希望产品运往何处。 接下来，我将做一个总结文章。 （如果您有未解决的问题，请告诉我。）

有人需要了解客户的需求。 该人员朝外，我称该人员为产品经理。 有人需要创建小故事，并从团队提供的内容中学习。 我称该人为产品负责人。 这些人员与BA一起组成了产品所有者价值团队，并随着时间的推移指导产品的商业价值。 商业价值不仅是功能，还在于何时修复缺陷以获得更好的客户体验以及何时解决技术问题，以便产品开发团队拥有更好的交付价值的经验。

接下来，我将做一个总结文章。 （如果您有未解决的问题，请告诉我。）

如果您想学习如何使用敏捷和精益交付您的客户想要的东西，请参加下一个产品负责人研讨会 。

翻译自: https://www.javacodegeeks.com/2016/06/product-owners-learning-part-4.html