产品功能清单要能同时回答“有哪些功能、给谁用、做到什么程度、由谁负责”。一张可复制的表格应包含功能编号、功能名称、所属模块、功能描述、用户角色、使用场景、优先级、实现状态、版本归属、负责人、验收标准、依赖关系和备注等字段，其中编号、名称、模块、描述、优先级、状态建议设为必填。以下模板、字段说明、必填对照和填写示例保持同一套字段，可直接复制到表格工具中使用。
要点总览（TL;DR）
- 产品功能清单建议包含13个字段：功能编号、功能名称、所属模块、功能描述、用户角色、使用场景、优先级、实现状态、版本归属、负责人、验收标准、依赖关系、备注。
- 功能编号、名称、所属模块、功能描述、优先级、实现状态建议设为必填，其余字段按团队阶段逐步补充。
- 字段调整的判断依据是：缺少该信息是否会导致清单无法被正确理解或跟踪；进入多版本并行阶段后，版本归属和负责人可转为必填。
- 示例中已上线功能写明版本号，开发中功能写计划版本，未排期功能版本留空、负责人写待定，避免用虚构信息占位。
- 维护时保持编号不复用、状态随阶段更新、版本归档不覆盖，并在版本评审中核对优先级、版本归属和依赖关系。
可复制的产品功能清单空白模板
下面这张表按模块分组呈现，复制到表格工具后，把“模块”列相同取值放在连续行，即可形成分组视图。空白行保留全部字段，便于逐条填写。
| 功能编号 | 功能名称 | 所属模块 | 功能描述 | 用户角色 | 使用场景 | 优先级 | 实现状态 | 版本归属 | 负责人 | 验收标准 | 依赖关系 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| F-001 | ||||||||||||
| F-002 | ||||||||||||
| F-003 | ||||||||||||
| F-004 | ||||||||||||
| F-005 |
按模块分组时，建议先确定模块清单，再在模块内按功能编号顺序排列。模块名称保持稳定，避免同一模块出现“订单”“订单管理”“订单中心”等多种写法，否则后续筛选和统计会失真。若团队使用在线表格，可冻结表头并为“所属模块”“实现状态”“版本归属”设置筛选，方便按模块或版本查看功能布局。
每个字段记录什么信息
字段的含义需要在团队内形成统一口径，否则同一列在不同人手里会填出不同含义。下表逐字段说明记录内容、填写口径和示例值。
| 字段 | 记录什么 | 填写口径 | 示例值 |
|---|---|---|---|
| 功能编号 | 功能的唯一标识 | 按“前缀-序号”编制，一经分配不复用；删除功能时保留编号并标注停用 | F-012 |
| 功能名称 | 功能的简短称呼 | 用动宾结构或名词短语，控制在十余字内，避免把描述塞进名称 | 批量导出订单 |
| 所属模块 | 功能归属的产品模块 | 从既定模块清单中选择，不临时新造；跨模块功能归入主要承载模块 | 订单管理 |
| 功能描述 | 功能做什么、解决什么问题 | 用一到三句话说明输入、处理和输出，写清边界，不写实现方案 | 支持按时间范围筛选订单并导出为表格文件 |
| 用户角色 | 主要使用者 | 填写角色名称而非具体人名，多个角色用顿号分隔 | 运营专员、财务专员 |
| 使用场景 | 用户在什么情况下使用 | 描述触发条件和目标，一句话即可 | 月末对账前批量获取订单明细 |
| 优先级 | 功能在规划中的相对位置 | 使用统一档位，如高、中、低，并约定每档含义 | 高 |
| 实现状态 | 功能当前进展 | 从固定状态集合中选择，如待规划、设计中、开发中、测试中、已上线、已停用 | 开发中 |
| 版本归属 | 功能计划或实际发布的版本 | 填写版本号或版本名称，未排期时留空并注明待排期 | V2.3 |
| 负责人 | 对该功能条目负责的人 | 填写具体责任人，一个功能只设一名负责人 | 张明 |
| 验收标准 | 判断功能完成的条件 | 写成可核验的条件，避免“体验良好”这类无法判断的表述 | 导出文件字段与列表一致，万条数据导出在约定时间内完成 |
| 依赖关系 | 该功能依赖的其他功能或外部条件 | 填写被依赖功能的编号，多个用逗号分隔 | F-008 |
| 备注 | 补充信息 | 记录变更原因、待确认事项或相关文档位置 | 导出格式待与财务确认 |
字段之间存在关联：功能编号被依赖关系引用，因此编号必须唯一且稳定；实现状态与版本归属配合使用，才能区分“计划在某个版本”与“已在某个版本上线”；验收标准与功能描述对应，描述界定范围，验收标准界定完成。填写时先写描述，再据此提炼验收标准，可以减少两者脱节。
哪些字段必填、哪些可以选填
必填字段保证清单具备基本的识别、定位和跟踪能力；选填字段按团队阶段和管理需要逐步补充。字段过多会增加填写负担，导致清单长期不更新，因此建议从最小集合起步。
| 类别 | 字段 | 取舍依据 |
|---|---|---|
| 必填 | 功能编号 | 唯一标识，支撑引用和去重 |
| 必填 | 功能名称 | 没有名称无法识别条目 |
| 必填 | 所属模块 | 支撑按模块查看功能布局 |
| 必填 | 功能描述 | 界定功能范围，避免同名不同义 |
| 必填 | 优先级 | 支撑规划排序和取舍讨论 |
| 必填 | 实现状态 | 反映当前进展，是清单的核心状态信息 |
| 选填 | 用户角色 | 角色复杂时补充，单一角色产品可省略 |
| 选填 | 使用场景 | 有助于评审时理解背景，条目多时可精简 |
| 选填 | 版本归属 | 进入排期后填写，早期规划阶段可留空 |
| 选填 | 负责人 | 进入设计或开发阶段后必填，规划阶段可暂缺 |
| 选填 | 验收标准 | 进入开发前补齐，早期条目可先写要点 |
| 选填 | 依赖关系 | 存在跨功能依赖时填写 |
| 选填 | 备注 | 按需记录，不强制 |
按团队阶段调整时，可以遵循一条原则：字段是否必填，取决于没有它是否会导致清单无法被正确理解或跟踪。产品早期条目少、变化快，可只保留六个必填字段，加快录入；进入多版本并行阶段后，把版本归属和负责人转为必填，避免功能无人跟进；进入交付阶段后，把验收标准转为必填，让完成有明确判断依据。每次调整必填范围，应在团队内同步并回填历史条目，避免新旧口径混用。
一份填好的功能清单示例
以下示例展示同一模块下三条功能如何协同填写，字段与前面的模板和说明一一对应。
| 功能编号 | 功能名称 | 所属模块 | 功能描述 | 用户角色 | 使用场景 | 优先级 | 实现状态 | 版本归属 | 负责人 | 验收标准 | 依赖关系 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| F-010 | 订单列表筛选 | 订单管理 | 支持按时间范围、订单状态和客户名称组合筛选订单列表 | 运营专员 | 日常查询特定状态订单 | 高 | 已上线 | V2.2 | 李华 | 三个筛选条件可任意组合，结果与条件一致 | 已随 V2.2 发布 | |
| F-011 | 订单批量导出 | 订单管理 | 将当前筛选结果导出为表格文件，字段与列表列一致 | 运营专员、财务专员 | 月末对账前批量获取订单明细 | 高 | 开发中 | V2.3 | 张明 | 导出文件字段与列表一致，万条数据导出在约定时间内完成 | F-010 | 导出格式待与财务确认 |
| F-012 | 导出任务记录 | 订单管理 | 记录每次导出的操作人、时间和数据范围，供后续查询 | 运营专员 | 需要追溯历史导出操作时 | 中 | 待规划 | 待定 | 可按操作人和时间查询导出记录 | F-011 | 依赖导出功能上线后再排期 |
示例中的状态与版本写法值得注意：F-010 已上线并写明版本 V2.2，状态与版本相互印证；F-011 处于开发中，版本归属写计划版本 V2.3，表示计划而非已发布；F-012 尚未排期，版本归属留空，负责人写“待定”，避免用虚构版本号占位。依赖关系用功能编号引用，F-011 依赖 F-010，F-012 依赖 F-011，形成可追溯的先后顺序。备注列记录待确认事项，让清单之外的信息有落点。
清单的调整与日常维护方法
功能清单会随产品演进不断变化，维护的重点是保持字段口径一致、状态及时更新、历史版本可追溯。以下规则可作为团队日常维护的检查依据。
- 字段增删有判断依据：当某一信息被反复写进备注列，说明它值得独立成列；当某字段长期空白或无人查看，考虑合并或删除。增删字段时同步更新字段说明和必填范围。
- 状态更新有节奏：功能进入设计、开发、测试、上线各阶段时更新实现状态，并在状态变化时补填版本归属。建议在每次版本发布后集中核对一次，避免状态停留在旧值。
- 版本归档有规则：已上线功能保留版本归属，不因后续版本迭代而覆盖；停用功能保留编号，状态改为已停用并在备注写明原因，编号不复用。
- 评审机制有固定动作：在版本规划评审中逐条核对优先级、版本归属和依赖关系；在开发启动前核对验收标准是否可判断。
- 责任人机制清晰：每条功能只设一名负责人，负责维护该条目的状态和描述；模块层面可设一名模块负责人，统一模块内命名和分组。
当清单条目增多、多人同时更新时，表格容易出现状态不同步、版本信息分散的问题。可以把功能清单作为工作项集中管理：每条功能对应一个工作项，编号、名称、模块、描述、优先级作为固定字段，实现状态随工作项流转自动变化，版本归属和负责人作为责任人字段维护，验收标准写在条目内并在评审时核对。ONES 的工作项自定义字段与状态流转可以承载这类结构，文档协作方式则适合存放字段说明和填写规范，让模板、字段口径和实际条目保持在同一处可查。选择承载方式时，以团队能否稳定更新状态和追溯版本为主要判断标准。
常见问题
功能清单里的功能编号需要一直保留吗？功能下线后可以删掉吗？
建议保留。功能编号是清单中唯一且稳定的标识，依赖关系、备注和外部文档都可能引用它。功能下线时，把实现状态改为“已停用”，在备注中写明停用原因和时间，编号不再分配给其他功能。这样历史记录仍可追溯，也不会出现同一编号指向两个功能的情况。
团队刚开始做功能清单，字段太多填不过来怎么办？
可以先只保留六个必填字段：功能编号、功能名称、所属模块、功能描述、优先级、实现状态。这六项能保证清单具备识别、定位和跟踪能力。等条目增多、进入多版本并行阶段后，再把版本归属和负责人转为必填；进入交付阶段后，把验收标准转为必填。每次调整必填范围时同步回填历史条目，避免新旧口径混用。
功能清单和需求池是一回事吗？
两者关注点不同。功能清单呈现产品功能布局与状态，回答“有哪些功能、属于哪个模块、做到什么程度”；需求池侧重收集和评估待处理需求。实际工作中可以让功能清单中的条目对应到需求或工作项，但清单本身不必承载需求价值评分和优先级评估方法，这些内容适合在需求管理流程中处理。
多人同时更新功能清单，状态经常不同步，有什么办法？
先明确每条功能只设一名负责人，由负责人维护该条目的状态和描述；模块层面可设模块负责人，统一模块内命名和分组。状态更新可以绑定固定节点，例如进入设计、开发、测试、上线时各更新一次，并在每次版本发布后集中核对。条目较多时，可以把功能清单作为工作项集中管理，让状态随工作项流转变化，减少手工同步。
验收标准写到什么程度才算可判断？
验收标准应写成可核验的条件，避免“体验良好”“运行稳定”这类无法判断的表述。可以从功能描述中提炼：描述界定了功能范围，验收标准界定完成条件。例如“支持按时间范围筛选订单并导出”对应的验收标准可以是“筛选结果与条件一致，导出文件字段与列表列一致”。进入开发前补齐验收标准，评审时逐条核对是否可判断。
