产品待办事项列表是许多产品经理使用的一种理念管理工具。这是一个有组织的列表，包含需要完成的想法、任务和更新。如何组织、定义、评估和确定产品待办事项列表的优先级取决于产品负责人、产品经理或Scrum Master(每个团队都不一样)。
产品待办事项列表不仅仅是一个待办事项列表——它是你团队中一个活生生的成员，应该不断调整以适应公司不断变化的需求和优先级。
特别地，对backlog进行优先级排序是PM生命中最令人头痛的问题之一。你如何才能在有限的资金、时间和资源下完成所有这些功能请求和更新，同时解决bug修复和技术债务问题?这就需要一个可靠的积压优先级划分方法来挽救局面。
这对一个人来说太难了。但只要你找到一个可靠的优先级排序过程，这并不一定是一场噩梦。
我们收集了一些常见的backlog优先级划分失败(也称为反模式)，解释了为什么它们是一个问题，以及如何修复它们。
看看我们的图书馆35+路线图模板．通过注册一个免费Roa188金宝慱官网下载dmunk试用把它们变成你自己的。
Backlog优先级陷阱1
积压中的太多项目是不相关的，或者采购订单不知道它们是怎么进来的。
为什么这是个问题:你的待办事项不应该是一个记事本，让每个人都记下与你的产品相关的每个随机想法。它应该是一个直观的、有组织的、充满相关计划的存储库。
解决方案:有一个清晰的产品愿景——并确保每个人都遵循它(如果有必要，可以做一点清理工作)。
你可能会问自己:一个清晰的产品愿景和一个杂乱的产品backlog有什么关系?所有与我们交谈过的项目经理都强调了在做任何其他事情之前拥有一个清晰的产品愿景的重要性。当每个人都对产品愿景有了深刻的理解，并将其作为自己的指路明灯时，项目经理就可以确保正确的想法被制定出来并包含在待办事项列表中。
这是理想产品愿景的视觉分解图，正如罗曼·皮切勒所描述的：
一个好的产品愿景清楚地表达了你期望你的产品对你的客户和你的行业产生的长期影响(一个好的产品愿景还有很多，但那是另一篇文章的主题)。如果你的团队中没有人在筛选积压中的特性请求时不断考虑你的愿景，那么你的愿景也毫无意义。
对产品愿景有共同的理解是构建产品的关键(杰夫·巴顿在他的书中也提到了这一点，用户故事映射)．要做到这一点，最好的方法是召集你的团队，谈谈他们对愿景的看法。当你进行这些对话时，你的目标应该是让每个人都在同一页上。你可以通过进行优先级排序练习来做到这一点——就像我们下面将要描述的那样——鼓励每个人量化对公司有价值的东西。
Backlog优先级划分陷阱2:
基于PM的个人偏见或不相关的度量来确定优先级。
为什么这是个问题:在团队内部，当需要评估一个想法时，团队会感到失落或没有人倾听。在外部，你最终构建的功能并没有得到你预期的客户响应。
解决方案:使用一个2x2的优先级矩阵。
的确，产品经理需要将他们对行业、目标受众和产品的知识应用到他们的优先级排序过程中。但是，如果你注意到客户对某个特性的不温不火的反应和有偏见的优先级之间存在某种关系，你就需要重新评估一些事情了。
理想情况下，你应该有一个框架，根据可取性、可行性和可行性，帮助你优先考虑待办事项和用户故事:
愿望:有多少顾客想要它?他们有多想要?(验证值)
可行性:我们有足够的资源(时间、金钱和精力)来建造它吗?
可行性:它会赚钱吗?
当涉及到定义这些值时，让团队在同一页面上的方法之一是通过价值(可取性)vs努力(可行性)矩阵运行功能，也称为象限或网格。
提示:众所周知，人们不擅长估算时间和客户期望等抽象数据。此外，很难为努力之类的事情分配硬性的值和数字(当你无法预测会不可避免地影响这些时间估算的异常值时，你如何量化完成某件事所需的小时数?)只要记住，你可能对这些估计是错误的，这没关系。你做的评估练习和backlog优先级划分工作越多，你就越能了解团队是如何理解产品的，以及你是否需要调整他们的思维方式。
价值与成本
下面是一个基本的优先排序矩阵，你可以在下一次团队待办事项优先排序会议上使用它。首先，找一个可以画出四象限矩阵的白板或应用程序。
- Y轴是客户价值。你如何定义一个特性的价值取决于你的产品。客户是否立即需要它?你的公司可能对价值有其他定义，比如潜在收入，所以如果你觉得相关的话，你可以把它画出来。
- 在X轴上，您将绘制开发一个计划的成本(也称为难度值)。这对开发团队非常有帮助。
- 在图表的左下方，您将绘制值最低的项目。在右上方，你会列出最高的。
一个每个人都同意的价值的优先级矩阵可以帮助您确定在通知待办事项优先级决策时，您从内部和外部涉众那里得到了多少输入。它还可以帮助您评估当前史诗和用户故事的数据是否准确和最新。
进行优先排序框架练习也可以帮助你解决囤积旧物品的问题。在这种情况下，“旧”是指你在接下来的3个冲刺中都无法获得的道具。
我们创建了一个可操作的指南来创建任何风格的敏捷路线图。在此下载
Backlog优先级陷阱3:
PM或PO没有接触到公众作为优先排序过程的一部分。
为什么这是个问题:您只能从内部、一维的角度了解一个特性有多么可取。
解决方案:验证，验证，再验证。
为了成功，项目经理需要的软技能之一是能够对自己进行持续的偏见检查。早期与客户一起验证功能想法不仅有利于项目经理的信心水平，还可以在投入资源构建功能之前给产品团队增加一层信心。
产品特性验证是一个巨大的主题，在这里我们不会讨论太多细节。重要的是，在你为下一个sprint收集最优先级的项目之前，你至少要做一些形式的计划。无论你是想进行用户访谈、beta测试、A/B测试还是调查，在你通过优先级框架或价值vs成本象限运行想法后，在某种程度上验证它们对优先级排序过程都是至关重要的。
以下是一个良好的客户验证过程应该帮助您回答的问题:
- 它对用户有多大的好处?
- 这对用户有多重要?
- 它是一种止痛药(直接解决了客户的痛点)还是一种维生素(有这种东西很好)?
- 它的使用频率是多少?
- 人们会花多少时间使用它?
Backlog优先级陷阱4:
在不考虑依赖关系的情况下确定优先级。
为什么这是个问题:你可能最终构建了一个特性或功能，当你发现依赖关系时，你需要回到这个特性或功能，或者你可能构建了一些东西，如果你从构建一个不同的特性开始，可能会花费更少的时间。
解决方案:让开发团队成为backlog优先级排序过程中不可分割的一部分。
你的产品越大，你构建的功能越多，它们之间的依赖关系就越大。当您更新或添加新内容时，它可能会对已有的多个产品功能产生影响。尽早发现待办事项项之间的依赖关系可以帮助您为下一个sprint确定正确的特性集的优先级。
您应该与开发团队定期召开backlog优先级会议。这样，它们可以帮助你在早期发现技术风险和依赖关系，在你花费所有的时间、金钱和精力去做你以后必须重做的事情之前。与你的开发团队进行优先级讨论也可以帮助你确保没有任何东西是按顺序构建的(功能x必须是第一位的，否则功能Y(我们在功能x之前安排的下一个sprint)就不可能存在)。
来总结一下
如果说从这篇文章中可以学到什么教训的话，那就是为待办事项排优先级并不是一个人的工作。团队应该一起工作，以确保他们根据对公司最重要的参数来排序和组织待办事项项。保持持续的合作和健康的想法和输入环境也会让每个人都觉得自己的想法被倾听。
最重要的是，通过确定这些价值是如何定义的，您的团队可以感觉到他们的贡献是基于某种形式的定性和定量标准的。
最后，当你努力建立这些优先级参数时，你可以确信你将花费时间和精力在对你、你的公司和你的客户最重要的计划上。
