在Scurm框架下，Product Owner 是一个非常重要的角色，那么PO应该掌握的那些基本知识呢？下面通过7个方面进行简单的介绍。
1、“Project to Product”
我们先来对比一下项目思维和产品思维。项目思维模式“由内向外”定义了什么是成功，使用的内部衡量标准更多的是关于任务管理和初始计划的执行精度。产品思维方式是一种由外而内的方法，它通过外部衡量标准来指导产品的开发，以实现价值最大化。
客户看中的是什么？项目还是产品？组织的目标并非是交付项目，而是通过产品交付价值，这些产品最终会为组织带来更高的收益和更低的成本。产品出色客户群就会增长，现有的客户就能保留下来。所以忘掉项目吧。把创意当做一个产品来看待，然后将产品创意交给一个富有能力的团队，向他们介绍业务目标及其意义，如客户的满意度，让每个成员都深刻意识到，实现这些目标的唯一方法是尽快发布有价值的产品，并验证预先设计的商业假设。
总结来看，敏捷产品管理的特点：
- 鼓励频繁发布，尽早获取市场反馈
- 传达目标而不是任务；团队为他们的解决方案赋予更多的创造性，针对他们的计划拥有更多所有权
- 减少对任务分配、报告和管理决策的依赖，从而消除浪费
一个组织不论开发何种产品，都会制定不同层次的计划。由于形似洋葱，因此形象的称之为“洋葱圈计划”。
在大的组织目标和开发团队日常工作之间存在“鸿沟”，我们称之为“产品管理真空”。
产品的真空区越大就会导致产品的技术团队与业务就越分离、就越依赖项目和任务管理、层级和交接就越多、浪费和返工就越多等一系列的问题，最终会导致交付给客户的价值就越少。
真正的产品管理就是在整个组织中自上而下地实现敏捷能力，并因此消除产品管理真空。如果实施到位，则必将创造出真正的竞争优势
- 愿景：创造透明性。成功的PO应该为团队建立清晰的产品愿景
- 价值：用于确定要检视的内容
- 验证：为了进行最终验证并降低总体产品风险，必须与市场建立一个反馈环。因此，需要做的是尽可能的频繁发布
产品管理真空区是需要PO参与进来的地方，一个被授权并且具有创业精神的PO能够填补产品管理的真空。
2、Product Owner
Product Owner的特征如下：
- 担任该角色的是一个人
- 驱动产品成功
- 对于客户来说代表项目
- 对于项目来说代表客户
- 要与所有人共同协作
- 一般由客户或客户代表担任
- 在Sprint过程中作为不可或缺的团队成员
在了解了PO的特征以后，我们再来看一下Product Owner的使命：
- 创建产品愿景
- 定义产品特性
- 根据市场价值进行优先级排列
- 对投资回报率（ROI）负责
- 根据市场反馈调整产品特性和优先级
- 接受/拒绝工作成果
- 确保为迭代输入做好准备
PO必须权衡产品的多重属性：
如果只是把精力集中在自己能够制造的产品上，那么你的产品可能没人想要，即便你对这个产品充满热情也无济于事。如果你只是把精力集中在自己能卖掉的产品上，可能会给客户许下不切实际的诺言，承诺一个生产不出来的产品。如果你只是集中精力生产能卖掉、自己却没有热情的产品，那么你最后生产出来的产品可能流于平庸。
上图的中央区域，三方交回的位置，是最理想的，是建立在现实基础之上的美好前景，很可能创造卓越。
3、Product Version
Product Version（产品愿景）是指产品负责人对产品未来前景和方向的一个高度概括描述，它应符合公司或组织的战略目标。好的产品愿景能让项目团队了解产品的价值，建立共同的目标并激发团队士气。
Product Version 的工具一般包括：Product Box（产品包装盒）、Press Release（媒体发布会）、Elevator Pitch（电梯演讲）。其中比较常用的就是电梯演讲工具，在乘电梯的20秒内清晰准确的向客户解释清楚解决方案，这是麦肯锡公司检验其陈述报告的方法之一。电梯演讲梳理产品愿景的格式化结构如下：
- For (customer)【目标客户】,
- who (statement of need)【需求和机会】,
- the (product name) 【产品名称】is a (product category)【产品定位、类型】
- that (key benefit, compelling reason to buy).【关键优点和购买理由】
- Unlike（primary competitor)【主要竞争对手】,
- our product (statement of primary differentiation)【差异化声明，即杀手功能】.
为了有效地传播愿景并确保更好地理解和遵循愿景，还可以在团队的工作场所中想办法让愿景宣言随处可见。
4、Product Backlog
Product Backlog（后面简称PB）是指产品可能包括的功能的动态列表以及其他为用户提供价值的工作。一个健康的PB应该具备DEEP 特征：
- Detailed appropriately【详略得当】
- Estimated【做过估算的】
- Emergent【涌现的】
- Prioritised/ordered【排列优先级的】
PB向团队所有人开放，但归根结底由PO进行梳理，聚焦在What能给用户带来最大价值。
在PB中可以包含的内容：
- 功能需求
- 非功能需求
- Spike（探针/刺探）
- 技术债务
Spike可以作为一种研究性条目放在PB中，其目标是帮助获取某项功能在实现时所需要的更多信息。通常，Spike是对某项功能实现的一个非常简单的概念验证。Spike的最终目标是通过试验来降低风险，让我们能够更快的做出更好的产品决策。
提醒：Spike的危险在于可能像任何东西一样被滥用。例如：每一个Sprint都是以一个Spike故事结束，要明白，Spike对企业不尝试任何的直接价值。所以可以使用，但不要滥用。
PB常见的优先级排序法有：MoSCow、KANO、100 Dollars，感兴趣的可以查阅相关资料进一步了解。
5、Persona
Persona（用户画像）简单的说就是根据用户的目标、行为和观点给用户贴标签。将标签进行归类，然后赋予名字、照片、人物属性，然后代入场景进行简单描述，形成的一个人物角色。
用户画像的好处：
- 挖掘用户痛点：帮助团队更好地理解用户的特征和行为，从而更准确地判断他们面临的问题和真正的痛点
- 建立同理心：建立用户画像的作用，其实就是帮助建立同理心
- 有助于设计和决策：用户画像的本质上回答了一个问题，我们的产品在为谁服务？Ta代表了使用产品的半虚拟角色，帮助我们从新的角度看设计，发现盲点并促进设计决策
既然用户画像好处这么多，那我们如何构建用户画像呢？参考步骤如下图：
通过实践，经过团队的共同努力，打造如下图示例的用户画像，团队共创的过程也非常的重要。
完成用户画像后，应该如何使用它呢？
- 向团队介绍用户画像。花点时间介绍研究的过程，展示照片给他们看，聊一聊画像的需求，期望，痛点，性格等
- 在迭代计划会上使用用户画像。例如“运维会想要这个功能吗？我觉得这个可能会阻碍升级”
- 在你的用户故事中使用用户画像。“如果我是Fiona前台，我想要XXX，这样可以方便XX。”
- 设计时，花点时间想象一下软件会被用户在工作中如何应用。以上文为例，考虑如何找到远离电梯的房间，但关注是顾客，而非软件。
6、User Story
User Story （用户故事）的基本格式如下：
- As a [user role]【用户角色】
- I want to [accomplish a result]【完成一个目标】
- So that [I can get some business value] 【获得商业价值】
我们都知道用户故事的格式，但是在实践的过程中会发现，最后一个‘’so that”很难写，或者不需要拘泥于形式，所以有的团队干脆就直接就不写了，那么“so that”的重要性到底有多大呢？
- 价值信息传递：从大规模到小团队，价值信息是从上而下，逐层分解、细化而传递的。So that 承担的便是价值信息的载体。省略 So that意味着价值信息传送链断裂。
- 依据价值排列优先级：在敏捷的世界里敏捷世界里排序的依据之一为价值，"So that" 都不见了，排序的依据是否就会是 "感觉" "难易度" 了呢？
- 为预期效果提供度量方式：So that 表达的是外部价值，如 "So that 可以提升用户转化效率"。那么当用户故事上线后，我们就需要获取数据来验证，是否用户转化效率是否提升了？提升了多少？与预期是否发生偏差，偏差的愿意是什么。为下一步的改进提供依据。
- 为开发人员提供更多信息：避免实现的僵化。没有明确的外部价值的，可能导致开发人员在实现时，产生不同的行为。
7、Acceptance Criteria
在Sprint结束时，对于团队是否构建了产品所有者“想要”的特性，存在争议是很常见的。这些纠纷很浪费资源，而且往往会让PO和开发人员产生分歧。我们希望他们紧密合作，而不是互相争斗。
Acceptance Criteria （验收标准，简称AC）是在实践中非常重要的东西。主要是参考了ATDD（Acceptance Test Driven Development，验收测试驱动开发）实践。在准备实施一个功能或特性之前，首先团队需要定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员和测试人员。面向开发人员，强调如何实现系统以及如何检验。
AC采用Given/When/Then 格式：
- Given:[a pre-condition]【给定前提条件】
- When: [user inputs]【用户输入】
- Then:[user gets expected results]【用户得到预期结果】
AC的例子如下：
在实践的过程中，采用的是团队协作来完成AC的编写，那么由团队来写验收标准AC的8个理由如下：
可以帮助团队更深刻理解需求
- 边写可以边进行拆分
- 考虑设计，从what转换到how
- 提前识别技术依赖
- 估算更容易
- 尽量避免误判和过度承诺
- 解放PO，让PO去做更有价值的事
- PO和团队协作，更像一个团队
参考书籍和内容：
- [加拿大]唐·麦格里尔(Don McGreal) ;[德] 拉尔夫·乔查姆《产品负责人专业化修炼》
- Scrum中文网公众号文章《用户故事是否可以不写 "So that" ?》
- CSPO认证培训材料
作者：梁媛 首批FDCC认证学员
玩乐高，学敏捷，规模化敏捷联合作战沙盘之「乌托邦计划」，2022年3月5-6日登陆深圳，将“多团队敏捷协同”基因内化在研发流程中，为规模化提升研发效能保驾护航！!⛴公众号回复“乌托邦”可参加