当待办列表说谎：一个硬件团队关于按价值排序的教训
2021年春天，一个我称之为Northgate的产品团队正在经历艰难的一年后重整旗鼓。团队半数远程办公，一家关键供应商对一块控制板仍报出十二周的交期，而产品负责人手上的待办列表有140个条目。表面上他们在做Scrum，实际上这个待办列表的顺序是历史的偶然：谁最近提交了请求，或在上次评审中争得最凶，谁就排在了前面。
《Scrum指南》对此毫不含糊。产品待办列表是一份有序清单，产品负责人对这一排序负责。有序不是指按日期、按工作量或按谁嗓门大来排，而是指排出顺序，使最可能交付价值的工作排在前面。Northgate跳过了这项纪律，代价就是浪费了多个冲刺。
混乱如何显现
症状很常见。冲刺结束时堆着一批没有客户要求的「已完成」条目，而三笔销售交易都在等的一个功能却排在第47位。团队不断切换上下文，因为待办列表顶部没有连贯的主题。由于受供应中断影响的控制板阻塞了一条硬件路径，所有依赖它的工作本应下移——但没人挪动，于是团队不断在半启动的工作上磕绊。
当我们和产品负责人坐下来时，真正的问题很快浮现。她是按请求排序，而非按价值。每一项干系人请求都大致按到达顺序加入堆栈，而「优先级」只是人们贴在自己条目上的标签，并非整张清单的属性。
有意识地按价值重新排序
我们没有引入一套笨重的评分框架。团队需要的是能在每次梳理会上运行、无需电子表格仪式的东西。我们用来比较任意两个待办条目的问题简单而具体：
这能释放什么价值，对谁释放？ 一项营收承诺、一个监管期限、一个阻止客户流失的修复——这些都胜过一次整洁的内部重构，无论后者多么令人满意。
等待要付出什么代价？ 有些条目随时间变得更便宜或更紧迫。受供应影响的控制板工作因交期不断推迟，延误代价越来越高；而可有可无的报表则不会。
现在真的可做吗？ 一个被缺件或缺决策阻塞的条目无法排在最前，无论它多有价值。顺序既反映价值，也反映就绪程度。
它能降低风险或不确定性吗？ 把一项有风险的集成提前——哪怕排在它那些光鲜的功能之前——往往比再做一个安全的增量交付更多真实价值。
产品负责人保留了责任——排序归她所有——但她让排序透明化。前十个条目每个都有一行理由，全团队和干系人都能看到。仅此一项改变就终结了大部分走廊游说，因为请求插队如今必须针对一条明示的理由来争辩，而不是针对沉默。
两个冲刺后发生了什么
阻塞销售的功能在下个冲刺交付，而非继续漂移；待办列表终于反映了业务的真实需要。
被供应阻塞的工作下移，不再割裂冲刺，团队每个周期都保持连贯主题。
梳理变快了，因为按价值比较条目比重新争论谁先提出要快得多。
干系人更信任这个顺序，恰恰因为他们能看到背后的推理。
这些都不稀奇。这正是Scrum框架早已要求的日常纪律，被诚实地落实而已。待办列表不是一份按到达顺序排的任务清单；它是一份关于「接下来什么最重要」的鲜活陈述。当一个远程、受供应约束的团队把这份陈述做对，其余所有Scrum事件都会运转得更好——因为团队终于是在从一份有意义的清单顶端取活。
如果你的交付团队很忙碌，但工作的顺序已不再反映价值，XNM的项目群与项目交付咨询可以帮助你把真正的优先级排序重新放回交付方式的中心。