如何成为一个搞死敏捷团队的产品负责人PO

在Scrum当中，没有其他角色像产品负责人（PO）那样，能够对团队的结果产生如此大的影响，他甚至能决定团队交付产出的到底是黄金还是垃圾。而且，PO可以说是该产品的“迷你CEO”，有单独做决策的权力。Scrum是一项团队运动，在成功的Scrum团队中，合作性和一致性是成功的先决条件，PO也不是独行侠。

倾向于单独做决策的PO，会把注意力放在我方的解决方案上，而不是关注客户的问题。因此，在团队中与团队成员就产品目标、产品待办列表进行对齐与讨论，是PO带领降低产品风险的关键策略。这也是Scrum的内置制衡机制，我们也可以看到现在市场上对于产品运营模型的关注是越来越多。

PO并不只是管理产品待办列表，而是创造透明一致性的参与者环境

根据Scrum指南，我们可以看到描述了产品负责人的工作如下：

• 从Scrum团队的工作中最大化产品的价值。
• 明确、建设、沟通该产品目标。
• 管理产品待办列表，即使部分委托他人，也要保持最终负责。
• 与利益干系人沟通，并作为代表澄清产品待办列表中的需求。
• 确保产品待办列表是透明的、可见的，并且被团队所理解。
• 对产品待办列表条目进行排序。
• 为Sprint制定目标。
• 若Sprint目标变得过时，PO有权中止Sprint。

大多数PO实践过程中的失败原因，往往是源于对产品待办列表管理方面的误解，这是PO责任的核心。特别是不太成功的PO，经常未能与团队成员、利益干系人沟通。从客户的角度出发，最大化Scrum团队的工作价值，同时在给定的约束条件下为组织的利润做出贡献，不仅仅是项目管理技能的问题，也不是处理产品需求文档或保持Jira更新的问题。

因此，成功的PO在处理产品待办列表上花费的时间较少，而更多地投入到产品探索中，特别是创造所有参与者之间的一致性。对他们来说，产品待办列表是手段，而不是工件存在的目的。

相反，成功的PO花费时间创建一个透明的系统，让他们能够从所有来源识别潜在有价值的想法，不懈地沟通“为什么”和与开发人员合作“做什么”。

产品待办列表和梳理细化的反模式

我们经常在产品待办列表，及其梳理细化中，发现许多PO的反模式（失败原因）：

• 存储想法：PO将产品待办列表作为想法和需求的存储库。
• 兼职的PO：PO不是每天都在产品待办事项列表上工作。
• 复制粘贴PO：PO通过将从利益干系人那里收到的需求文档分解成更小的块来创建产品待办列表条目。
• 主导型PO：PO创建产品待办事项列表项时，不仅提供“为什么”，还提供了“怎么做”和“做什么”。
• 代理优先级：会给某单个利益干系人、利益相关者委员会，在产品待办列表中优先排序他的内容。
• 100%提前：Scrum团队预先创建了一个涵盖整个项目或产品的待办列表。
• 超大型：产品待办列表包含的条目，超过了Scrum团队在三到六个Sprint内可以交付的数量。
• 过时问题：产品待办列表包含过去几周或更长时间内，不被触及（提及）的条目内容。
• 全部详细和估算：所有产品待办列表条目都被完全详细地进行描述和估算。
• 基于组件的项：产品待办列表条目是基于组件水平分割，而不是基于端到端功能的垂直分割。
• 缺少验收标准：有些产品待办列表条目需要额外的验收标准，但没有列出它们。
• 不超过标题：产品待办列表包含的条目，仅包含了标题。
• 用户故事作者：PO在创建产品待办列表条目时，前期投入了太多时间，使它们过于详细。
• 没有研究：产品待办列表中很少有甚至没有，利用Spike、Sprint进行研究和学习的任务。
• 涉及Scrum团队——为什么：PO没有让整个Scrum团队参与产品待办列表细化过程。

Sprint计划的反模式

Sprint计划的反模式

PO反模式（失败原因）列表中的第二大领域，是Sprint计划本身：

• 我们为什么而战？：PO无法将即将到来的Sprint的业务目标与产品目标和整体产品愿景对齐。
• 没有业务目标，没有Sprint目标，只是随机事项：PO提出的方向类似于随机任务的组合，没有目标方向。
• 未完成的业务：上一个Sprint中未完成的用户故事和其他任务未经讨论就流入新的Sprint。
• 最后一刻变化：PO试图在最后一刻加入一些未经细化的产品待办列表条目。
• 输出焦点：PO推动开发人员承担比他们实际能处理的更多任务。

Sprint的反模式

另一个容易出现PO反模式（失败原因）的领域是Sprint冲刺：

• 缺席PO：PO在Sprint的大部分时间里缺席，无法回答开发人员的问题。
• 坚持任务的PO：PO一旦产品待办列表条目成为Sprint待办列表的一部分，就无法放手（丢弃）。
• 不灵活的PO：PO不灵活地调整验收标准。
• 延迟PO：PO没有在Sprint待办列表项完成后立即提供反馈。
• Sprint填充：开发人员提前完成了Sprint目标，PO强烈推动他们接受产品待办列表中的新工作以填补“空白”。
• 未经协商取消Sprint：PO未经与Scrum团队协商就取消Sprint。
• 不取消Sprint：PO不取消Sprint，但其Sprint目标不再可实现或已过时。

每日Scrum的反模式

我们观察到，与其他Scrum事件相比，每日Scrum对PO反模式的抵抗力较强，但仍然容易有以下问题：

• 分配：PO直接向团队成员分配任务。
• 额外工作：PO甚至其他利益干系人试图在每日Scrum期间，引入新工作至当前Sprint。

Sprint评审反模式

最后，还有Sprint评审。尽管这是PO、利益干系人、开发人员改善合作并共同确定产品下一步方向的绝佳机会，但某些PO还是没有领会到这一点：

• 自私的PO：PO向利益干系人展示“他们”的成就。
• PO的“接受”：PO在Sprint评审中“接受”开发人员认为“完成”的产品待办列表条目。
• 不易接近的PO：PO不接受利益干系人或开发人员的反馈。

小结

在Scrum模型中，产品负责人角色是模型中最具挑战性的角色，是价值创造的关键，因为他们决定Scrum团队的下一步方向。幸好的是，即使在具有挑战性的产品负责人角色中，总有改进的空间。这份产品负责人反模式列表可以作为成长和发展的起点。

若你还观察到了哪些不在列表中的产品负责人PO反模式？可与我们联系并分享。