如果不加注意,产品backlog 就可能变得很庞大且不易维护。通常的做法是经常回顾backlog,然后剔除掉那些团队永远都不准备做的条目。 Neil Killick 从其他方面质疑了该方法管理需求的有效性.
据 Neil 所述:
- 它阻碍了创新
- 它可能使得产品的整体愿景打折
- 它制造了“需求黑洞”
- 它会产生维护费用(无效的成本)
- 庞大的列表 = 高循环次数
- 让 PO(Product Owner,产品负责人)更难理解依赖关系
- 让 PO 变成了确定需求顺序和优先级的角色
为什么会说这个方法阻碍了创新,Neil 谈到了更多的细节:
基于提前写好的文档开发产品时,也面临相同的问题——在产品实现过程中不会促进产品创新。如果把要做的事情写在了 backlog 中,那么人们就会假定它是合理的,就会认为写这个需求的人大概是花时间思考过为什么要把它排在 backlog 中。所以,产品负责人和团队就会产生一种倾向,他们就会想照着这个产品“它应该的样子”来构建这款产品,照这样做也不会把事情搞砸。
许多公司会提前计划好 4 个、5 个、6 个甚至更多个迭代,并且在各个迭代中排列好要做的“用户故事”,完全忽略了如何做创新。
Todd Charron强调,当产品 backlog 开始没法管理时,并不是说得去找一款更复杂的敏捷产品管理工具。他重点提到:
你需要的不是更好的 backlog 管理工具,而是一份内容更少的 backlog。
Roman Pichler谈到了产品 backlog 的动态特性,认为应该把产品 backlog 当作一个学习工具,而不是僵化、一成不变的东西。
因此,我们应该假设产品 backlog 有待验证,并需要通过客户和用户的反馈来细化。
RomanRoman 还提供了一些工具用来代替产品backlog,其中有一款工具叫 product canvas 。你在处理产品 backlog 时,注意过有类似的问题存在吗?你试过哪些代替它的方法?
评论