需求关闭记录要解决两个问题：关得清楚，关得可追溯。模板建议分成三块——关闭原因分类、关闭结论、价值反馈，分别回答“为什么关”“关得是否达标”“关完产生了什么变化”。下面给出一张可直接复制使用的空白表，并逐项说明字段口径、必填规则、完整示例与后续维护方法。
要点总览（TL;DR）
- 关闭原因采用两级枚举：一级固定为完成交付、主动取消、重复合并、无法实现、转其他需求、外部原因六类，二级用短文本写具体情形，另留自由文本备注位。
- 关闭结论按单项需求的验收结果分已满足、部分满足、未满足三档，每档必须配一句话依据，写明验收方式或证据位置。
- 价值反馈设受益对象、变化前、变化后、数据来源、观察时点、后续动作六个字段，记录可观察的变化，不承担产品整体效果评估。
- 必填与条件必填按关闭原因触发：取消类必须写原因说明，重复合并类必须填合并去向，完成交付类必须填结论与价值反馈核心字段。
- 模板落地后按枚举增删审批、字段新增触发条件、版本记录与季度回看分类分布来维护，避免枚举膨胀和字段失效。
可复制的需求关闭记录空白模板
下表可直接复制到文档或表格工具中，按行填写。字段编号与后文字段说明、填写示例一一对应，调整模板时请同步修改编号。
| 编号 | 字段 | 填写内容 |
|---|---|---|
| 01 | 需求编号与名称 | |
| 02 | 需求提出方 | |
| 03 | 关闭日期 | |
| 04 | 关闭原因一级分类 | □完成交付 □主动取消 □重复合并 □无法实现 □转其他需求 □外部原因 |
| 05 | 关闭原因二级情形 | |
| 06 | 原因备注（自由文本） | |
| 07 | 关闭结论 | □已满足 □部分满足 □未满足 |
| 08 | 结论依据（一句话） | |
| 09 | 受益对象 | |
| 10 | 变化前 | |
| 11 | 变化后 | |
| 12 | 数据来源 | |
| 13 | 观察时点 | |
| 14 | 后续动作 | |
| 15 | 关联记录 | |
| 16 | 填写人与复核人 |
使用说明：04、05、07、08、09为常规必填项，10–14按关闭原因条件必填，具体规则见第四节。15用于填写关联的验收记录、合并去向或替代需求编号，16记录责任人与复核人，便于追溯。
关闭原因分类怎么设：一级枚举与二级情形
关闭原因建议采用两级枚举：一级分类固定取值，保证统计口径统一；二级情形用短文本补充具体原因，兼顾灵活性与可分析性。只设自由文本会导致同类原因写法各异，无法汇总；只设一级枚举又过于笼统，复盘时看不出真实原因，两级结构是折中方案。
| 一级分类 | 含义 | 二级情形示例 |
|---|---|---|
| 完成交付 | 需求已实现并交付使用 | 全量上线、灰度上线、按范围交付 |
| 主动取消 | 提出方或业务方决定不再推进 | 业务方向调整、优先级下降、预算取消 |
| 重复合并 | 与其他需求重复或并入其他需求 | 与某需求重复、合并至某需求 |
| 无法实现 | 受技术、合规或资源限制无法落地 | 技术不可行、合规限制、资源不足 |
| 转其他需求 | 拆分为新需求或转入其他团队处理 | 拆分为多个需求、转交其他产品线 |
| 外部原因 | 由外部依赖或环境变化导致关闭 | 依赖方变更、政策调整、供应商退出 |
取值规则有三条。第一，一级分类只能从枚举中选择，新增取值需走审批，避免个人随手添加。第二，二级情形用简短词组描述，同一团队内保持写法一致，例如统一写“与需求XXX重复”而非多种表述。第三，06原因备注保留自由文本，用于补充背景、决策过程和链接，不承担统计职能。
分类与关闭结论存在对应关系：完成交付类通常对应“已满足”或“部分满足”；主动取消、重复合并、转其他需求类通常对应“未满足”，并在依据中写明去向；无法实现与外部原因类按实际交付情况判定。分类回答“为什么关”，结论回答“关得是否达标”，两者分开填写，避免用原因替代结论。
关闭结论与价值反馈字段说明
关闭结论以单项需求的验收结果为准，判定口径如下：已满足指需求描述的目标全部达成并有依据；部分满足指核心目标达成、部分范围未交付或效果打折；未满足指目标未达成即关闭，需在依据中说明原因。结论必须配一句话依据，写明验收方式或证据位置，例如“按验收清单逐项通过”或“仅完成A场景，B场景延后”。
| 字段 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 受益对象 | 需求交付后直接受益的角色或群体 | 写具体角色或业务单元，不写“全体用户” | 客服一线坐席 |
| 变化前 | 关闭前的可观察状态 | 写事实或数据，不写感受 | 平均每单查询耗时约4分钟 |
| 变化后 | 关闭后的可观察状态 | 与变化前同一口径对比 | 平均每单查询耗时约2分钟 |
| 数据来源 | 支撑变化前后数据的出处 | 写系统报表、抽样记录或访谈记录名称 | 客服工单系统月度报表 |
| 观察时点 | 数据采集的时间范围 | 写具体日期或区间 | 上线后第2周 |
| 后续动作 | 关闭后需要跟进的事项 | 写动作与责任方，无则填“无” | 下季度复测一次，产品经理跟进 |
价值反馈只记录本需求直接带来的可观察变化，用于单项需求的闭环说明。产品整体效果评估、多需求综合价值判断属于另一层工作，不在此表展开。字段之间存在引用关系：09受益对象决定10、11的观察范围；12数据来源与13观察时点共同支撑10、11的可信度；14后续动作承接观察中发现的遗留问题，可关联到新需求编号。
必填与选填：哪些字段不能空
必填字段保证每条关闭记录都能被追溯和统计，选填字段为补充信息留出空间。规则按关闭原因触发，不同原因下要求不同。
| 字段 | 属性 | 规则说明 |
|---|---|---|
| 01–03 基本信息 | 必填 | 无编号、提出方或日期则记录无法定位 |
| 04 一级分类 | 必填 | 统计与复盘的基础 |
| 05 二级情形 | 必填 | 补充具体原因，避免一级分类过于笼统 |
| 06 原因备注 | 选填 | 需要背景说明或链接时填写 |
| 07 关闭结论 | 必填 | 所有关闭记录都要有结论 |
| 08 结论依据 | 必填 | 结论需有可核对的依据 |
| 09 受益对象 | 条件必填 | 完成交付、部分满足时必填 |
| 10–13 变化前后与来源时点 | 条件必填 | 完成交付且已产生可观察结果时必填；尚无数据可填“待观察”并写明计划时点 |
| 14 后续动作 | 条件必填 | 部分满足、未满足、转其他需求时必填，写明跟进事项 |
| 15 关联记录 | 条件必填 | 重复合并填合并去向，转其他需求填新需求编号 |
| 16 填写人与复核人 | 必填 | 明确责任，便于回溯 |
条件必填的典型场景：主动取消类必须在05或06写明取消原因和决策人；重复合并类必须填15指向被合并的需求；无法实现类必须在08写明限制条件。留空表示该字段不适用或尚未填写，填“无”表示已确认不存在该项内容，两者含义不同，团队需统一约定并在模板说明中注明。
填写示例：一条完整的需求关闭记录
示例背景：客服团队提出“工单查询页支持按客户编号快速检索”，以减少坐席在多系统间切换的时间。以下为按模板填写的完整记录。
| 编号 | 字段 | 填写内容 |
|---|---|---|
| 01 | 需求编号与名称 | REQ-2317 工单查询页支持按客户编号快速检索 |
| 02 | 需求提出方 | 客服运营组 |
| 03 | 关闭日期 | 2025-03-14 |
| 04 | 关闭原因一级分类 | 完成交付 |
| 05 | 关闭原因二级情形 | 全量上线 |
| 06 | 原因备注 | 3月10日全量发布，无回滚 |
| 07 | 关闭结论 | 已满足 |
| 08 | 结论依据 | 按验收清单逐项通过，检索命中率与响应时间均达标 |
| 09 | 受益对象 | 客服一线坐席 |
| 10 | 变化前 | 平均每单查询耗时约4分钟，需切换两个系统 |
| 11 | 变化后 | 平均每单查询耗时约2分钟，单页完成检索 |
| 12 | 数据来源 | 客服工单系统月度报表与坐席抽样记录 |
| 13 | 观察时点 | 上线后第2周 |
| 14 | 后续动作 | 下季度复测一次耗时数据，产品经理跟进 |
| 15 | 关联记录 | 验收记录 ACC-088 |
| 16 | 填写人与复核人 | 产品经理李某 / 客服运营组王某 |
逐项说明：04与05配合说明关闭性质为正常交付；07与08构成结论与证据的对应，避免只写“已满足”而无依据；09–13形成一条可核对的价值链，受益对象明确、前后口径一致、来源与时点可查；14承接复测计划，防止关闭后无人跟进；15、16保证记录可追溯。若该需求只完成部分场景，则07填“部分满足”，08写明未覆盖范围，14写明补齐计划。
模板的调整与维护方法
模板落地后需要定期维护，否则枚举会膨胀、字段会失效。建议按以下清单执行。
- 枚举增删走审批：新增一级分类需说明现有分类为何无法覆盖，由需求管理负责人确认后统一发布；删除或合并分类前先统计历史使用量，保留映射关系。
- 字段新增设触发条件：同一类补充信息连续多次出现在06备注中，或多次因缺少某字段导致复盘困难时，才考虑新增字段，并同步更新编号与说明。
- 版本与历史记录：每次调整记录版本号、调整内容和生效日期，历史记录按原版本保留，不追溯改写已关闭需求。
- 定期回看：每季度统计各一级分类的分布、二级情形的集中度、10–14的填写率，填写率长期偏低的字段考虑改为选填或删除，分类过度集中的考虑细化二级情形。
当关闭记录需要在工作项状态流转中承载时，可将上述字段配置到需求工作项的关闭环节：状态流转到关闭时触发必填校验，关闭原因与结论作为结构化字段沉淀，价值反馈随记录归档。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，构建需求—任务—测试—缺陷的全流程闭环，并可通过模板、权限和流程配置平衡短期交付与长期产品价值；关闭记录模板可作为其中一环，与验收记录一并留存在需求条目下。若团队使用 ONES Wiki 沉淀模板，页面模板库支持一键创建制式化文档模板，页面组可关联项目使需求与文档互相对应，页面版本记录支持随时查看与回滚，便于维护模板的历史版本。
常见问题
需求关闭原因只设一级分类够不够，什么情况下需要加二级情形？
一级分类负责统计口径，二级情形负责说明具体原因。当同一一级分类下的关闭原因差异较大、复盘时需要区分时，就应补充二级情形。例如“主动取消”下可以区分业务方向调整、优先级下降、预算取消；如果团队关闭量很小、原因单一，也可以先只填一级分类加备注，等出现无法归类的记录再细化二级。判断标准是：季度回看时，一级分类的分布能否支撑你做出判断，不能则细化。
需求关闭后才发现价值数据还没出来，价值反馈字段怎么填？
可以填“待观察”，并在观察时点写明计划采集的时间，在后续动作里写明由谁在什么时间补录。不要为了填满字段而写主观评价或估算数字。等数据出来后回填变化前、变化后、数据来源三个字段，并保留原记录。若观察期结束后仍无数据，应在后续动作中说明原因，例如样本不足或指标未上线，避免记录长期悬空。
关闭原因分类和关闭结论会不会重复，能不能只填一个？
两者回答不同问题，建议分开填写。关闭原因回答“为什么关”，例如主动取消、重复合并；关闭结论回答“关得是否达标”，例如已满足、部分满足、未满足。一条主动取消的需求，结论通常是未满足，但原因和结论的信息不能互相替代。只填原因，统计时看不出交付质量；只填结论，复盘时看不出关闭动因。两者配合，才能支撑后续的分类统计和复盘。
模板里的字段要不要全部搬进需求管理工具，还是保留在文档里？
取决于记录的使用方式。需要按关闭原因统计分布、按结论筛选需求、在状态流转时强制校验的字段，适合配置到需求工作项上，例如关闭原因一级分类、关闭结论、结论依据。背景说明、决策过程、链接等长文本内容，适合留在文档或备注中。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，构建需求—任务—测试—缺陷的全流程闭环，并可通过模板、权限和流程配置平衡短期交付与长期产品价值；ONES Wiki 的页面模板库支持一键创建制式化文档模板，页面组可关联项目，页面版本记录支持随时查看与回滚，适合沉淀模板与历史版本。具体字段能否配置为条件必填，需以实际环境验证。
模板用了一段时间后，一级分类越加越多怎么办？
先统计各分类的历史使用量，把长期低频、含义重叠的分类合并，并保留新旧映射关系，历史记录按原版本保留、不追溯改写。新增分类要求说明现有分类为何无法覆盖，由需求管理负责人确认后统一发布。同时检查二级情形是否承担了本该由一级分类承担的区分职能，必要时把高频二级情形上升为一级分类，再重新观察一个季度。
