产品待办列表要支撑排序、验收和追溯来源，每条条目至少应记录：唯一编号、标题、条目类型、业务背景与目标、验收标准、优先级或排序位置、估算、状态、负责人、来源、创建与更新日期。团队成熟后，可再补充价值依据、依赖关系、目标版本或迭代、风险与假设、附件链接。下面给出一份可直接复制的空白表格模板，并说明每个字段怎么填、哪些必填、如何随团队调整；ONES 可用于承载这些字段与状态流转，具体配置以实际环境为准。
要点总览（TL;DR）
- 产品待办列表每条条目至少记录：编号、标题、条目类型、业务背景与目标、验收标准、优先级或排序位置、状态、负责人、来源、创建与更新日期，这组字段覆盖排序、验收、追溯三个基本用途。
- 估算与目标版本/迭代在团队开始做迭代规划时启用；依赖关系、风险与假设、附件链接按条目实际情况填写，避免模板一开始就过重。
- 条目类型不同可调整必填程度：需求类强化背景目标与验收标准，缺陷类强化复现环境与影响范围，通用字段保持一致。
- 填写时排序位置与估算要配合使用，验收标准逐条可验证，来源关联到具体记录，字段缺失按团队约定处理而不是长期留空。
- 模板落地后按“是否支撑排序、验收、追溯”判断字段增删，固定梳理节奏与归档规则，字段变更时保留旧条目的历史值可读。
可复制的产品待办列表空白模板
下面这张表可以直接复制到 Excel、在线表格或文档中。列顺序按“先识别、再判断、后流转、最后治理”排列，便于从左到右填写。空白行用占位符表示，复制后替换为实际内容即可。
| 编号 | 标题 | 条目类型 | 业务背景与目标 | 验收标准 | 优先级/排序位置 | 估算 | 状态 | 负责人 | 来源 | 目标版本/迭代 | 依赖关系 | 风险与假设 | 附件链接 | 创建日期 | 更新日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PB-001 | （一句话描述要交付的能力） | 需求/缺陷/技术改进/调研 | （为什么做、解决谁的什么问题、期望结果） | （可验证的完成条件，逐条列出） | （数字序号或高/中/低） | （故事点或人天，注明单位） | 待梳理/待排期/已排期/进行中/已完成/已归档 | （姓名） | （客户反馈/内部提出/数据分析/合规要求） | （版本号或迭代名称，未定可留空） | （依赖的条目编号或外部条件） | （已知风险、待验证假设） | （原型、文档、工单链接） | （YYYY-MM-DD） | （YYYY-MM-DD） |
| PB-002 | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） |
| PB-003 | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） | （占位） |
如果团队按条目类型管理，可以在同一张表上增加“类型专属列”，不必为每类条目单独建表。常见做法是：需求类条目增加“用户角色”“使用场景”；缺陷类条目增加“复现环境”“影响范围”“严重程度”；技术改进类条目增加“影响系统”“回滚方案”。这些列在对应类型下填写，其他类型留空。
复制到表格工具后，建议先做三件事：把编号列设为文本格式，避免前导零丢失；把状态列做成下拉选项，统一取值；冻结表头并开启筛选，便于按负责人、状态、迭代快速查看。若复制到文档中，可保留表格结构，把长文本字段（背景、验收标准）放在表格下方以段落展开，表格内只放摘要。
每个字段的含义与填写口径
字段说明与上面的模板一一对应。填写口径的目标是让不同的人看到同一条目时，能做出相近的判断，而不是追求字段越多越好。
| 字段 | 含义 | 填写形式 | 常见错误 |
|---|---|---|---|
| 编号 | 条目的唯一标识，用于引用、依赖和追溯 | 固定前缀加流水号，如 PB-001；全表唯一，不复用 | 手工随意编号导致重复；删除条目后把编号让给新条目 |
| 标题 | 用一句话说明要交付什么 | 动词开头，包含对象和结果，控制在二十字左右 | 写成“优化一下”“看看这个问题”等无法判断范围的说法 |
| 条目类型 | 区分需求、缺陷、技术改进、调研等 | 从固定选项中选择，不自由填写 | 类型混用，导致必填字段和验收方式不一致 |
| 业务背景与目标 | 说明为什么做、解决谁的什么问题、期望达到什么结果 | 两到四句话，包含现状、问题和目标；目标尽量可观察 | 只写解决方案，不写问题；背景写成产品介绍 |
| 验收标准 | 判断条目完成的客观条件 | 逐条列出，每条可验证，包含正常路径和关键异常路径 | 写成“体验良好”“性能达标”等无法判定的描述 |
| 优先级/排序位置 | 表达条目之间的相对先后 | 用连续序号表示排序，或用高/中/低加理由；同一列表内口径统一 | 所有条目都标“高”；排序与估算脱节，无法支撑排期 |
| 估算 | 表达完成条目所需的相对规模或工作量 | 故事点或人天，注明单位；同一团队使用同一尺度 | 不同人用不同单位；估算后长期不更新 |
| 状态 | 表示条目当前所处的处理阶段 | 从固定状态集中选择，如待梳理、待排期、已排期、进行中、已完成、已归档 | 状态名称随意增加；条目完成后不归档 |
| 负责人 | 当前对条目推进负责的人 | 填具体姓名，不填团队名；交接时同步更新 | 长期空缺；多人并列导致责任不清 |
| 来源 | 记录条目从何处产生，便于追溯和回访 | 客户反馈、内部提出、数据分析、合规要求等，附具体来源标识 | 只写“用户反馈”，无法回到原始记录 |
| 目标版本/迭代 | 条目计划进入的版本或迭代 | 版本号或迭代名称；未确定时留空，不提前填占位 | 为未排期条目随意填写版本，造成排期失真 |
| 依赖关系 | 条目完成所依赖的其他条目或外部条件 | 填写依赖条目编号，或写明外部条件及预计满足时间 | 只写“依赖对方”，不写具体对象和时间 |
| 风险与假设 | 记录已知风险和尚未验证的前提 | 每条风险写影响和应对；假设写验证方式 | 把风险写成泛泛的“可能有风险” |
| 附件链接 | 指向原型、文档、工单等补充材料 | 放链接或文件位置，不把大段内容粘进表格 | 链接失效无人维护；附件散落在个人目录 |
| 创建日期 | 条目首次录入的时间 | YYYY-MM-DD，由系统或录入人填写 | 补录时填成当天，失去时间参考 |
| 更新日期 | 条目最近一次实质性修改的时间 | YYYY-MM-DD，状态、排序、验收标准变化时更新 | 只改内容不更新日期，无法判断信息新鲜度 |
标识类字段解决“这是哪一条、属于什么、从哪来”；判断类字段解决“为什么做、做到什么程度算完成、先做哪条、大概多大”；流转类字段解决“现在到哪一步、谁在推、计划放哪、卡在什么上”；治理类字段解决“什么时候进来、什么时候改过、有什么不确定、材料在哪”。四类字段各自承担不同用途，缺一类就会在排序、验收或追溯上出现断点。
必填与选填：按团队阶段划分字段层级
字段数量应服从三个用途：能支撑排序、能支撑验收、能追溯到来源。刚建立待办列表的团队，先把最小必填集填稳，再按需要启用扩展字段，比一开始就追求齐全更可持续。
| 层级 | 字段 | 启用条件 | 理由 |
|---|---|---|---|
| 最小必填 | 编号、标题、条目类型、业务背景与目标、验收标准、优先级/排序位置、状态、负责人、来源、创建日期、更新日期 | 所有团队、所有条目默认填写 | 覆盖排序、验收、追溯三个基本用途；缺少任一项，条目在评审或交接时就需要额外补问 |
| 建议启用 | 估算、目标版本/迭代 | 团队开始做迭代规划，或需要比较投入产出时 | 估算与排序位置配合，才能判断“先做哪条、做不做得完”；目标版本在排期后填写 |
| 按需启用 | 依赖关系、风险与假设、附件链接 | 条目存在跨团队依赖、技术不确定性或需要补充材料时 | 这些字段对部分条目关键，对简单条目可能是空列；按条目实际情况填写 |
条目类型不同，必填字段可以有差异。需求类条目必须写清业务背景与目标、验收标准；缺陷类条目可以强化复现环境、影响范围和严重程度，业务背景可简化为问题现象；技术改进类条目需要写清影响系统和回滚方案；调研类条目可以把验收标准写成“输出什么结论、由谁确认”。差异只调整字段的必填程度，不改变编号、标题、状态、负责人、来源这些通用字段。
字段缺失时要有处理约定，而不是让空字段长期存在。可以约定：缺少验收标准的条目不能进入“已排期”；缺少来源的条目在梳理会上补录，补录前标记为“待补充”；负责人空缺超过一个梳理周期，由产品负责人指定临时负责人。约定写进团队的工作规则，比反复口头提醒更有效。
完整填写示例：一条需求从录入到可排序
下面用一条演示条目说明各字段如何协同。示例为虚构场景，仅用于展示填写方式。
| 字段 | 填写内容 |
|---|---|
| 编号 | PB-014 |
| 标题 | 支持按客户标签批量导出订单明细 |
| 条目类型 | 需求 |
| 业务背景与目标 | 运营团队每月需要按客户标签整理订单数据，目前逐页导出再手工合并，单次约耗时半天，且容易漏单。目标是把单次整理时间降到半小时以内，并保证导出结果与列表筛选一致。 |
| 验收标准 | 1. 在订单列表按客户标签筛选后，可一键导出当前筛选结果；2. 导出文件包含订单号、客户名称、标签、金额、下单时间；3. 导出条数与列表显示条数一致；4. 超过一万条时给出分批导出提示；5. 无导出权限的用户看不到该入口。 |
| 优先级/排序位置 | 排序第 3 位；理由：影响运营月度结算，且已有明确替代手工方案 |
| 估算 | 5 故事点（团队统一尺度） |
| 状态 | 待排期 |
| 负责人 | 产品经理甲 |
| 来源 | 运营团队月度复盘提出，关联工单 FK-2087 |
| 目标版本/迭代 | 留空，待排期会议确定 |
| 依赖关系 | 依赖 PB-009 完成客户标签权限校验 |
| 风险与假设 | 风险：大数据量导出可能影响接口响应，需评估分批策略；假设：运营团队使用的标签体系与系统内一致，待确认 |
| 附件链接 | 原型图与字段清单见需求文档链接 |
| 创建日期 | 2025-03-04 |
| 更新日期 | 2025-03-11 |
逐项对应前面的字段说明：编号和标题解决识别；业务背景写清现状、问题和目标，验收标准逐条可验证，二者共同支撑验收；排序第 3 位表达相对先后，5 故事点表达规模，两者配合才能判断这条需求在当前排期内是否放得下；状态和负责人说明当前由谁推进；来源关联到具体工单，便于回访提出方；依赖关系提示排期前需先确认 PB-009 的进度；风险与假设把不确定项显性化，避免排期后才发现。
这条示例停留在待办列表层面：它说明了条目如何从录入走到“可排序”，不展开进入迭代后的任务拆分，也不涉及价值评分模型的打分方法。排序理由写的是业务影响和替代方案，属于定性判断，具体评分口径由团队另行约定。
模板的调整与日常维护方法
模板落地后，字段会随团队分工和业务变化而调整。调整的判断依据可以归结为三个问题：这个字段是否还在支撑排序、验收或追溯中的某一项；填写它是否带来了可观察的决策改善；维护它的成本是否低于它带来的信息价值。三个问题都答不上来的字段，可以考虑合并或废弃。
- 新增字段：当同类信息反复出现在评论、聊天记录或会议纪要中，且影响排序或验收判断时，再增加为正式字段。新增前先确认取值方式和填写人。
- 合并字段：两个字段长期一起填写、一起阅读，可以合并为一个，减少重复录入。合并时保留原字段的历史值说明。
- 废弃字段：连续两个梳理周期几乎无人填写、也未影响任何决策的字段，可以停用。停用不等于删除历史数据，旧条目中的值应保持可读。
条目状态和归档规则需要固定下来。建议约定：已完成或已取消的条目在一个梳理周期后移出活跃视图，标记为已归档；归档条目仍可按编号和来源检索；状态名称只增不改，避免同一状态出现多种叫法。定期梳理的节奏可以设为每周一次或每个迭代一次，由产品负责人主持，各条目负责人提前更新自己负责的条目。梳理会的产出是排序调整、字段补全和归档决定，而不是逐条重新讨论背景。
字段变更时要注意历史数据兼容。比较稳妥的做法是：新增字段对旧条目留空，不强制回填；废弃字段保留列或保留在历史记录中，只从新建条目的必填项中移除；修改字段取值口径时，在字段说明中注明生效日期，旧值按原口径理解。这样旧条目不会因为模板变化而失去上下文。
当待办条目增多、参与角色变多时，表格本身会逐渐难以承载筛选、状态流转和权限控制。此时可以把字段结构迁移到工作项管理工具中：ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，ONES 工单可收集各方反馈并转化为需求、整理出产品 Backlog；条目较多时可用筛选器按条件定位，复杂需求可用子工作项拆解并关联研发和测试任务。迁移时保持字段名称和取值口径与本文模板一致，先迁移活跃条目，再按需归档历史数据。
常见问题
团队刚开始建待办列表，字段填不全怎么办？
先把最小必填集填稳：编号、标题、条目类型、业务背景与目标、验收标准、优先级或排序位置、状态、负责人、来源、创建与更新日期。估算、目标版本/迭代等字段可以在开始做迭代规划时再启用。对暂时缺失的字段，建议写进团队工作规则，例如缺少验收标准的条目不能进入“已排期”，缺少来源的条目在梳理会上补录并标记为“待补充”，负责人空缺超过一个梳理周期由产品负责人指定临时负责人。用约定代替反复口头提醒，空字段才不会长期堆积。
缺陷和技术改进类条目也要用同一张表吗？
可以放在同一张表里，通过“条目类型”区分，再增加类型专属列，不必为每类条目单独建表。需求类条目可增加用户角色、使用场景；缺陷类条目可增加复现环境、影响范围、严重程度，业务背景简化为问题现象；技术改进类条目可增加影响系统、回滚方案；调研类条目把验收标准写成“输出什么结论、由谁确认”。类型差异只调整字段的必填程度，编号、标题、状态、负责人、来源这些通用字段保持一致，便于统一筛选和追溯。
排序位置和估算都填了，排期时还缺什么判断？
排序位置表达条目之间的相对先后，估算表达规模或工作量，两者配合才能判断当前排期内放不放得下。排期前还需要确认依赖关系是否满足，例如某条需求依赖另一条目的权限校验先完成；同时看风险与假设中是否有未验证的前提，避免排期后才发现阻塞。目标版本/迭代在排期会议确定后再填，未确定时留空，不用占位值填充，否则会造成排期失真。
模板用了一段时间，字段越来越多，怎么判断该删哪些？
用三个问题判断：这个字段是否还在支撑排序、验收或追溯中的某一项；填写它是否带来了可观察的决策改善；维护成本是否低于它带来的信息价值。三个问题都答不上来的字段，可以考虑合并或废弃。合并适用于长期一起填写、一起阅读的字段；废弃适用于连续两个梳理周期几乎无人填写、也未影响决策的字段。停用字段时保留历史数据可读，只从新建条目的必填项中移除，旧条目不会因为模板变化失去上下文。
待办条目多到表格难以维护时，迁移到工具要注意什么？
迁移时保持字段名称和取值口径与现有模板一致，先迁移活跃条目，再按需归档历史数据，避免新旧两套口径并行。选择工具时关注三点：能否自定义条目属性和状态、能否按负责人和状态等条件筛选定位、能否把条目与迭代规划和研发测试任务关联。以 ONES 为例，ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，条目较多时可用筛选器按条件定位，复杂需求可用子工作项拆解并关联研发和测试任务；ONES 工单可收集各方反馈并转化为需求、整理出产品 Backlog。具体字段配置范围以实际环境为准。
