产品管理经验分享：删掉 500 个产品待办事项后，我逃离了「假敏捷」

文章开始之前，我想先请大家思考几个问题：

我第一次问自己时，得到的答案是这样的：

我开始反思产品待办列表（Product Backlog）和产品待办事项（Product Backlog Item）的奇怪现象，随后确定了一件事情：我没有理解「敏捷」的真正含义。

现在我将与你分享，为什么清理（甚至删除）产品待办列表可能让你拥抱更自由的敏捷。

01 笨重的产品待办列表是敏捷的劲敌

你能立刻说出「敏捷」的含义吗？

一千个人眼中有一千个哈姆雷特，而我的理解是：敏捷要更快地向用户和业务提供价值。

对于抽象的「价值」，大家或许也会有不同的解读。于我而言，「提供价值」意味着在帮助用户解决问题的同时，为业务带来回报。

从容地面对未知是践行敏捷的关键。

追本溯源，敏捷强调拥抱变化，在变化中学习。我们应该简单地创建假设、验证假设、学习、检查并调整。这听上去并不复杂，但不知何故，很多人都把它变得无比复杂，包括我自己。

庞大的、笨重的产品待办列表恰恰是敏捷的反面。我猜你可能会反驳说自己很敏捷，但你是不是

我认为，任何有超过三个迭代工作量的产品待办列表都是笨重的。如果产品待办事项的数量比 Scrum 团队几个迭代的工作量还要多，那就说明团队当前「拥抱计划 > 拥抱变化」。那这到底是敏捷呢？还是瀑布呢？

要想实现价值，就必须维护一个精益的产品待办列表。不要被计划的假象所迷惑。

作为一名产品负责人，再没有什么比笨重的产品待办列表更能让我恐慌了。无条件地向利益相关者承诺交付，美其名曰「客户至上」；但事实上，在现存的所有产品待办事项中，有近乎一半的承诺难以兑现——它们始终在待办列表中占有一席之地，被「计划中」完美掩护。产品负责人换了一个又一个，它们却一直没有被交付和满足。

一个无限制的、庞大而笨重的待办清单让我们永远无法兑现所有的承诺。这也是一种无法持续管理产品待办事项的坏方法。

不要用「把需求放进产品待办列表」的方式，愚弄利益相关者。

我先后在多个组织担任过产品负责人，在很长的一段时间里，我都在以一种低效的、甚至可以说是毫无意义的方式适应新工作。我之前的做法是：

这样做的结果是，我浪费了大量的时间，还给自己带来了更多来自不同干系人的压力。每个人都急切地想要一些东西，但没人愿意把自己的需求从产品待办列表中删除。

这是一个很常见的错误：让利益相关者掌握主动权，而不是自己把控产品方向。

现在，我会先做这些事：

你一定在想：把产品待办列表删掉也太激进了！

是的，你说得对。但是，为了更快地交付价值，我们必须采用非常规的，乃至极端的办法。除非能消除所有干扰，否则你没有时间去做最重要的事。

我删掉了利益相关者想要的需求，他们会生气吗？肯定会啦，但是这跟他们发现产品无法达到预期而发的脾气可没法比。

再说一个秘密吧：我曾经一次性删掉了大约 500 个产品待办事项，最后只有 2 位利益相关者向我提出了疑问，而其他人没有任何反馈。我的经验是，如果你申请删除某个事项，大概率会被拒绝；但如果愿意冒一次险，那你可能会收获意外之喜。

做对产品有利的事情很难不惹人生气。因为我们无法通过取悦所有人，更快地交付价值。正确地做产品一定需要面对冲突和压力，而处理冲突的能力又将决定我们是否是合格的产品负责人。

同生活中的任何事情一样，短期利好很可能是靠牺牲长期利益实现的。

如果产品待办列表能完美地符合利益相关者的期望，他们会在一开始时非常高兴，但久而久之逐渐失望，因为团队无法实现他们的预期。如若在最开始就选择那条艰难的路，选择拥抱冲突来实现承诺，那你将可以带领 Scrum 团队交付价值，而不是陷入 WaterScrumFall 的错误模式。

为了确保自己不会陷入「有效性错觉」，请每 3 个月清理一次产品待办列表，为新事物腾出空间，让噪音消失；也为 Scrum 团队留出时间复盘学习成果，评估当前的目标和意义，重新开始。

最后，有效性错觉和技能错觉是由一种强大的专业文化来支撑的。我们知道，在任何情况下，当身边的人都跟自己持同样的想法时，不论这种想法有多么荒唐，人们都能保持一种不可动摇的信念。——《思考，快与慢》，丹尼尔·卡尼曼

敏捷强调要拥抱变化，拥抱学习。无限制的、笨重的产品待办列表会使组织无法快速响应变化，而无法如约交付承诺也会让利益相关者越行越远。

定期清理产品待办列表，维护组织价值交付的敏捷性，始终关注最重要的事情，才能让企业和组织保持活力，一往无前。

（原文作者为 David Pereira，内容经 LigaAI 翻译整理。）

LigaAI@SegmentFault 还将分享更多产品管理、研发提效等干货内容，欢迎关注我们。

助力研发团队扬帆远航，点击体验新一代智能研发协作，一起变大变强！