在 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 日登陆深圳，将“多团队麻利协同”基因内化在研发流程中，为规模化晋升研发效力保驾护航！!🏰⛴公众号回复“乌托邦”可加入