需求排期表和实现进展对不上，先别急着改表。更有效的做法是先判断脱节属于哪一类：日期没跟上、状态停在旧值、关键字段缺失，还是两处口径不同。确认症状后，抽取近期一批需求，把排期表字段与实现侧的工作项状态、时间、负责人逐条对照，找出差异集中的环节，再用证据排除原因，最后处置并复检。
要点总览（TL;DR）
- 先给脱节分类：日期不符、状态停滞、字段缺失、口径不一致，四类问题的处置方式不同，混在一起改容易反复。
- 抽取近一到两个迭代内已启动或已完成的需求做样本，把排期表字段与实现侧工作项状态、时间、负责人逐条对照，记录差异类型与频次。
- 原因排除靠证据：更新责任是否落到角色、信息是否分处两地、状态定义是否一致、变更是否只改一处，每类都要找到可验证的记录。
- 处置时先建立字段对应关系、指定更新责任人与时点、统一状态口径，历史差异一次性校准前备份原表，口径争议未解决时暂停批量修改。
- 用同一批样本复检确认差异清零或可解释，再设定固定核对节奏与抽查比例，把更新动作嵌入需求流转节点。
脱节在排期表上通常表现成什么样
排期表与实现进展脱节，表面看都是“表不准”，实际包含几种不同问题。先分类，才能避免用同一种办法处理所有不一致。下面四类症状可以作为自查起点。
| 症状类型 | 排期表上的表现 | 实现侧的表现 | 常见误判 |
|---|---|---|---|
| 日期不符 | 计划开始、计划完成日期长期未调整，或实际已开始、已完成但日期仍为空 | 工作项已有实际开始时间、完成时间，或已进入开发、测试状态 | 把日期滞后当成执行延期，实际是表未更新 |
| 状态停滞 | 状态字段停留在“待排期”“进行中”等旧值 | 工作项已流转到开发中、待测试、已完成 | 把状态差异当成两套流程，实际是同步遗漏 |
| 字段缺失 | 排期表只有需求名称、负责人和日期，缺少实现进展所需的状态、关联任务、评审结论等字段 | 实现侧有任务拆解、提交记录、评审记录，但排期表无法承载 | 认为排期表“够用”，实际无法支撑进展判断 |
| 口径不一致 | “完成”指开发完成，或指上线，或指验收通过，表中未说明 | 工作项状态按开发、测试、发布分别定义 | 同一需求两处都写“完成”，含义却不同 |
自查时可以先看差异是否集中在某一类。如果多数需求只是日期没改，问题偏向更新机制；如果状态叫法在两处不同，问题偏向字段定义；如果排期表根本放不下实现进展信息，问题偏向表格结构。把症状归类后，再进入样本对照，检查才有明确目标。
逐条对照：用样本找出差异出在哪一环
样本对照的目的，是用一批近期需求验证差异到底出现在哪个字段、哪个流转节点，避免凭印象判断“整张表都不准”。样本量不必很大，选取近一到两个迭代内已启动或已完成的需求，覆盖不同负责人和不同需求类型即可。
对照操作步骤
- 确定样本清单。从排期表中选取近期若干条需求，记录需求编号、名称、当前排期表状态和日期。
- 打开实现侧对应记录。按需求编号找到对应工作项，读取其当前状态、实际开始时间、实际完成时间、负责人、关联任务和最近一次评审记录。
- 逐字段比对。排期表的计划日期与实现侧的实际日期比对，排期表状态与工作项状态比对，负责人两处比对，关联任务是否存在也比对。
- 记录差异类型。每条差异标注为“数据未更新”“字段缺失”或“口径不一致”，并记录出现频次。
- 观察分布。看差异集中在某位负责人、某个状态节点，还是某类需求，分布本身也是线索。
样本对照记录表
| 需求编号 | 排期表状态/日期 | 实现侧状态/日期 | 差异字段 | 差异类型 | 备注 |
|---|---|---|---|---|---|
| R-001 | 进行中，计划完成 6/20 | 待测试，实际开发完成 6/18 | 状态、完成日期 | 数据未更新 | 开发完成后未回写排期表 |
| R-002 | 已完成，完成日期 6/15 | 已上线，验收通过 6/22 | 完成口径 | 口径不一致 | 排期表按开发完成计，实现侧按上线计 |
| R-003 | 无关联任务字段 | 已拆解 3 个子任务 | 关联任务 | 字段缺失 | 排期表无法反映拆解情况 |
记录完成后统计频次。若“数据未更新”占多数，重点查更新责任和更新时点；若“字段缺失”集中出现，说明排期表结构需要补充；若“口径不一致”反复出现，则要先统一状态定义，再谈同步。三类原因的处置顺序不同，混在一起改容易反复。
常见原因及各自的排除证据
样本对照给出的是差异分布，原因仍需逐项验证。下面列出四类常见原因，以及可以用于确认或排除的证据。每类原因都应找到具体记录，避免把猜测直接写成结论。
| 原因假设 | 可验证证据 | 排除条件 |
|---|---|---|
| 更新责任未落到具体角色 | 排期表中无“更新人”字段；询问后发现无人明确负责回写；差异集中在无人认领的需求上 | 若每条需求都有明确更新人且仍有大量滞后，则责任缺失不是主因 |
| 排期表与实现记录分属两处，靠人工同步 | 两处系统或文件独立维护；存在手工复制粘贴记录；同步时间间隔明显 | 若两处已同源维护，差异应主要来自口径而非同步遗漏 |
| 状态定义不一致 | 同一进度在两处叫法不同；字段说明缺失；不同负责人对“完成”理解不同 | 若两处状态名称和含义完全一致，可排除此项 |
| 变更后只改一处 | 存在需求范围或日期变更记录，但仅实现侧或仅排期表有变更痕迹；变更前后差异突然扩大 | 若变更记录在两处同步出现，则变更遗漏不是主因 |
验证时按“先查记录、再问角色、最后看定义”的顺序推进。记录类证据最直接，例如变更历史、字段修改时间、工作项流转记录；角色类证据可以通过一次简短确认获得；定义类证据则要看字段说明和实际使用习惯。三类证据指向同一原因时，才可以进入处置；证据互相矛盾时，先补充样本再判断。
按检查结果安排处置动作
处置动作应与已确认的原因对应，避免一次性大改。下面按动作列出责任、时点和风险提示，执行前先确认适用范围。
- 建立字段对应关系。由需求管理角色牵头，把排期表字段与实现侧工作项字段一一对应，明确哪些字段以实现侧为准、哪些由排期表维护。对应关系写成简短说明，附在表头或字段说明中。
- 指定更新责任人与更新时点。每条需求明确一名更新责任人，更新时点嵌入需求流转节点，例如进入开发、开发完成、提测、上线各回写一次。责任人可以是需求负责人，也可以是项目协调角色，按团队实际分工确定。
- 统一状态口径。把“进行中”“完成”等状态在两处的含义写清楚，特别是完成是指开发完成、测试通过还是上线。口径写入字段说明，新增需求按同一口径填写。
- 一次性校准历史差异。对样本中确认的差异数据集中修正。操作前备份原表或导出当前数据，校准范围限定在已确认差异的需求，避免顺手改动未核对的内容。
- 设置暂停与确认点。校准过程中若出现口径争议，例如两方对某需求是否算完成意见不同，暂停该条修改，由需求管理角色确认后再继续。批量修改前先小范围试改并复核。
当排期表与实现记录长期分处两地、靠人工回写时，可以考虑把需求与排期字段放在同一工作项中维护。ONES 通过统一的需求池、工单与任务看板同步状态与信息，业务团队可跟踪需求和缺陷处理进度，研发团队通过任务和工单完成开发、测试与修复；对于复杂需求，还可以用子工作项拆解并关联研发和测试任务。这样排期字段与实现状态来自同一处记录，减少两处对照时的回写遗漏。具体字段配置和状态映射需按团队实际开通的模块确定。
怎么验证已经恢复一致并防止复发
处置完成后，用同一批样本复检，是确认恢复一致最直接的方式。复检时重新读取排期表与实现侧记录，逐条比对之前的差异字段，确认差异已清零，或剩余差异有明确解释，例如某需求因范围变更重新排期。复检结果记入验证记录，写明复检日期、样本范围、差异数量和遗留说明。
固定核对机制
- 设定核对节奏。按迭代节奏安排核对，例如每个迭代中期和结束前各核对一次，重点看状态和日期是否同步。
- 确定抽查比例。全量核对成本较高时，可按固定比例抽查近期需求，覆盖不同负责人和不同状态节点；出现差异时扩大抽查范围。
- 把更新动作嵌入流转节点。在需求进入开发、提测、上线等节点设置回写动作，由责任人在节点完成时更新排期表，减少事后集中补录。
- 保留回溯线索。记录每次核对发现的差异类型和数量，出现新差异时按类型回溯：数据未更新查责任人，字段缺失查表结构，口径不一致查字段说明。
验证与预防形成闭环后，排期表才能持续反映实现进展。核对节奏和抽查比例应随团队需求数量调整，需求增多时适当提高抽查覆盖，需求稳定后可维持固定节奏。关键是每次核对都留下记录，让下一次差异出现时有据可查。
常见问题
样本对照时，抽多少条需求、抽哪些需求比较合适？
样本量不必大，覆盖近一到两个迭代内已启动或已完成的需求即可，关键是覆盖不同负责人、不同需求类型和不同状态节点。如果只抽同一负责人的需求，差异可能被个人习惯掩盖；如果只抽已完成需求，状态停滞类问题就看不出来。发现差异集中时再扩大样本范围，比一开始全量核对更省力。
排期表和实现侧都写“完成”，但含义不同，这种情况算脱节吗？
算，而且属于口径不一致这一类，处置方式和数据未更新不同。排期表的“完成”可能指开发完成，实现侧工作项可能按开发、测试、上线分别定义状态。检查时要先看两处字段说明是否存在，再确认不同负责人对“完成”的实际理解。口径统一之前，单纯回写数据只会让两处继续对不上。
历史差异数据一次性校准，需要注意什么风险？
校准前先备份原表或导出当前数据，校准范围限定在样本对照中已确认差异的需求，避免顺手改动未核对的内容。批量修改前先小范围试改并复核。若校准过程中出现口径争议，例如两方对某需求是否算完成意见不同，暂停该条修改，由需求管理角色确认后再继续。
把排期字段和实现状态放在同一处维护，能减少脱节吗？
能减少靠人工回写造成的遗漏，但前提是状态在流转过程中被及时更新。ONES 通过统一的需求池、工单与任务看板同步状态与信息，业务团队可跟踪需求和缺陷处理进度，研发团队通过任务和工单完成开发、测试与修复；复杂需求可用子工作项拆解并关联研发和测试任务。排期字段与实现状态来自同一处记录后，两处对照的工作量下降，字段配置和状态映射仍需按团队实际开通的模块确定。
复检时发现仍有少量差异，怎么判断是否可以接受？
看差异是否有明确解释。因需求范围变更重新排期、因上线时间调整而改期，这类差异有变更记录支撑，属于可解释差异；没有记录、也说不清原因的差异，应继续按类型回溯：数据未更新查责任人，字段缺失查表结构，口径不一致查字段说明。复检结果记入验证记录，写明复检日期、样本范围、差异数量和遗留说明，下一次核对时优先复查遗留项。
