设定和使用产品目标：一个政府数字团队的经验教训
本文描述的是多个真实情境的综合，已修改可识别细节。该团队是省级政府内的一个数字服务单位，负责为一个福利管理项目构建在线门户。六名开发人员，一名产品负责人，一名Scrum Master。他们运行Scrum已有八个月。团队能力过硬，Scrum活动运转顺畅。但每次Sprint评审会都会产生一个Scrum Master无法准确说明的隐忧：每个Sprint完成的工作感觉互不相连。没有人能简洁地解释这个产品是为了什么——现在、在这个阶段、有这些资源。
产品目标解决了什么问题
"产品目标是Scrum团队的长期目标。在Scrum团队承接另一个产品目标之前，当前的产品目标必须被达成——或被放弃。"2020年Scrum指南中的这句话，精确描述了团队所缺少的。没有产品目标，来自各方干系人的每项请求都被用"这是个好主意吗？"而非"这是否服务于我们当前的目标？"来评估。产品负责人在合适的时间接受来自合理之人的合理工作，而产品在悄悄漂移。
引入产品目标后发生了什么
产品负责人与Scrum Master和项目主任共同起草了当前阶段的产品目标："使福利申请人能够在线完成并提交资格认定，无需电话或当面拜访，目标在2022年第二季度末实现。"这个目标具体、以成果为导向、有时间限制。
产品目标作为与产品Backlog相关联的承诺被添加进来。Backlog中的每个条目都被评估：它是否服务于产品目标？不服务于当前目标的条目被移到单独的"未来考虑"区块。
当那位想要通知模块的高管再次提出请求时，产品负责人能够进行不同的对话："这是一个有价值的功能。它不在我们当前产品目标的范围内，当前目标聚焦于资格提交。我可以将它放入Backlog，在下一阶段标记优先考虑。"高管接受了。他没有被拒绝，而是被告知"暂时不行"，并附有理由。
团队开始不仅仅通过条目是否完成来衡量Sprint成功，还通过是否达成了明确支持产品目标的Sprint目标来衡量。
到第二季度末，资格提交功能上线了。团队第一次实现了产品目标。接下来一季度，通知模块成为第二阶段新产品目标的第一个条目。
经验教训
产品目标不是项目计划。 它是给团队提供方向和过滤器的中期目标，不规定目标如何实现——那是Sprint目标和Sprint Backlog的职责。
产品目标使产品负责人能够说"暂时不行"。 没有产品目标，每位干系人的请求都被单独评估其价值，好主意挤占了目标空间。有了产品目标，产品负责人就有了可阐述的理由来推迟不服务于当前目标的工作。
Scrum工件有承诺是有原因的。 产品Backlog的承诺是产品目标；Sprint Backlog的承诺是Sprint目标；增量的承诺是完成定义。这些承诺使工件成为规划工具，而非清单。
XNM协助公共部门及资本项目组织建立有效的Scrum和敏捷交付实践，包括产品目标设定和产品Backlog管理。欢迎联系XNM项目群与项目交付咨询团队，获取敏捷项目群支持。