产品功能清单把产品要做的事按功能逐行登记，写清给谁用、做到什么程度，供规划、评审和排期共用。本文交付一张可直接复制到表格工具的空白模板，并配套字段说明、必填与选填规则、一条完整填写示例和维护方法，四部分使用同一套字段。
要点总览（TL;DR）
- 空白模板按标识类、描述类、管理类三组排列，共12列；功能编号、功能名称、所属模块、目标用户、功能描述、优先级、状态、负责人8列必填，验收要点、关联需求、版本、备注4列选填。
- 必填的判断标准是缺少这一列评审或排期就无法进行；必填范围可按初稿、评审、开发中三个阶段调整，调整时在变更记录中写明生效时间和原因。
- 填写时一行只写一个可独立交付的功能，功能描述写用户动作与期望结果，验收要点写可核验的完成标志，方案细节留给后续设计文档。
- 优先级与状态使用统一枚举，同一张表内只保留一套取值，否则筛选和统计会失真。
- 模板落地后按版本存档快照，定期把已验收功能移入归档区，已搁置超过两个版本的功能由负责人确认去留，避免清单无限膨胀。
可复制的产品功能清单空白模板
下面这张表可以直接选中复制到 Excel、在线表格或文档表格中。表头保持一行，两行空白填写行用于试填，正式使用时按需增删行。列按三组排列：标识类在前，便于检索和引用；描述类居中，承载功能内容；管理类在后，记录优先级、状态与协作信息。
| 功能编号 | 功能名称 | 所属模块 | 目标用户 | 功能描述 | 验收要点 | 优先级 | 状态 | 负责人 | 关联需求 | 版本 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
复制后的基本处理有三步。第一，把表头设为冻结行，向下滚动时字段名始终可见。第二，为优先级、状态两列设置下拉选项，取值见第三节的枚举表，避免同义写法混用。第三，为功能编号列设置文本格式，防止类似 001 的编号被表格自动转成数字。若团队使用在线表格，可再开启按状态分组的视图，评审时按模块筛选查看。
列顺序可以按团队习惯微调，但建议标识类三列保持在最前，因为编号和名称是跨文档引用这张表时最常用的定位信息。描述类与管理类之间的顺序不影响使用，调整后同步更新字段说明即可。
每一列填什么：字段说明
字段说明与上面的空白模板一一对应，目的是让产品、设计、开发和测试对同一列的理解一致。下表给出每个字段的填写口径和一个反例，反例用于说明边界，不作为推荐写法。
| 分组 | 字段 | 填写口径 | 反例 |
|---|---|---|---|
| 标识类 | 功能编号 | 团队内唯一的短编号，建议“模块缩写-序号”，如 ORDER-012，创建后不随名称修改而变更 | 用“1”“2”“3”顺序编号，插入新功能后全部错位 |
| 标识类 | 功能名称 | 动词加对象的短名称，能独立指代一个功能，如“批量导出订单” | “订单相关”“优化一下”，无法判断具体做什么 |
| 标识类 | 所属模块 | 填写产品已有的模块名，与导航或信息架构保持一致 | 临时自造模块名，与产品结构对不上 |
| 描述类 | 目标用户 | 写具体角色或使用场景中的身份，如“仓库管理员”“首次注册的企业用户” | “所有用户”，等于没有限定 |
| 描述类 | 功能描述 | 写用户动作与期望结果，一到三句，说明在什么情况下做什么、得到什么 | 写按钮位置、接口字段、页面布局等方案细节 |
| 描述类 | 验收要点 | 写可核验的完成标志，如“导出文件包含筛选结果全部字段，千条以内 10 秒完成” | “体验流畅”“功能正常”，无法判断是否达标 |
| 管理类 | 优先级 | 从统一枚举中取值，反映相对顺序而非绝对日期 | 写“很急”“一般般”，或直接填一个日期 |
| 管理类 | 状态 | 从统一枚举中取值，反映该功能当前所处环节 | 同一列混用“开发中”“在做”“进行中”三种写法 |
| 管理类 | 负责人 | 填一个对这条功能推进负责的人，不填团队名 | 填“产品组”，出问题时无人对应 |
| 管理类 | 关联需求 | 填需求池中的需求编号或链接，说明这条功能来自哪个需求 | 把需求原文整段粘贴进来，清单变成需求文档 |
| 管理类 | 版本 | 填计划交付的版本号或迭代名，未排期时留空 | 提前填一个猜测的日期当作版本 |
| 管理类 | 备注 | 记录依赖、风险、待确认事项等不适合放进其他列的信息 | 把功能描述写不下的内容全部堆进备注 |
功能描述与验收要点容易写混，区分方法是：描述回答“用户做什么、得到什么”，验收要点回答“怎么判断做到了”。前者面向理解和评审，后者面向开发和测试。目标用户一列看似简单，实际最容易被敷衍，写具体角色能直接暴露功能是否服务了过多人群，从而在评审时引发必要的取舍讨论。
必填与选填怎么定
必填的判断标准是：缺少这一列，评审或排期就无法进行。按此标准，功能编号、功能名称、所属模块、目标用户、功能描述、优先级、状态、负责人八列必填，其余四列选填。选填不等于可随意省略，而是在功能尚未推进到相应环节时可以留空。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 功能编号 | 必填 | 跨文档引用和去重的依据，创建时即生成 |
| 功能名称 | 必填 | 评审时首先被读到的信息 |
| 所属模块 | 必填 | 决定分组查看与后续排期的归属 |
| 目标用户 | 必填 | 判断功能必要性的前提 |
| 功能描述 | 必填 | 没有描述无法评审 |
| 优先级 | 必填 | 排期的直接输入 |
| 状态 | 必填 | 跟踪进展和筛选视图的依据 |
| 负责人 | 必填 | 明确推进责任，避免悬空条目 |
| 验收要点 | 选填 | 进入开发前补齐即可，初稿阶段可先留空 |
| 关联需求 | 选填 | 功能来自明确需求时填写，探索性功能可暂缺 |
| 版本 | 选填 | 排期确定后填写，未排期留空 |
| 备注 | 选填 | 按需记录，无内容时留空 |
必填范围可以按阶段调整。初稿阶段允许目标用户和优先级先填粗值，重点是把功能名称和描述写清楚，先把候选功能列全；评审阶段要求八列必填全部到位，验收要点也应补齐，否则评审缺少判断依据；开发中阶段锁定编号、名称、描述和验收要点，避免开发过程中随意改口径，优先级和版本可随排期变化更新。每次调整必填范围，在模板的变更记录中写明生效时间和原因。
优先级与状态必须使用统一枚举，否则筛选和统计都会失真。下面是一套可直接采用的取值，团队可按自身节奏替换名称，但同一张表内只保留一套。
| 字段 | 取值 | 含义 |
|---|---|---|
| 优先级 | P0 | 本版本必须交付，缺失则版本目标不成立 |
| 优先级 | P1 | 本版本应交付，资源紧张时可协商延后 |
| 优先级 | P2 | 可延后到后续版本 |
| 优先级 | 待定 | 信息不足，需在评审中确定 |
| 状态 | 待评审 | 已登记，尚未通过评审 |
| 状态 | 已确认 | 评审通过，等待排期 |
| 状态 | 开发中 | 已进入开发 |
| 状态 | 已验收 | 验收要点全部满足 |
| 状态 | 已搁置 | 暂不推进，保留记录 |
填写示例：一条完整的功能记录
下面用一条已填写的记录示范各字段如何配合。示例为演示情景，团队名称与编号均为虚构。
| 字段 | 填写内容 |
|---|---|
| 功能编号 | ORDER-012 |
| 功能名称 | 批量导出订单 |
| 所属模块 | 订单管理 |
| 目标用户 | 仓库管理员、财务对账人员 |
| 功能描述 | 用户在订单列表按时间与状态筛选后，可将筛选结果一次性导出为表格文件，用于线下对账和发货核对 |
| 验收要点 | 导出文件包含筛选结果的全部字段；一千条以内 10 秒完成；无筛选条件时提示先选择范围 |
| 优先级 | P1 |
| 状态 | 已确认 |
| 负责人 | 张明 |
| 关联需求 | REQ-208 |
| 版本 | V2.3 |
| 备注 | 依赖订单列表筛选能力上线，需与数据组确认导出字段范围 |
逐项看填写思路。编号采用模块缩写加序号，后续插入新功能时不影响已有编号。名称用“批量导出订单”而非“导出优化”，一眼能看出动作和对象。目标用户写了两个具体角色，因为对账和发货核对是两种不同场景，这会影响导出字段的设计。功能描述只写用户动作和结果，没有写按钮放在哪、用什么格式实现，方案细节留给后续设计文档。验收要点把“导出正确”拆成字段完整、速度、边界提示三条可核验的标准，与描述形成分工：描述说明做什么，验收要点说明做到什么程度算完成。备注记录的是跨团队依赖，这类信息放进描述会干扰对功能本身的理解。
常见填写错误可以对照检查：一行写多个功能，例如把“导出订单”和“导出报表”合并成一条，导致状态和负责人无法分别跟踪；描述里塞入接口字段和页面布局，评审时讨论跑偏到方案细节；优先级写“紧急”而枚举中是 P0，筛选时漏掉；负责人填团队名，推进时无人认领；关联需求直接粘贴需求原文，清单膨胀成需求文档。发现这类问题时，优先拆行和改口径，而不是在备注里打补丁。
模板的调整与长期维护
模板落地一段时间后，团队会提出加字段的需求。新增字段的判断标准有两条：这一列是否会被反复查询或筛选；现有列是否已经承载了同类信息。两条都满足才新增，否则优先合并到现有列。例如“预计上线时间”和“版本”表达的是同一件事，保留版本列即可；“技术负责人”与“负责人”职责不同且都需要单独筛选时，才拆成两列。合并重复列时，先统一取值口径，再把内容迁移到保留列，最后删除旧列并在变更记录中注明。
版本与变更记录建议在清单之外单独维护一张小表，记录变更日期、变更内容、发起人和生效范围。字段增删、枚举调整、必填范围变化都属于需要记录的变更。清单本身按版本存档，例如每个版本评审通过后导出一份快照，后续调整在最新版上进行，历史快照只读保留，便于回溯某个功能当时的口径。
定期清理与归档按节奏执行：每个版本结束后，把已验收的功能标记完成并移入归档区，清单主表只保留待评审、已确认和开发中的条目；已搁置超过两个版本的功能，由负责人确认是删除还是转入长期观察，避免清单无限膨胀。清理时保留编号，不重复使用已归档的编号。
这张清单与相邻文档有明确边界。需求池记录需求的来源、背景和价值判断，功能清单只记录由需求拆出的功能条目，通过关联需求列建立对应；路线图记录版本层面的目标与时间安排，功能清单通过版本列挂接到路线图上，不重复描述版本目标。单个需求的价值评分、方案表达形式和原型评审流程属于其他环节，不在本表展开。清单进入多人协作后，状态流转、负责人变更和版本快照需要留痕，ONES 的工作项与文档能力可以承载这类管理动作，具体配置按团队实际环境确定。
常见问题
团队已经有需求池，功能清单和需求池要怎么分工，会不会重复维护？
两者记录的对象不同。需求池记录需求的来源、背景和价值判断，功能清单记录由需求拆出的功能条目，通过“关联需求”列建立对应关系。维护时需求池负责需求层面的取舍，功能清单负责功能层面的描述与状态跟踪，同一信息只在一处维护，另一处引用编号即可。若发现同一内容在两边反复填写，通常说明功能清单里混入了需求背景描述，应把这类内容退回需求池。
功能清单里的优先级和需求优先级不一致时，以哪个为准？
建议明确一条规则：需求优先级决定需求之间的先后，功能优先级决定同一需求拆出的功能之间的先后，两者层级不同，不直接比较。当某个功能的优先级与所属需求冲突时，以评审结论为准，并在备注中记录调整原因。若冲突频繁出现，说明拆分粒度过粗或优先级枚举定义不清，应先统一口径再继续使用清单。
一个功能横跨多个模块，所属模块列该怎么填？
优先按用户完成该功能时主要操作的模块填写，其余涉及的模块写入备注。如果功能确实需要多个模块协同且无法判断主次，说明这条功能可能拆得不够细，应尝试按用户动作拆成两条记录，各自归属模块并分别跟踪状态。强行在一行里填多个模块，会让按模块筛选的视图失真。
清单条目多到几百条后，怎么保证还能用？
靠状态和归档控制主表规模。每个版本结束后把已验收的功能移入归档区，主表只保留待评审、已确认和开发中的条目；已搁置超过两个版本的功能由负责人确认删除或转入长期观察。同时保持编号唯一且不复用，归档条目仍可按编号检索。条目数量本身不是问题，主表长期堆积已完成条目才是。
小团队也需要12列这么完整的模板吗？
可以精简，但建议保留8个必填列。小团队最容易省掉的是关联需求和版本，如果暂时没有需求池和版本规划，这两列留空即可，不必删除表头。验收要点在初稿阶段可以留空，进入开发前补齐。精简的原则是减少列数而不减少必填信息，否则评审时仍要口头补充，清单就失去了共用依据的作用。
