当产品负责人无法说“不”时
这是一个合成场景，团队和人物均为虚构，用以说明我们常见的一种模式。一支分布式Scrum团队在2021年春天刚刚转为居家办公，《Scrum指南》要求的一切它都具备：一位产品负责人、一位Scrum Master、若干开发人员、一份产品待办列表，以及各项事件。纸面上堪称范本。可实际上，冲刺总是以做了一半的工作收场，待办列表每隔几天就变一次样。诊断花了一段时间，因为问题在任何单一事件中都看不出来。它藏在“究竟由谁来决定什么”里。
症状
团队的产品负责人，姑且叫她Dana，认真负责且广受喜爱。但每一个有关优先级的重要决定都绕过了她。一位高级总监会直接给某位开发人员发去一项“紧急”请求。一位干系人会在私下交谈中重排待办列表。Dana撰写待办事项、主持评审，却无法对任何人说“不”，于是待办列表反映的是最近找过团队的那个人，而非最有价值的东西。团队很忙，却原地踏步。
《Scrum指南》到底怎么说
《Scrum指南》讲得很清楚：产品负责人对最大化产品价值负责，并且是一个人，而非一个委员会。尤为关键的是，它指出，要让产品负责人取得成功，整个组织都必须尊重其决定。这些决定体现在产品待办列表及其条目的排序中。整个组织可以尝试通过说服产品负责人来改变待办列表——但要通过她，而不是绕过她。Dana有责任却无权力，这正是该角色最常见的失败方式。
改变了什么
解决之道在于组织，而非流程。归结为几个具体动作。
一份待办列表，一位负责人。 每一项请求——无论提出者职位多高——都汇到Dana处，并体现在唯一的产品待办列表中。不再有通向开发人员的私下渠道。
让决定可见。 待办列表的排序成为优先级的公开记录。若某位干系人想让某事更早完成，就向Dana陈情，而取舍是明确的：必有别的事项往下挪。
管理层公开为她撑腰。 出资的总监用明白的话告诉干系人群体：除非有人说服Dana，否则她的排序为准。这一句话比任何流程变更都管用。
她开始说“不”，并给出理由。 真正的产品负责人拒绝的远多于接受的。Dana开始解释某个事项为何处在那个位置，由此建立起信任，让人们不再绕过她。
几个冲刺之内，待办列表稳定了下来，冲刺完成了它们开始的工作，持续的反复也随之消退。技术和团队技能都没有任何变化。变的是终于允许一个人来决定，而组织也同意接受她的决定。一个无法说“不”的产品负责人不是产品负责人，而是替所有其他人记录优先级的文书。
如果你的交付团队有Scrum角色，却没有与之相称的权力，XNM的项目集与项目交付咨询服务可以帮你把真正的决策权放到责任已经所在之处。