产品待办事项列表是产品开发链的重要组成部分之一, 产品特性的优先级列表，从公司和产品的愿景出发，通过执行，直至完整的发布. 它是一个强大的工具, 因为它将高层次的愿景转化为创建产品的工作细节. 产品待办事项列表管理由产品经理负责, 谁有创造的主要责任, 优先考虑, 并保持它. 让我们更深入地了解健康产品待办事项列表创建的逐步过程和核心要素.

将待办事项分成两个列表

在创建backlog之前, 定义它的范围, 是否适用于产品线, 一组产品, 或者公司的所有产品——这将帮助您管理功能.

我从多个项目中学到，将待办事项分成两个列表是一种健康的做法: 长期主积压 和 短期可执行待办事项 (也称为sprint backlog，因为它可以包括一个或多个sprint). 这样做的目的是把重点放在最紧急的项目上，以便及时开发它们，同时在主待办事项列表中维护所有特性的大局.

一开始，这两个backlog都是以高级功能列表开始的. 然而, 为了便于执行，冲刺待办事项通常分为史诗和用户故事, 而长期的积压依然如故. 作为产品经理，您决定哪些项目应该从一个列表移动到另一个列表，以及何时移动.

如何创建产品待办事项列表

下一步是确定可以为待办事项列表提供潜在特性建议的来源. 来源可以是 用户研究，具体的客户要求，调查，或 详细的市场调研. 如果你有其他产品的相关发现, 他们也可以作为一个很好的资源. 虽然这些是最常见的来源，但还有其他一些来源:

• 的 QA团队 是待定项的优秀来源吗, 因为他们广泛使用该产品，并且可能对改进提供有价值的反馈.
• 客户支持反馈. 以五金产品为例, 一个像样的来源可以是制造问题或从现场报告的问题.
• 对产品的问题、问题或bug的回顾也可以产生如何改进它的想法.
• 销售要求
• R&D计划或想法

避免阻塞特性

一个好的产品经理应该拥有待办事项列表，并作为看门人控制哪些特性出现在待办事项列表中并被执行. 构建待办事项安排，以便高优先级的项目出现在列表的顶部, 最不重要的在底部. 产品经理 应该促进待办事项的包含，而不是阻止它们. 只有在极端情况下才会发生阻塞, 当产品经理完全确信某个特性毫无价值时. 而不是阻止项目，让优先排序过程进行过滤. 这听起来可能不合理, 但是你甚至可以包括一个可能五年内都不会开发的功能——把所有潜在的功能放在一个地方是一个有价值的资源.

处理项目

待办事项列表由必须开发成史诗的高级特性组成, 或者用户故事, 或者简单地输入描述，这样它们就会出现在待办事项列表中. 当你把它们写进去的时候，确保你有足够的信息，但不要在细节上做过多的工作. 看看这个 产品待办列表示例 如果你不确定. 保持敏捷:只在项目接近开发阶段时才花时间编写描述. 为了节省时间和保持效率，产品经理必须在看到大局和不太深入细节之间保持平衡.

产品待办事项列表是如何安排的?

整理待办事项是确定优先级的核心过程. 这是一个高度战略性的步骤，侧重于数据而不是直觉. 虽然优先级划分通常是产品经理的职责, 通常需要高层管理人员的确认和批准. 有一个适当的结构可以帮助你捍卫你的优先级决定. 您需要能够呈现结构、进行沟通并获得批准.

维护健康的优先级流程的一个关键需求是为待办事项特性创建定义良好的权重和评估标准. 不同的产品根据其性质需要不同的解决方案. 在下一节中, 我介绍了一些实用的组件，这些组件可以作为一个工具箱来创建不同的公式，以有效地确定优先级.

定义优先级的标准

定义对你的产品有重要意义的标准，并用它们对待办事项列表特性进行分级. 这些标准应包括在任何产品中:

• 收入. 这个标准是关于该功能可能带来多少收益，并基于客户或销售团队的反馈. 除非已经达成协议，否则潜在的收入将只是一个猜测. 尽管如此, 它仍然是一个有用的优先级度量，因为它可以帮助产品经理避免潜在的低投资回报(ROI)特性。.
• 市场契合度和市场独特性. 市场契合度显示给定的功能是否为用户解决了现有的问题. 市场独特性是衡量新功能相对于竞争对手的独特性. 这两个项目结合起来将突出竞争对手尚未开发的最相关的功能，从而带来巨大的机会.
• 复杂性. 这个标准结合了 预计发射时间 以及执行的整体复杂性. 这将影响多少函数? 每个项目的直接成本和潜在隐性成本是什么? 以尽可能短的交付时间和功能所能带来的最大价值为目标.

