为什么PO的角色在Scrum框架中不可替代|ShineScrum认证

尽管我们口头倡导人人都是产品经理，2019年Mike Cohn的blog"是时候取消Scrum的产品负责人角色了吗"(Is It Time to Do Away with Scrum's Product Owner Role？)，引来不少的热点和争议。我一直坚信PO这个角色在Scrum中是不可缺失的。

2014年我有幸在波士顿参加Jeff Sutherland的CSPO课程，惊奇的发现一个班级人数达到30多人。后来细一探究，多数学员是学了CSM课程，在企业实践Scrum 以后，发现PO是一个重要的领导力角色，CSM学员又回过头来学习PO的课程。

在国内，CSM已经得到认可，是一个基础和核心的Scrum课程；但CSPO的课程却不温不火，可能是CSPO课程没有硬性的考试？(尽管我多次建议Scrum联盟增加考试)，或是国内有NPDP的认证？原因不得而知。不管怎么说，PO这个角色在Scrum 的执行过程中是至关重要的。今年我立了一个小小的目标，通过努力，能认证和辅导100位CSPO公开课学员，有多方面的原因。

2000年9月我开始做工程师，敲代码，当时我的觉察是做产品经理才有前途，对自己未来职业规划的重要一步要接触产品。当时我在波士顿工作，外面市场上公开招聘产品经理的职位很少。通过观察我发现，要想转型成为产品经理，有两条路可走，公司内部转岗High-Tech产品经理(技术背景的产品经理)，英文要求不高，或者去读MBA，我选择了后者，2002-2004年我自费5万多美金去读MBA，学到了如何写Business Plan，Marketing Plan，3到5年财报的预测，其实都是在做乘法、做假设。教授并没有教你如何去做实验验证这些假设，以降低风险；如何做MVP，找到早期客户，占有市场。跨出0到1这一步是最艰难的。我经常半开玩笑，CSPO课程相当于一个Mini-MBA课程，尽管只有两天时间，投资回报远远高于MBA。

PO是一个全职的岗位，有别于传统的产品经理，PO更像一个创业型的领导，她在投资一个个Sprint和团队；PO把项目经理的部分职责，产品经理，干系人的利益，客户的声音整合在一个人身上，面对复杂多变的环境，PO被充分授权快速做决定。所以PO是一个人，而不是一个委员会或小组。PO一个人不是意味要独裁，而是要持续地与干系人和开发团队沟通和谈判，做出最经济的决定。

在培训和咨询中，接触的企业实际情况是，要么有一个戴PO这顶帽子的人，但实际上只是一个Title，PO的行为和工作方式还是传统的，PO不是一位正确的人(A Right Person)来担当这个责任，PO的8个反模式(下图)；要么就根本没有PO这个角色，团队面对多个业务口的对接，有时候SM兼任PO。

组织中，识别和培养一个PO是管理者一项非常重要的工作。顾名思义，PO是产品负责人，产品的成功失败必须要有一个人来买单，否则就是没有人对结果负责。

PO要有相应的权利：

1. 有独立的权威决定Why和What(正确的产品目标和需求)

2. 决定产品待办列表的内容(Scope)

3. 发布的时间和范围权衡

4. 对产品待办列表的排序

5. 有权中止Sprint

权利和责任是对等的，我们在谈论责任(Responsibility)的同时，要看看是否给与了相应的权利(Rights)。

如果从精益的角度开发产品，我们遵循下面的原则：

1. 按产品指定价值

2. 识别每个产品的价值流

3. 让价值无间断地流动

4. 通过戴明的Plan-Do-Check-Act环追求持续改进

从敏捷产品的视角，我总结了下面10条，我们在CSPO课堂上一起解读和操练。

PO的工作是围绕一个关键词"价值"展开的，她的使命是最大化开发团队和产品的价值，其中一个最为重要的职责是对产品待办列表条目的排序。排优先级是每个企业面临的一项艰难的决定，每每听到业务和研发有这样的对话："每个需求都很重要"，"这些功能我都要"。不排优先级实际上是不做决定的表现。哪些先做，哪些后做，哪些不做，必须有一个人拍板，不做决定实际上是没有关注价值的表现。当然做决定的人要有担当对做的决定带来的后果和影响负责。

CSPO课程是一个产品探索(Discovery)的过程, 一个从零到一的创造产品价值的学习体验。课堂上让大家体验使用有效的工具和技能与干系人开发团队成员围绕"价值"共创，不是单纯的理论讲解，大大小小的练习一共设计了15个。

（1）产品愿景和目标

为什么要有愿景？什么是一个好的产品愿景？通过产品Vision Box练习针对一个产品想法头脑风暴，分组自选一个产品想法，然后使用Moore Statement模板帮助我们一起梳理和精化产品愿景。愿景是不变的，目标是实现愿景的可执行步骤。围绕目标我们对产品增量和流程(包括工作方式)检视和调整，优化和改进。

（2）产品策略，引入Scrum双轨制的概念，重点放在用什么工具一起挖掘和设计MVP的实例。业务的假设有：

学员一起使用实验画布去设计针对一个产品大的MVP或实验，PO引导大家对产品策略探讨和对话。特别关注风险和假设，设计成本最低的可行实验(Lowest Cost Viable Experiment)来测试产品想法，比如Video MVP，众筹或Pre-order。

什么是MVP？如何定义MVP？这是大多数学员的疑问。针对MVP我们进行进一步的讨论，重点讨论MVP的核心是什么，在软件产品和硬件产品中探索不同的MVP的设计和实验，MVP(Minimum Viable Product)最小可行产品的实验，用于快速验证市场的接受度，MVP的目的是为了学习，帮助产品决策。失败和学习的本质区别在哪里。同时引入了两个新概念MMP与MMF。

（3）价值定义和有效的创造价值

我们用价值主张画布和用户画像两个工具去识别用户和真正的需求(痛点和问题)，然后以用户故事的形式去描述用户需求和价值，强调Who/What/Why。实际演练以用户故事作为PBI构建最初的产品待办列表雏形，展开对"价值"的对话和评估，真正理解用户和客户的需要(Need)而非需求文档(Requirement)，用户故事工作坊书写。用户的一些假设有：

• 用户是谁？

• 我们的产品在他们的工作或生活中如何定位(Fit)？

• 我们的产品解决了什么问题？

• 我们的产品何时以及如何使用？

• 哪些功能很重要？

• 我们的产品外观和行为应该如何?

（4）识别最小的MMP，故事地图

在Scrum中没有明确给出发布计划的活动，对开发团队来看，产品待办列表只见树木不见森林，团队可能会局限在只关注一个Sprint的工作内容。作为PO，需要在项目启动阶段或产品探索阶段让团队看到一个整体的画面(A Whole Picture)，让每个团队成员意识到所有的工作都是价值驱动，用户故事地图正好起到了这样的功效，由一维的产品待办列表变成了二维的发布计划版本的横线切分(见下图)。

在Sprint 1启动之前，PO邀请相关的干系人和开发团队一起探索和讨论产品的需求，范围管理和控制，展开积极的对话，增加沟通的效率，建立相互信任。故事地图最小MMP的识别非常有帮助。MMP(Minimum Marketable Product)是验证后的最小可发布的产品，MVP1+MVP2+…+MVPn=MMP，目标是抢占市场窗口，尽早地获取到客户真实反馈指导我们产品增量的下一步规划和发布。客户买的是特性，MMP是最小的MMF(Minimum Marketable Feature)特性集合，也就是最少的经济合理的，最小可发布特性实现产品的独特核心价值，即满足发布目标。敏捷产品探索和开发就是用更快的速度、更少的成本，做更好的产品，Speed is everything。

在线课程，你会有意想不到的收获。做Story Mapping练习，大家先讨论与完成Backbone，各自静默书写，创建卡片，对产品功能一步步进行扩展。你会发现，通过这个练习，整个产品的架构浮现出来了。

（5）敏捷产品路线图

在产品愿景和产品待办列表之间缺失一个东西，那就是产品路线图，敏捷产品路线图不同于传统的项目里程碑，它是一个活的文档，旨在回答下列有关产品战略的几个问题：