[Day09] 团队系统设计 - PO 系统

上篇文章中，我提出了一个「规画系统」，其系统的起始点，是由 PO 与 Designer 组成的子系统。我见过大部分的 Product Owner 通常还身兼 Project Manager，或是 Job Manager，从接收需求开始，到协调设计师出 UI/UX 规格，到开发阶段的任务分派与进度追踨，全包了。我一方面对这个角色充满敬佩，一方面也在大部分的 Product Owner 身上观察到了强大的内部张力，可以说是整个团队中，张力-舒缓系统运作的最频繁的角色。

"PO 的任务，是让产品赚钱。"

而身为团队系统架构师的职责，就是帮助 PO 回归本务：产品设计、用户研究与数据追踪。与 PO 取得共识是整个系统的成败关键，因为扛着营收的压力，在无法完全掌握团队状态的情况下，PO 会极度的缺乏安全感。而唯有 PO 信任团队，才能真正的建立安全感。

我帮助团队与 PO 建立互信的过程与策略如下：

1. 沟通目标
承诺 PO 建立一个可以量化的观测专案进度的开发系统，观测的方式不再需要透过口头询问，而是由团队主动提供资讯。PO 可以最大程度的控管风险。在双方的协作下，PO 的日常工作负担可以大幅度的减轻。

2. 梳理 Product Backlog

在到达目标前，PO 必须提供的协助为：

• 良好结构的 Product Backlog
  待办清单中的任务有明确的阶层结构，如 Epics → Stories，再由 RD 负责将规模较大的 Story ，拆分成颗粒 度较小的 Tasks； 结合估点系统的运作，PO 可以很轻易的掌握每个 Epic / Story 需要的开发资源(时间与人 力) 。以往，产品甘特图可能来自 PO 的经验估算，尔後是一个具有信心度的估算结果。
• 针对商业价值对 Backlog 进行排序
  确保开发团队在进行当下最重要的开发工作，任何插件的原则都必须先进行价值判断
• 明确的验收条件

3. 改善估点系统
估点是一门学问。我常听到 Scrum 团队成员提到自家最秏时的活动就是估点，不仅效率差，参考价值也低。原因在於常见的「扑克估点法」「Fibonacci 估点」等实践方式，带给团队很大的内部张力，如讨论时间太长、不同领域的开发者互相投点、点数如何时时间挂勾等因素。因此，我介绍了一种变型的估点系统。让 PO 了解，这次不同。
有关我提出的估点系统，之後会有专文介绍。

4. 建立进度回报机制
在每日的站立会议，PO 可以不用再询问推进进度，让团队专注在「遇到的问题」「需要的协助」等重要事项。而所谓的进度回报，则是透过培养团队每日更新点数的习惯，由专案管理工具获取资讯。
这里的重点不是工具，而是培养团队的习惯。资讯流不应透过任何一个「人」当作结点，而是应该创造一个结构，让它自然流动。但是当团队规模较大时，例如我带过 20 人的 Scrum 团队 (完全违反了 Scrum Guide 的精神)，工具也确实会带来效率的提升。
有关我如何透过设计 Scrum 工具，来优化这个庞大团队的经验，留待之後的文章再来聊。

5. 辅导转型期
此时的 PO 一定处在将信将疑的状况，经验带来信念，只有让团队有了好的经验，接下来的系统化运作才能顺畅。因此，规画好的步骤与执行，在初期需要 Scrum Master 跟紧一些。例如，承诺让 PO 会拿到的资讯， Scrum Master 必须使命必达，即使团队还没完成养成习惯，也必须想办法提供。让 PO 的讯息流简化到单一窗口，再逐步进化到由团队主动提供。

PO 系统的修正，可以说是一个与开发团队解藕合的过程，让 PO 去做最重要的事，才符合整个团队的利益。下一篇文章，我们来聊聊 Refinement 的实践方式，明天见！