需要有代替产品backlog的方法吗？

如果不加注意，产品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时，注意过有类似的问题存在吗？你试过哪些代替它的方法？

\

查看英文原文：Do we need an alternative to the product backlog?