干系人承诺跟踪模板以“一条承诺一行”为基本结构，把来源、优先级、状态和变更分成四组字段：来源保证承诺可追溯，优先级支持排序，状态支持跟进，变更保证历史不被覆盖。下面给出一张可直接复制的空白表，并说明各字段怎么填、哪些必填、如何维护。
要点总览（TL;DR）
- 模板以“一条承诺一行”组织，来源、优先级、状态、变更四组字段分别解决可追溯、可排序、可跟进、可留痕的问题。
- 来源字段记录提出人、提出场合、提出日期和原始表述；优先级先评估影响程度与紧迫性，再给出P1/P2/P3结论。
- 状态统一为待确认、已承诺、进行中、已完成、已变更、已取消六种取值；状态回退时同步补一条变更记录。
- 必填字段以保证可跟踪为底线：承诺编号、承诺内容、提出人、提出日期、优先级结论、承诺状态；承诺人自“已承诺”起必填。
- 变更采用追加记录，写全变更日期、内容、原因、影响；承诺较多时拆出独立变更表，主表只留最近一次摘要。
可复制空白承诺跟踪表
将下表复制到文档或表格工具中即可使用。表头已覆盖来源、优先级、状态、变更四类字段，空白行按“一条承诺一行”填写，同一干系人提出的多条承诺分成多行记录。
| 承诺编号 | 承诺内容 | 提出人 | 提出场合 | 提出日期 | 原始表述 | 影响程度 | 紧迫性 | 优先级结论 | 承诺状态 | 承诺人 | 计划兑现日期 | 最近更新日期 | 变更日期 | 变更内容 | 变更原因 | 变更影响 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果项目承诺数量较多，建议把“变更日期、变更内容、变更原因、变更影响”拆到独立的变更记录表中，以承诺编号关联，主表只保留最近一次变更摘要。这样主表便于浏览，变更表保留完整历史。
字段说明：来源、优先级、状态、变更怎么填
字段说明与上表表头一一对应。填写口径在项目启动时确定一次，后续所有记录沿用同一口径，避免同一字段在不同人手里含义不同。
| 字段 | 所属类别 | 含义与填写口径 |
|---|---|---|
| 承诺编号 | 标识 | 项目内唯一编号，建议采用“项目缩写-序号”，便于在会议纪要和变更表中引用 |
| 承诺内容 | 标识 | 用一句话写清谁承诺做什么、交付什么，避免只写“支持”“配合”这类无法验收的表述 |
| 提出人 | 来源 | 提出该期望或承诺的具体人员，写姓名与角色，不写部门代称 |
| 提出场合 | 来源 | 记录提出时的场景，如启动会、需求评审、周例会、书面邮件，便于回溯上下文 |
| 提出日期 | 来源 | 期望首次提出的日期，用于判断承诺的时效和后续跟进间隔 |
| 原始表述 | 来源 | 尽量保留提出人的原话或原文摘录，后续转述、拆解时以原始表述为准，减少失真 |
| 影响程度 | 优先级 | 该承诺对项目目标、里程碑或交付质量的影响，可取值高、中、低，并附一句判断依据 |
| 紧迫性 | 优先级 | 承诺兑现的时间压力，可取值高、中、低，参考计划兑现日期与关键节点距离 |
| 优先级结论 | 优先级 | 综合影响程度与紧迫性给出的排序结论，如P1、P2、P3，作为跟进顺序依据 |
| 承诺状态 | 状态 | 承诺当前所处阶段，取值统一为待确认、已承诺、进行中、已完成、已变更、已取消 |
| 承诺人 | 状态 | 实际对兑现负责的人员，与提出人可能不同，需在状态转为“已承诺”时明确 |
| 计划兑现日期 | 状态 | 承诺人确认的兑现时间，状态推进和逾期判断以此为准 |
| 最近更新日期 | 状态 | 该行任何字段最后一次修改的日期，用于识别长期未更新的记录 |
| 变更日期 | 变更 | 本次调整发生的日期，追加记录，不覆盖此前记录 |
| 变更内容 | 变更 | 写清改了什么，如兑现日期从某日调整到某日、承诺范围缩小到某个模块 |
| 变更原因 | 变更 | 记录调整的实际原因，如资源调整、需求变化、外部依赖延迟 |
| 变更影响 | 变更 | 说明该变更对项目计划、其他承诺或干系人预期的影响，便于评估连锁反应 |
| 备注 | 补充 | 放置不便归入上述字段的补充信息，如关联的风险编号、相关会议纪要位置 |
状态字段的取值需要在团队内固定含义。“待确认”表示期望已记录但承诺人尚未明确接受；“已承诺”表示承诺人确认兑现内容和时间；“进行中”表示已开始投入；“已完成”表示交付物已被提出方确认接收；“已变更”表示原承诺内容或时间发生调整且已留痕；“已取消”表示承诺不再执行并说明原因。状态只向前推进，回退时同步写一条变更记录。
必填与选填的划分
必填字段以保证“能跟踪”为底线：没有它就无法判断这条承诺是谁提的、要做什么、当前到哪一步。选填字段按项目规模和治理要求补充，避免每张表都填满而增加负担。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 承诺编号 | 必填 | 唯一标识，变更记录和会议纪要引用都依赖它 |
| 承诺内容 | 必填 | 没有可验收的内容描述，跟踪无从谈起 |
| 提出人 | 必填 | 来源可追溯的最低要求 |
| 提出日期 | 必填 | 判断时效和跟进节奏的依据 |
| 优先级结论 | 必填 | 决定跟进顺序，缺失会导致所有承诺同等对待 |
| 承诺状态 | 必填 | 跟进工作的核心字段 |
| 承诺人 | 必填（状态为已承诺及以后） | 状态进入“已承诺”后必须有明确责任人 |
| 提出场合 | 选填 | 跨部门、多会议场景建议填写，单一渠道沟通的小项目可省略 |
| 原始表述 | 选填 | 承诺内容存在歧义或涉及合同、验收口径时建议保留原文 |
| 影响程度、紧迫性 | 选填 | 需要解释优先级结论时填写，小项目可直接给结论 |
| 计划兑现日期 | 选填（建议填写） | 有明确时间要求的承诺应填写，用于逾期提醒 |
| 变更日期、变更内容、变更原因、变更影响 | 选填（发生变更时必填） | 无变更时留空，一旦调整必须完整记录四项 |
| 备注 | 选填 | 按需补充关联信息 |
必填字段缺失时的处理方式：当场无法确认提出人的，先以“待补充”标记并在最近一次更新日期旁注明，下一次例会前补齐；承诺内容过于笼统的，退回提出人澄清后再入库，不带着模糊描述进入跟踪；优先级结论暂无法判断的，先按影响程度给出临时结论并标注“待复核”，在下次优先级评审时确认。
填写示例：一条完整承诺记录
以下是一条已填写记录，演示四类字段如何配合，以及状态推进和一次变更如何留痕。示例为演示情景，人员与项目名称均为虚构。
| 字段 | 填写内容 |
|---|---|
| 承诺编号 | XM-012 |
| 承诺内容 | 由测试组在联调开始前提供接口自动化测试脚本，覆盖订单创建与支付回调两个流程 |
| 提出人 | 李敏（测试组负责人） |
| 提出场合 | 3月第2周项目周例会 |
| 提出日期 | 3月11日 |
| 原始表述 | “联调前我们可以把订单和支付回调的自动化脚本先给到开发，其他流程后面再补。” |
| 影响程度 | 高：联调阶段回归效率直接依赖该脚本 |
| 紧迫性 | 高：联调计划于3月25日开始 |
| 优先级结论 | P1 |
| 承诺状态 | 已变更 |
| 承诺人 | 李敏 |
| 计划兑现日期 | 3月24日（变更后） |
| 最近更新日期 | 3月18日 |
| 变更日期 | 3月18日 |
| 变更内容 | 交付范围由两个流程缩减为订单创建一个流程，兑现日期由3月22日调整为3月24日 |
| 变更原因 | 支付回调依赖的沙箱环境延迟开放，测试组优先保障订单创建流程 |
| 变更影响 | 支付回调相关回归需在联调第二周补做，需同步通知开发组调整联调排期 |
| 备注 | 关联风险R-07（沙箱环境交付延迟） |
这条记录的推进过程是：3月11日例会提出后，状态记为“待确认”；3月12日李敏确认范围和日期，状态转为“已承诺”；3月15日脚本开始编写，状态转为“进行中”；3月18日因环境问题调整范围与日期，状态转为“已变更”，同时追加变更四项字段。原始表述和提出日期保持不变，任何人回看都能知道这条承诺最初是怎么来的、中间改过什么。
当承诺跟踪表需要多人协作维护时，可以把表格放在支持模板库、版本记录和权限控制的文档工具中。ONES Wiki 支持使用模板库一键创建文档，并记录页面版本、支持查看与回滚，适合承载承诺表及其变更历史；页面组可关联项目，便于把承诺记录与对应项目文档放在一起。状态推进和变更留痕的管理动作，也可以借助 ONES ALM 方案中对变更影响分析和过程状态追踪的管理方式，把承诺调整与需求、版本变更放在同一条线索上对照。具体使用方式以实际产品配置为准。
模板的调整与维护方法
模板首次填写完成后，长期可用取决于字段取舍、状态口径和变更维护节奏是否稳定。以下清单可直接作为项目内的模板维护操作依据。
字段增减的取舍原则
- 新增字段前先问：这个字段是否会影响跟进动作或判断结论。只用于记录、不影响任何后续动作的字段，优先放入备注。
- 承诺数量在20条以内的小项目，可省略影响程度、紧迫性两列，直接保留优先级结论；跨部门、多供应商项目建议保留分项评估。
- 变更频繁的项目，把变更四列拆到独立变更表，主表只留最近一次变更摘要，避免主表过宽难以阅读。
- 删除字段前确认历史记录已归档，已填写的数据不因字段删除而丢失。
状态取值如何统一
- 项目启动时把六个状态取值及含义写入模板说明页，新成员入项时先读说明再填表。
- 状态变更由承诺人或其指定的跟进人操作，其他人员只读，减少口径不一致。
- 每次状态变更同步更新最近更新日期；状态回退必须同时写变更记录。
- 每月抽查一次状态与实际进展是否一致，重点检查长期停留在“进行中”的记录。
变更记录的维护节奏
- 变更发生时即时记录，不等到例会再补，避免原因和影响被遗忘。
- 每次变更四项字段一次写全，缺项视为记录不完整，在下次复核时补齐。
- 涉及里程碑或对外承诺的变更，当天同步给受影响的干系人，并在备注中注明通知时间。
定期复核与归档方式
- 每周例会用优先级结论排序过一遍P1承诺，确认状态和计划兑现日期是否仍然有效。
- 每月做一次全表复核：清理已完成的记录、补齐缺失的必填字段、核对变更记录完整性。
- 项目阶段结束时，将已完成和已取消的承诺移入归档表，主表只保留仍在推进的记录。
- 归档时保留承诺编号、原始表述和全部变更记录，便于项目复盘和后续审计追溯。
按上述节奏维护，模板在项目周期内保持字段稳定、状态口径一致、变更历史完整，新加入的成员也能依据表内记录快速接手跟进。
常见问题
承诺内容写得太笼统，已经入库了怎么办？
退回提出人澄清后再更新该行，不带着模糊描述继续跟踪。澄清时把“支持”“配合”这类表述改成可验收的动作和交付物，例如“由测试组在联调前提供订单创建流程的自动化脚本”。更新后同步修改最近更新日期，原始表述字段保留提出人最初的说法，便于对照。
同一干系人在不同会议上重复提出同一期望，需要记多行吗？
按承诺对象判断，不按提出次数判断。如果指向同一件事、同一兑现范围，合并为一行，在提出场合中补充后续会议，原始表述保留最早一次的原话。如果后续提出扩大了范围或改变了时间，则视为一次变更，在变更字段中追加记录，不新增行。
承诺状态可以回退吗？比如从“进行中”退回“待确认”。
可以回退，但必须同时写一条变更记录，说明回退原因和影响。常见情形是承诺人对范围产生异议，需要重新确认。回退后状态改为“待确认”，变更内容写清从哪个状态退回、涉及哪些条款，避免其他人看到状态变化却不知道发生了什么。
变更记录放在主表里还是单独建表？
看变更频率和承诺数量。承诺在20条以内、变更不多的项目，主表保留变更四列即可。承诺数量多或变更频繁时，把变更四列拆到独立变更表，以承诺编号关联，主表只留最近一次变更摘要。拆表后主表便于浏览，变更表保留完整历史，归档时两张表一起保留。
多人协作维护这张表时，如何避免状态被随意改动？
先约定操作权限：状态变更由承诺人或其指定的跟进人操作，其他人员只读。再把六个状态取值的含义写入模板说明页，新成员入项时先读说明。工具层面可借助文档工具的权限配置区分读写角色，ONES Wiki 支持为多种角色配置不同的读写权限，并记录页面版本、支持查看与回滚，便于核对改动。