其他视乎产品而定的考虑标准:

• 信心. 你有多大的信心这将被使用? 这是创业公司的重要标准，也是公司进入新市场的重要标准.
• 风险. 风险越高，该标准的得分越低. 这一标准与 信心 标准.
• 成本. 实现成本高，得分低. 它类似于 复杂性 然而，在某些情况下，高成本意味着较短的开发时间.

分级方法

在给每个待办事项特性打分之前, 设置三到五个选项(非常低), 低, 媒介, 高)并简要描述它们. 例如，关于功能开发的长度 复杂性 标准将有以下等级:

• 非常低的. 只需要几天的时间 实现一个特性. (此功能得到 最高等级.)
• 低. 实现需要不到一个完整的冲刺或一到两周的时间.
• 媒介. 实现需要一个sprint或两个星期.
• 高. 实现需要不止一个冲刺. (此功能得到 最低级.)

不要给级别顺序编号(即不要使用0、1、2、3). 相反，使用这个系统:

非常低等级0分
低等级1分
中等3分
高分9分

当使用这种分级方法时，你会得到一个清晰的特征总和分离. 当你将它用于30或50个功能时，这将产生巨大的差异，而不是最终只有15个功能具有相同的分数——你想要的是一个清晰排序的优先级列表.

定义权重

下一个重要步骤是为所选标准定义权重或因子. 默认情况下，所有标准对特征等级的贡献是相等的. 然而，有时，标准有显著不同的影响，因此是更可靠的贡献. 为简单起见，让我们举一个有两个标准的数值例子:a和B. 如果你按上面描述的方式加起来，每条标准将占分数的一半. 然而, 标准A的重要性是标准B的两倍, 你应该得到这样一个公式:

整体特征得分= 0.66 * A + 0.33 * B

这个公式可能有很多不同的版本, 根据因子的权重，将其转换成数字. 权重加起来总是等于1.

加权方法为优先级排序提供了灵活性，并使待办事项与公司的战略保持一致. 例如, 如果一家公司专注于短期收入, 与收入有关的因素在加权办法中的等级将高于其他因素. 这样，有望获得收益的功能就会出现在待办事项列表的最前面.

细化:面向用户故事

在优先排序过程完成之后, sprint待办事项的下一步是创建用户描述. 产品经理插入初始特性描述，并将用户描述的原始版本包含到待办事项列表中. 现在是时候了 scrum团队 创建新的用户故事以响应用户的需求. 待办事项的细化(或修饰)当然是团队合作的结果. 我喜欢与团队进行头脑风暴，将用户商店转化为功能, 因为这是抽象愿景转变为实际实现的时候. 作为产品负责人，您可能会寻求 开发一个精确的用户故事-记住这一点, 但要对团队的想法持开放态度:以我的经验来看, 可以显著地改进用户描述 scrum团队的 贡献.

短期待办事项包括三种类型的用户故事:

• 生. 这些是刚刚结晶的故事，正在细化阶段进行处理. 产品经理必须积极主动，推动团队将最好的故事推向开发阶段.
• 准备好了. 这些都是可以开发的故事. 在这个阶段, 产品经理必须亲自动手，通过回答问题和消除瓶颈来支持执行.
• 完成. 这些是已完成的故事，已准备好部署和发布.

维护待办事项

定期地，应该对积压任务(主任务和sprint任务)进行修订. 当长期清单上的任务太多时, 查看底部的项目，并决定是否需要删除它们. 同时，确保在编写发布计划之后修改backlog. 刷新优先级, 如果优先级发生变化，则应将项目移至短期待办事项列表中. 在特性实现和发布之后, 将它们标记为“完成”，并归档到主待办事项列表下. 你可能会在sprint回顾和 KPI测量.

如何沟通待办事项

因为待办事项列表是一个主要的产品构建计划, 对于产品经理来说，有效地与团队沟通是至关重要的, 首席执行官, 或者其他利益相关者. 不要原封不动地列出清单——细节太多了, 这样你就会失去听众的注意力. 相反，关注两个方面:

• 优先级机制. 给出待定项标准和权重的高级表示，并用支持数据证明它们的合理性. 通过这种方式，您将使受众相信您构建的待办事项列表满足所有要求 需求 并且与公司的愿景一致.
• 特性. 从上到下呈现待办事项列表的特性. 具体程度应该取决于受众, 你可能需要解释这些特征和它们的等级.

强大的工具

产品待办事项列表是产品经理的强大工具, 因为它代表了从战略思维到日常战术的转变. 作为产品领导者，你所培养的技能是管理, 优先考虑, 更新, 并保持库存——这将有助于你打造伟大的产品，提高公司的整体业绩.