产品待办事项：分步指南

产品待办事项是产品开发链的重要组成部分之一，是产品功能的优先列表，从公司和产品的愿景到执行再到完整发布。 它是一个强大的工具，因为它将高层次的愿景转化为创建产品的工作细节。 产品经理的主要职责是创建、优先排序和维护产品待办事项。 让我们更深入地了解构建健康产品待办列表的分步流程和核心要素。

将积压工作拆分为两个列表

在创建积压工作之前，定义它的范围，它是否应该适用于一个产品线、一组产品或公司的所有产品——这将有助于您管理功能。

我从多个项目中了解到，将积压工作分为两个列表是一种健康的做法：长期主积压工作和短期可执行积压工作（也称为冲刺积压，因为它可以包括一个或多个冲刺）。 这个想法是专注于最紧迫的项目，以便及时开发它们，同时保持主积压中所有功能的全局。

一开始，两个积压工作都是从高级功能列表开始的。 然而，为了便于执行，冲刺积压通常分为史诗和用户故事，而长期积压则保持原样。 作为产品经理，您决定哪些项目应该从一个列表移到另一个列表，以及何时。

积压源

下一步是确定可以为积压工作提供潜在功能的来源。 来源可以是用户研究、特定客户请求、调查或详细的营销研究。 如果您从使用的其他产品中获得相关发现，它们也可以作为重要来源做出贡献。 虽然这些是最常见的来源，但还有一些其他来源：

• QA 团队是积压项目的绝佳来源，因为他们广泛使用该产品，并且可能有宝贵的改进反馈。
• 客户支持反馈。 在硬件产品的情况下，一个不错的来源可能是制造问题或现场报告的问题。
• 对产品的问题、问题或错误的审查也可以产生如何改进它的想法。
• 来自销售的请求
• 研发计划或想法

弃权阻止功能

一个好的产品经理应该拥有积压工作并充当看门人，控制其上显示和执行的功能。 构建一个 backlog，以便高优先级的项目出现在列表的顶部，最不重要的项目出现在底部。 产品经理应该促进将项目包含在积压工作中，而不是阻止它们。 阻塞应该只发生在极端情况下，当产品经理完全确信某个功能毫无价值时。 不要阻止项目，而是让优先级处理进行过滤。 这可能听起来不合理，但您甚至可以包含一个可能在五年内不会开发的功能——将所有潜在功能集中在一个地方是一个有价值的来源。

处理物品

待办事项由必须开发成史诗或用户故事的高级功能组成，或者只需输入描述，以便它们出现在待办事项中。 包括它们时，请确保您有足够的信息，但不要过度使用细节。 保持敏捷：仅在项目接近开发阶段时才花时间撰写描述。 产品经理必须在看到大局和不深入细节之间保持平衡，以节省时间并保持效率。

优先处理积压工作

对积压工作进行排序是确定优先级的核心过程。 这是一个高度战略性的步骤，专注于数据而不是直觉。 尽管优先级通常是产品经理的职责，但通常需要得到高级管理层的确认和批准。 有一个适当的结构可以帮助你捍卫你的优先级决定。 您需要能够展示结构、传达结构并获得批准。

维持健康的优先级流程的一个关键要求是为积压功能创建明确定义的权重和评估标准。 不同的产品根据其性质需要不同的解决方案。 在下一节中，我将介绍可用作工具箱的实用组件，以创建不同的公式以实现有效的优先级排序。

定义优先级标准

定义对您的产品重要的标准，并使用它们对每个待办事项功能进行评分。 任何产品都应包括这些标准：

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

取决于产品的其他考虑标准：

• 信心。 你对这将被使用有多大信心？ 这是创业公司的重要标准，也是公司进入新市场时的重要标准。
• 风险。 风险越高，该标准的得分越低。 该标准与Confidence标准密切相关。
• 成本。 高实施成本得到低分。 它类似于复杂性标准，但是，在某些情况下，高成本意味着较短的开发时间。

分级方法

