产品待办列表要能支撑排序、交接和清理，建议至少包含五类信息：标识与来源、内容描述、分类与关联、状态与优先级、维护信息。本文给出一张可直接复制到表格工具的空白模板，逐字段说明填写口径，并区分必填与选填，最后用一条完整示例演示从粗粒度条目细化到可进入迭代的写法。字段可按团队规模裁剪，标识、描述、状态、优先级、负责人五项建议保留为必填。
要点总览（TL;DR）
- 产品待办列表建议至少包含五类信息：标识与来源、内容描述、分类与关联、状态与优先级、维护信息，共18个字段。
- 编号、标题、用户场景或目标、状态、优先级、负责人建议设为必填；验收要点在进入迭代前补齐，其余字段按团队情况选填。
- 小团队可压缩为六列并把类型与模块合并为“分类”；多产品线团队建议保留全部字段，并固定来源渠道与类型的取值口径。
- 从粗粒度到可进入迭代，主要动作是补充标题范围、把验收要点细化到可测试、填写目标版本或迭代。
- 模板需定期维护：字段增删留痕、状态与优先级口径统一、每两周或每个迭代前处理重复项与积压。
可复制空白产品待办列表模板
下表按五类信息分组排列，表头命名与后文“字段说明”保持一致。复制到 Excel、在线表格或协作工具的自定义字段中即可使用。前两行为空白填写行，实际使用时按需增删行数。
| 分组 | 编号 | 标题 | 提出人 | 来源渠道 | 用户场景 | 目标 | 验收要点 | 类型 | 所属模块 | 关联项 | 状态 | 优先级 | 目标版本/迭代 | 负责人 | 创建日期 | 更新日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 标识与来源 | |||||||||||||||||
| 内容描述 / 分类关联 / 状态优先级 / 维护信息 |
如果表格工具不支持合并单元格，可以把“分组”列改为在每行重复填写所属分组名称，或直接删除该列，依靠列顺序识别分组。分组列的作用是帮助填表人理解字段归属，不参与后续筛选。
每个字段记录什么：字段说明
字段说明解决“这一格该写什么”的问题。同一字段在不同条目中应保持相同的写法颗粒度，否则排序和筛选会失真。下表逐字段给出含义与填写口径。
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 编号 | 条目的唯一标识 | 由系统自动生成或按“模块缩写-序号”手工编排，一经分配不再复用；删除的条目编号作废，不转给新条目 |
| 标题 | 一句话概括待办内容 | 用“动词+对象+场景”写法，控制在20字左右，例如“支持按手机号搜索客户”；避免“优化一下”“看看登录”这类无法判断范围的表述 |
| 提出人 | 该需求的原始提出者 | 填写具体姓名或工号，便于回溯确认；多人共同提出时填主要联系人 |
| 来源渠道 | 需求进入列表的路径 | 统一取值，如客户反馈、销售提单、内部运营、数据分析、竞品观察、技术债；渠道口径需团队事先约定，避免同一来源出现多种叫法 |
| 用户场景 | 谁在什么情况下遇到什么问题 | 写清角色、触发条件和当前障碍，两三句即可；这一栏是后续判断价值和拆分任务的依据 |
| 目标 | 做完之后希望达到的结果 | 描述可观察的变化，如“客服可在同一页面完成退款，无需跳转工单系统”；避免只写“提升体验” |
| 验收要点 | 判断完成的标准 | 列2–5条可核验的条件，初期可粗，进入迭代前必须细化到可测试的程度 |
| 类型 | 条目的性质分类 | 常用取值：新功能、功能改进、缺陷修复、技术债、数据与报表、合规要求；类型决定后续评审路径和排期方式 |
| 所属模块 | 条目落在产品的哪个部分 | 沿用产品现有的模块划分，不临时造新分类；跨模块条目填主要模块，其余在关联项中说明 |
| 关联项 | 与其他条目的关系 | 填写重复项、前置依赖、父需求或被拆分的子项编号；发现重复时保留一条主条目，其余标注“重复于××”并关闭 |
| 状态 | 条目当前所处的处理阶段 | 统一取值，如待评估、已确认、已排期、进行中、已完成、已关闭；状态只反映流程位置，不表达价值高低 |
| 优先级 | 相对排序结果 | 使用有限档位，如高、中、低，或按排序序号；同一档位内仍需有先后顺序，避免大量条目并列“高” |
| 目标版本/迭代 | 计划在哪个版本或迭代交付 | 未排期时留空，不填“待定”占位；排期后填写版本号或迭代名称，与迭代计划保持一致 |
| 负责人 | 当前推动该条目的人 | 填写产品负责人或需求对接人，而非最终开发人员；负责人变更时同步更新，避免条目无人跟进 |
| 创建日期 | 条目录入时间 | 由系统自动记录，用于识别长期积压条目 |
| 更新日期 | 最近一次修改时间 | 由系统自动记录；手工维护时每次实质修改都要更新，作为清理检查的依据 |
| 备注 | 补充信息 | 记录讨论结论、客户原话、临时约束等不宜放入正式字段的内容；结论性信息应回写到对应字段，备注只作辅助 |
字段之间存在对应关系：标题与用户场景、目标共同构成条目描述，验收要点支撑状态从“已确认”推进到“已完成”；类型和所属模块决定评审由谁参加；优先级与目标版本/迭代共同决定排期顺序；关联项负责把重复和拆分关系串起来。填写时若发现某字段无法落笔，通常说明条目还太粗，需要先补充场景信息。
必填与选填：最小可用字段集
字段越多，录入负担越重，列表越容易被填成半成品。建议先确定一组必填字段保证列表可用，再按团队情况增加选填字段。
| 字段 | 建议属性 | 理由 |
|---|---|---|
| 编号 | 必填（系统生成） | 唯一标识是引用、关联和追溯的基础 |
| 标题 | 必填 | 列表视图和排序主要依赖标题识别条目 |
| 用户场景或目标（至少一项） | 必填 | 缺少场景或目标的条目无法判断价值，评审时只能反复追问 |
| 状态 | 必填 | 没有状态就无法区分待评估与已排期，交接时容易重复处理 |
| 优先级 | 必填 | 待办列表的核心用途是排序，缺优先级则排期无依据 |
| 负责人 | 必填 | 明确推动人，避免条目长期无人认领 |
| 提出人、来源渠道 | 选填（建议保留） | 条目较多、来源复杂时用于回溯和统计；单一来源的小团队可暂缓 |
| 验收要点 | 选填（进入迭代前必填） | 粗粒度阶段可先不写，排期前必须补齐 |
| 类型、所属模块 | 选填 | 多产品线或多模块团队建议保留，用于筛选和分工；单模块小团队可合并为一个“分类”字段 |
| 关联项 | 选填 | 出现重复或拆分需求时使用，条目量少时可暂不设列 |
| 目标版本/迭代 | 选填 | 排期后填写，未排期留空即可 |
| 创建日期、更新日期 | 选填（系统自动） | 用于积压清理，手工表格建议保留 |
| 备注 | 选填 | 承载临时信息，不承担正式字段职责 |
裁剪建议分两种情况。小团队（例如十人以内、单一产品线）可保留编号、标题、用户场景、状态、优先级、负责人六列，把类型与模块合并为“分类”，验收要点在排期前补写。多产品线团队建议保留全部字段，并额外约定来源渠道和类型的固定取值，否则跨团队汇总时口径难以对齐。
字段缺失的风险是渐进的：缺优先级，排期会退化为按提出先后处理；缺状态，已关闭的旧需求会被反复讨论；缺负责人，条目在交接中丢失；缺关联项，重复需求各自占用评审时间。字段不必一次配齐，但上述必填项一旦缺失，列表的排序和清理功能就会失效。
填写示例：一条完整待办从录入到细化
下面用一条演示性质的条目展示各字段如何配合。示例内容为虚构，仅用于说明填写方式。
| 字段 | 初次录入（粗粒度） | 细化后（可进入迭代） |
|---|---|---|
| 编号 | CRM-0137 | CRM-0137 |
| 标题 | 客户列表支持按手机号搜索 | 客户列表支持按手机号精确与模糊搜索 |
| 提出人 | 李敏（客服主管） | 李敏（客服主管） |
| 来源渠道 | 客户反馈 | 客户反馈 |
| 用户场景 | 客服接到电话时只有手机号，需要在客户列表中查找对应客户，目前只能按姓名搜索，找不到时需转人工核对 | 同左，补充：日均约30次此类查询，集中在售后高峰期 |
| 目标 | 客服凭手机号可直接定位客户 | 客服凭手机号在3秒内定位到唯一客户，无需转人工核对 |
| 验收要点 | 能搜到即可 | 1. 输入完整手机号返回唯一客户；2. 输入后四位返回候选列表；3. 无结果时给出明确提示；4. 搜索结果与客户详情页数据一致 |
| 类型 | 功能改进 | 功能改进 |
| 所属模块 | 客户管理 | 客户管理 |
| 关联项 | 重复于 CRM-0098（早期同类反馈） | 重复于 CRM-0098，已合并；前置依赖 CRM-0142（搜索服务升级） |
| 状态 | 待评估 | 已排期 |
| 优先级 | 中 | 高 |
| 目标版本/迭代 | （空） | V3.2 / 第14迭代 |
| 负责人 | 王磊 | 王磊 |
| 备注 | 客户原话：每次都要问客户姓名，很耽误时间 | 评审结论：先做精确搜索，模糊搜索随搜索服务升级一并上线 |
示例中状态从“待评估”变为“已排期”，是因为优先级经评审上调、目标迭代确定；优先级从“中”调为“高”，依据是查询频次和售后高峰的影响范围；关联项先记录重复条目并合并，再补充前置依赖，避免排期后才发现被其他工作阻塞。备注中的客户原话帮助评审理解场景，评审结论则回写到验收要点和备注，保证信息不丢失。
从粗粒度到可进入迭代，主要变化有三处：标题补充了搜索方式，明确范围；验收要点从一句“能搜到”扩展为四条可测试条件；目标版本/迭代从空值变为具体迭代。这三步完成后，条目才具备被拆分任务和估算的条件。迭代内的任务拆分与跟踪属于迭代管理范畴，本文不展开。
模板的调整与日常维护方法
模板落地后需要定期调整，否则字段会随使用逐渐膨胀或失效。以下动作可按团队节奏执行。
- 字段增删遵循“先加后删、留痕变更”原则。新增字段先在一个迭代内试用，确认有人填写、有人查看后再转为正式字段；删除字段前把历史数据导出或归档，并在变更记录中写明删除原因、生效日期和影响范围。变更记录可放在表格的独立页签或团队文档中，每次调整追加一行。
- 统一状态与优先级口径。把状态取值和每个状态的含义写成简短说明，例如“已确认”指需求已通过评审但未排期；优先级各档位给出判断依据，如“高”指影响核心流程或有明确交付承诺。新成员入职时先读口径说明再录入。发现同一状态出现多种叫法时，集中批量修正，不逐条口头纠正。
- 定期处理重复项与积压。建议每两周或每个迭代开始前做一次检查：按标题和模块筛查疑似重复条目，保留主条目并关闭其余；对超过一定时间未更新、且未排期的条目逐条确认，决定关闭、合并或重新评估。检查结果记录在备注或变更记录中，便于下次对照。
- 明确维护责任人与检查节奏。指定一名产品负责人或需求管理员负责模板字段和口径的最终解释，其他人提出调整建议由其汇总。检查节奏与迭代节奏对齐，例如迭代计划会前完成一次积压清理，评审会上确认新增字段的试用结论。
当待办条目从几十条增长到数百条，手工表格在状态联动、重复筛查和权限控制上会逐渐吃力。此时可以把模板字段迁移到协作工具中承载：ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，条目可按负责人分配并规划至迭代；ONES 工单可收集来自各方的反馈，处理后将工单转化为需求并整理成产品 Backlog，减少来源渠道字段的手工转录。对于功能复杂、需要拆分的条目，可利用子工作项拆解并关联研发和测试任务，使关联项字段中的父子关系在工具内直接可见。字段的具体可配置项以实际产品配置为准，迁移前建议先用少量条目验证字段映射。
常见问题
待办条目还很少的时候，有必要一开始就配齐全部字段吗？
不必一次配齐。可以先保留编号、标题、用户场景、状态、优先级、负责人六项，保证列表能排序、能交接；类型、所属模块、关联项、目标版本等字段在条目数量增加或出现跨团队协作时再补。判断标准是：当某个字段缺失已经导致重复讨论或排期争议时，就把它转为必填。
同一需求被多个客户提出，应该合并成一条还是分别记录？
建议保留一条主条目，在备注中记录提出方和频次，其余条目标注“重复于××”后关闭。合并时把不同客户的场景差异写进用户场景，把频次作为优先级判断的参考。如果不同客户对实现方式有实质分歧，可以拆成主条目加子条目，用关联项串起来，避免在一条记录里堆叠互相冲突的要求。
状态和优先级由谁维护，多久更新一次？
状态和优先级建议由条目负责人维护，产品负责人或需求管理员负责口径解释。更新时机与流程节点对齐：评审后改状态、排期后填目标迭代、优先级调整时同步修改。日常可以每两周或每个迭代开始前做一次集中检查，重点看长期停留在“待评估”的条目和优先级大量并列“高”的情况。
手工表格维护到多少条就该考虑迁移到协作工具？
没有固定阈值，常见信号是：状态与迭代计划需要手工同步、重复项靠人工比对、不同角色需要看到不同字段。出现这些情况时，可以把模板字段迁移到协作工具承载。ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，条目可分配负责人并规划至迭代；ONES 工单可收集各方反馈，处理后将工单转化为需求并整理成产品 Backlog。迁移前建议先用少量条目验证字段映射，具体可配置项以实际产品配置为准。
验收要点在粗粒度阶段写不出来怎么办？
粗粒度阶段可以先写一句方向性描述，例如“能按手机号搜到客户”，但要在状态推进到“已排期”之前补齐为可核验的条件。补齐的方法是把目标拆成几个可观察的结果：输入什么、返回什么、无结果时如何提示、数据与哪个页面保持一致。验收要点写不出来的条目，通常说明场景或目标还没想清楚，应先回到用户场景字段补充信息。
