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

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

  • 你的产品待办列表中有多少项工作?
  • 其中最早的待办事项是什么时候创建的?
  • 你和 Scrum 团队多久会维护一次列表中那些从没进过迭代的「钉子户」事项?

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

  • 产品待办列表中有 450 个待办事项;
  • 最早的一项在三年零七个月前创建;
  • 至少有 100 个事项被完善和评估,却从未被规划进迭代。

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

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

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

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

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

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

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

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

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

  • 让事项在产品待办列表中呆了很多年?
  • 不敢删除任何待办事项,唯恐惹恼干系人?
  • 同开发人员一起浪费大量时间处理一些永远不被排进迭代的需求?

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

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

02 大胆地删除产品待办事项

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

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

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

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

  • 阅读整个产品待办列表;
  • 接触关键干系人,了解每个事项背后的需求;
  • 结合交流结果,丰富产品待办事项;
  • 确定事项优先级,为产品待办列表排序。

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

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

现在,我会先做这些事:

  • 理解产品战略;
  • 清理/删掉产品待办列表;
  • 定义要验证的假设;
  • 创建与战略相关的事项,重建列表。

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

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

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

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

03 没有冲突,敏捷就枯萎了

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

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

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

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

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

# LigaAI 总结

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

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

(原文作者为 David Pereira,内容经 LigaAI 翻译整理。)

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

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

相关推荐
叶修_A15 小时前
FS-17 功能安全ISO26262之敏捷开发融合深度解析
敏捷开发·autosar·汽车电子·功能安全·iso26262
腻害兔20 小时前
【若依项目-产品经理视角】RuoYi-Vue-Pro 源码拆解:ERP 企业资源模块,一个轻量级进销存的完整实现?
前端·javascript·vue.js·人工智能·前端框架·产品经理·ai编程
zzzzzz31021 小时前
当用户说「帮我用AI写个淘宝」时,我在想什么——一个独立开发者的 AI 时代奇葩需求大赏
人工智能·程序员·产品经理
腻害兔1 天前
【若依项目-产品经理视角】RuoYi-Vue-Pro 源码拆解:字典、短信、邮件、通知——后台系统的“基础设施四件套“!
java·前端·vue.js·产品经理·ai编程
腻害兔1 天前
【若依项目-产品经理视角】RuoYi-Vue-Pro 源码拆解:支付模块 yudao-module-pay,一个让产品经理都看懂的支付中台设计
java·前端·vue.js·产品经理·ai编程
腻害兔3 天前
【若依项目-产品经理视角】深度拆解 RuoYi-Vue-Pro 认证与权限:RBAC + 数据权限,这套“门禁系统“到底怎么设计的?
java·vue.js·人工智能·产品经理·ai编程
领麦微红外4 天前
FW-D1 vs 迈来芯MLX90614:参数全面对比
人工智能·产品经理
怕浪猫4 天前
不过是做了几年产品经理罢了,我高估了自己
产品经理·产品·资讯
腻害兔4 天前
【若依项目-产品经理视角】深度拆解 RuoYi-Vue-Pro 框架层:15 个 Starter 到底在干什么?
前端·vue.js·产品经理·ai编程
sunneo4 天前
S18.4AI产品留存与召回——让用户走了还回来(系列收官)
人工智能·产品运营·产品经理·用户运营·用户体验