产品待办列表是什么
产品待办列表是需求的单一来源，由产品负责人维护并按价值排序。它包含用户故事、缺陷修复、技术改进与合规任务等多种条目，随认知更新持续细化。它的核心不是清单本身，而是排序权与唯一性：只有一处待办列表、只有一个人负责排序，团队才不必在多套优先级之间猜。其上是产品目标，其下是 Sprint 待办列表。
基本信息
| 归属角色 | 产品负责人对内容与排序负最终责任 |
|---|---|
| 内容构成 | 用户故事、缺陷、技术改进、合规与迁移类任务 |
| 细化机制 | 定期梳理，把近期要做的条目细化到可估算可验收 |
| 与 Sprint 的关系 | Sprint 待办列表由产品待办列表条目拆分而来，是团队当前承诺 |
典型使用场景
- 版本规划：按价值与依赖把条目分配到未来几个迭代
- 需求澄清会：把近期条目细化到可估算，补充验收准则
- 多来源需求整合：业务、运维、合规的需求统一进入同一列表排序
- 缺陷与功能权衡：用同一套价值标准判断先修缺陷还是先做新功能
- 发布准备：检查待办中是否有未完成的合规与迁移条目
条目描述格式
条目描述格式
作为 <角色>，我希望 <功能>，以便 <价值>
验收准则：
1) 正常路径：用户提交表单后收到确认并生成记录
2) 异常路径：提交失败时提示原因且不产生脏数据
3) 非功能：响应时间在 P95 情况下小于 1 秒
# 验收准则要可测试，否则条目无法验收排序依据
| 字段 | 说明 | 示例 |
|---|---|---|
| 价值 | 对核心指标的贡献 | 影响转化率的关键路径功能 |
| 合规期限 | 监管要求的上线日期 | 年报前必须完成的报备改造 |
| 依赖 | 需先完成的平台改造 | 先升级鉴权，才能接入新登录方式 |
| 风险与成本 | 不确定性与实现代价 | 高不确定性条目先做原型 |
| 紧急缺陷 | 影响生产可用性的问题 | 支付失败需优先修复 |
常见排序误区
| 误区 | 表现 | 后果 |
|---|---|---|
| 按提出人排序 | 谁声音大谁优先 | 价值排序失去意义，团队失去公信力 |
| 只排功能条目 | 缺陷与技术改进长期积压 | 债务累积，交付速度持续下降 |
| 排序长期不更新 | 几个月沿用同一顺序 | 业务变化后优先级与现实脱节 |
| 细度一刀切 | 远期条目也细化到最细 | 浪费大量梳理时间在可能取消的需求上 |
细化颗粒度
| 时间距离 | 建议颗粒度 | 原因 |
|---|---|---|
| 当前迭代 | 可估算、可验收、可拆分任务 | 团队当周就要开工 |
| 下一个迭代 | 明确范围与验收准则 | 为规划会做准备 |
| 两三个迭代后 | 方向与大致规模清楚即可 | 避免过早投入细化成本 |
| 更远 | 仅保留目标与假设 | 可能被取消或被替代 |
落地要点
- 排序依据显式化并公开，减少排序争议与反复解释
- 产品待办列表保持单一来源，其他渠道的需求先汇总再排序
- 定期梳理但不追求全部细化，靠近交付的条目才需要精细
- 明确的拒绝记录同样要留，避免同一诉求反复提出
排列顺序建议公开透明：让团队知道为什么这一条比那一条优先，比单纯下发一张顺序表更能获得执行认同。
待办列表无人维护、条目描述含糊到无法估算，Sprint 规划会就会退化成现场猜工作量，估算与承诺都不可靠。