在给每个积压功能打分之前，设置三到五个选项（非常低、低、中、高）并简要描述它们。 例如，关于功能开发长度，复杂性标准将具有以下等级：

• 非常低。 实现一个功能只需要几天时间。 （此功能获得最高分。）
• 低的。 实施需要不到一个完整的冲刺或一到两周的时间。
• 中等的。 实施需要一个冲刺或两周。
• 高的。 实施需要不止一个冲刺。 （此功能获得最低等级。）

不要给级别序号（即不要使用 0、1、2、3）。 相反，请使用此系统：

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

采用这种分级方法时，您将清楚地分离特征的总和。 当您使用具有 30 或 50 个功能并且不希望最终使用具有相同分数的 15 个功能时，这会产生很大的不同——您需要的是一个清晰排序的优先级列表。

定义权重

下一个重要步骤是定义所选标准的权重或因素。 默认情况下，所有标准对要素等级的贡献均相同。 但是，有时，标准会产生显着不同的影响，因此会做出更可靠的贡献。 为简单起见，让我们举一个带有两个标准的数值示例：A 和 B。如果您如上所述对分数求和，则每个标准将贡献一半的成绩。 但是，当标准 A 的重要性是标准 B 的两倍时，您应该提出如下公式：

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

该公式可能有许多不同的版本，具体取决于转换为数字的因素权重。 权重总是必须加起来为 1。

加权方法为优先排序提供了灵活性，并使积压项目与公司战略保持一致。 例如，如果一家公司专注于短期收入，那么与收入相关的因素在权重方案中的等级将高于其他因素。 这样，有望获得收入的功能将出现在积压的顶部。

细化：走向用户故事

在完成优先级排序过程后，sprint backlog 的下一步是创建用户故事。 产品经理插入初始功能描述，并将用户故事的原始版本包含在待办事项列表中。 现在是时候让 Scrum 团队参与创建新的用户故事来响应用户的需求了。 待办事项细化（或修饰）当然是团队合作的结果。 我喜欢通过将用户商店转变为功能来与团队进行头脑风暴，因为这是抽象愿景转向实际实施的时候。 作为产品负责人，您可能会寻求开发精确的用户故事——牢记这一点，但对团队的想法保持开放：根据我的经验，团队的贡献可以显着改善用户故事。

短期积压包括三种类型的用户故事：

• 生的。 这些是在细化阶段正在处理的新鲜结晶的故事。 产品经理必须积极主动并驱动团队，以便将最好的故事推入开发阶段。
• 准备好。 这些是可以开发的故事。 在这个阶段，产品经理必须亲自动手，通过回答问题和消除瓶颈来支持执行。
• 完毕。 这些是已准备好部署和发布的完整故事。

维护积压

应该定期修改积压工作（master 和 sprint）。 当长期列表中的任务过多时，请查看底部的项目并决定是否需要删除它们。 此外，请确保在制定发布计划后修改积压工作。 通过刷新优先级，如果项目的优先级发生变化，则应将其移至短期积压。 在功能实施和发布后，将它们标记为“完成”并归档在主积压工作中。 您可能需要它们来进行 sprint 回顾和 KPI 测量。

如何沟通积压

由于积压是主要的产品构建计划，因此产品经理将其有效地传达给团队、首席执行官或其他利益相关者至关重要。 不要按原样呈现列表——有太多细节，你会失去观众的注意力。 相反，关注两个方面：

• 优先机制。 给出积压项目标准和权重的高级表示，并用支持数据证明它们的合理性。 这样，您将说服观众您构建的积压工作满足所有要求并与公司的愿景保持一致。
• 特征。 从上到下呈现积压的功能。 详细程度应取决于受众，您可能需要解释功能及其等级。

功能强大的工具

产品待办列表是产品经理的强大工具，因为它代表了从战略思维到日常策略的转变。 作为产品负责人，你所培养的技能——管理、优先排序、更新和维护积压工作——将有助于你构建出色的产品和提高公司的整体绩效。