研发效能看板与源系统数值对不上时，先别急着改数据。多数差异来自口径、采集范围或刷新时点，只有少数是真正的数据错误。建议按“症状分类—口径核对—采集映射—刷新链路—回归验证”的顺序排查，每一步留下对照记录，避免把假设当成结论。
要点总览（TL;DR）
- 先按症状分类：页面间不一致优先查口径与聚合层级，看板与源系统不一致优先查采集范围、状态映射和刷新时点，刷新后跳变优先查缓存与任务。
- 口径核对按定义、统计范围、时间字段、聚合去重四个维度逐项对照，并用同一筛选条件在源系统复算，复算一致说明差异在采集或刷新环节。
- 采集层用抽样逐条比对定位差异记录，核对采集过滤、状态映射和增量/全量同步方式，未验证环节标注待查。
- 刷新层先确认差异是否落在刷新间隔内，再查缓存与中间表旧值；手动重算前备份、限定时间范围并设定停止条件。
- 修复后用同一时间点、同一筛选条件做前后对照，约定偏差收敛标准，并建立口径变更记录、异常通知与定期对账机制。
先分清差异类型：症状与影响范围
“对不上”是一个笼统描述，排查前要把它拆成可判断的症状。不同症状指向不同的排查起点：同一指标在不同页面不一致，优先查口径与聚合层级；看板与源系统不一致，优先查采集范围、状态映射和刷新时点。
常见症状可以归为三类。第一类是页面间不一致，例如团队效能页显示本周完成 42 个需求，项目概览页显示 38 个，两个页面读取同一批工作项却给出不同结果，通常与筛选条件、统计对象或去重规则有关。第二类是看板与源系统不一致，例如源系统筛选出 50 条已完成工作项，看板只呈现 46 条，差异可能来自采集过滤、状态映射或同步滞后。第三类是时点波动，同一页面隔一段时间刷新后数值变化，而源系统数据并未变动，这类差异要重点查刷新链路与缓存。
区分稳定偏差与时点波动有一个简单办法：固定筛选条件，间隔多个刷新周期连续记录数值。偏差长期保持同一幅度，倾向口径或采集范围问题；数值忽高忽低、刷新后跳变，倾向刷新链路或缓存问题。
排查开始时就应建立影响范围记录，避免只修一个页面而遗漏同类指标。记录表可参考以下结构：
| 差异类型 | 指标 | 页面/入口 | 记录时间点 | 源系统数值 | 看板数值 | 偏差幅度 | 影响人群 |
|---|---|---|---|---|---|---|---|
| 页面间不一致 | 本周完成需求数 | 团队效能页 / 项目概览页 | 周一 10:00 | — | 42 / 38 | 4 | 项目经理、团队负责人 |
| 看板与源系统不一致 | 已完成工作项数 | 迭代看板 | 周一 10:00 | 50 | 46 | 4 | 迭代负责人 |
| 时点波动 | 缺陷修复时长 | 质量看板 | 连续三日 09:00 | 稳定 | 波动 | — | 质量负责人 |
表中“—”表示该列不适用，实际记录时按需填写。影响范围要写清受影响的指标、页面、时间范围和使用人群，后续验证与通知都以这份记录为基准。
口径层排查：定义、范围与聚合是否一致
口径差异是页面间不一致最常见的原因。指标名称相同，不代表计算方式相同。排查时按定义、范围、时间、聚合四个维度逐项对照，能较快区分“口径不同”与“数据错误”。
四个维度的核对要点
- 指标定义：同名指标可能统计对象不同。例如“完成需求数”，一处按工作项状态变为“已完成”计数，另一处按关联发布上线计数，结果自然不同。要确认指标的计算公式、分子分母和排除条件。
- 统计对象范围：核对项目、团队、工作项类型的覆盖范围。一个页面统计全部需求类型，另一个只统计“产品需求”，数值差异来自范围而非数据丢失。
- 时间口径：确认使用创建时间、完成时间还是状态变更时间，以及统计周期的边界如何划分。按自然周统计与按迭代周期统计，同一批工作项会落入不同区间。
- 聚合层级与去重：按人、按工作项、按迭代聚合的结果不同。一个工作项关联多个负责人或多次流转时，是否去重、按哪条记录去重，都会影响计数。
用同一筛选条件在源系统复算
口径核对的落点是复算。把看板使用的筛选条件原样搬到源系统，包括项目范围、工作项类型、状态集合和时间区间，导出明细后手工汇总，再与看板数值比对。复算结果一致，说明口径已对齐，差异在采集或刷新环节；复算结果仍不一致，继续逐项检查上述四个维度，直到找到具体是哪一项定义不同。
复算时建议保留导出明细和筛选条件截图，作为口径对照清单的附件。清单按“定义、范围、时间、聚合”四列标注每个指标的异同，结论写“一致”“口径不同”或“待确认”，避免用模糊描述收尾。
在 ONES 中，工作项状态与报表数据来自同一套业务数据，Performance 模块将 Project 中的业务数据同步后统一展示，管理者可从统一入口查看多项目、多团队的效能表现。排查口径时，先确认看板指标对应的工作项类型、状态集合和时间字段，再与源系统筛选条件逐项对齐，能减少因页面预设筛选不同造成的误判。
采集与映射排查：源数据进入看板前后的偏差
口径对齐后仍有差异，问题通常出在数据从源系统进入看板的过程中。这一层要回答的是：哪些数据被采集、字段如何映射、同步方式是否造成数值变化。排查时把每个环节写成假设，再用证据验证，未验证的环节明确标注“待查”。
重点核对三个环节
- 采集范围与过滤条件：确认采集是否排除某些状态、工作项类型，是否包含已删除或已归档数据。源系统默认展示未删除数据，看板若保留历史归档记录，计数会偏高；反之，看板过滤掉某些状态，计数会偏低。
- 字段映射与状态转换：源系统的状态名称映射到看板统计口径时，可能发生多对一合并或拆分。例如源系统有“已完成”“已关闭”“已验收”三个状态，看板统一计为“完成”，若映射遗漏其中一个，数值就会少算。字段类型转换、空值处理也可能改变计数。
- 同步频率与增量/全量方式：增量同步只采集变更记录，遇到状态回退或记录删除时可能漏算；全量同步覆盖完整，但执行周期较长。同步频率低于源系统更新频率时，看板呈现的是旧时点数据。
抽样逐条比对
整体数值比对只能说明有差异，抽样比对才能定位差异落在哪些记录上。从源系统导出差异时间段的明细，随机抽取若干工作项，逐条在看板中查找，记录每条的状态、负责人、时间字段是否一致。抽样时覆盖不同状态、不同类型和边界时间点，比随机抽取更能暴露映射问题。
核对记录按“环节、假设、验证方式、结论”四列填写。结论只写“符合”“偏差”或“待查”，偏差项附上具体工作项编号和两侧数值。这样后续修复有明确对象，也便于判断差异是系统性问题还是个别记录异常。
刷新链路排查：缓存、任务与时间窗
刷新链路造成的差异有一个共同特征：源系统数据已经正确，看板在一段时间内仍显示旧值。排查要围绕刷新周期、缓存层和任务状态展开，处置时按风险从低到高推进。
先确认时间窗与刷新先后
看板数据刷新与源系统更新存在时间差。源系统在 10:00 完成状态变更，看板按固定周期同步，10:05 查看时可能仍是旧值。排查时记录源系统变更时间、看板刷新时间和查看时间三个时点，判断差异是否落在刷新间隔内。若差异只在变更后短时间内出现、下一个周期自动收敛，属于正常的时点差异，不需要修复数据。
检查缓存与中间表
缓存层和中间表可能保留旧值。常见表现是：源系统已更新，看板多次刷新后数值不变；或不同页面读取不同缓存，出现页面间不一致。排查时对比直接查询源系统与经过缓存查询的结果，若源系统正确而缓存结果滞后，问题在缓存层。中间表要确认重算是否覆盖了变更时间段，部分重算遗漏的记录会长期停留在旧值。
识别刷新任务失败或延迟
刷新任务失败往往没有明显提示，表现为数据整体停在某个时间点。识别方式包括：查看最近一次成功刷新的时间戳、对比多个指标的更新时点是否一致、检查任务执行日志中的报错或超时记录。多个指标同时停止更新，通常是任务级问题；单个指标异常，更可能是该指标的采集或计算环节出错。
处置步骤按风险排序
- 记录当前状态：保存差异明细、刷新时间戳和任务日志，作为处置前基线。
- 等待下一个刷新周期，确认差异是否自动收敛。能自动恢复的，不需要手动干预。
- 确认缓存或中间表存在旧值时，先备份相关表或导出当前数据，再执行缓存清理。
- 需要手动触发刷新或重算时，明确重算的时间范围和影响指标，选择业务低峰期执行。
- 重算过程中设置停止条件：若重算后数值与源系统偏差扩大，或影响其他指标，立即停止并回滚到备份状态。
手动重算属于有破坏风险的操作，执行前要确认备份可用、影响范围已通知相关使用人。重算只针对确认存在旧值的时间段，避免全量重算扩大影响面。
ONES Performance 具备数据同步与统一展示能力，官方资料表述为实时同步 Project 中的业务数据。具体刷新周期、缓存机制和任务失败告警方式，资料未注明，实际排查时以所使用环境的任务日志和刷新记录为准，不预设固定周期。
验证恢复与复发预防
修复完成后，验证要用同一时间点、同一筛选条件做修复前后对照，确认差异收敛到可接受范围，再把这次排查转化为可复用的机制。
修复前后的对照验证
验证时固定三项条件：相同的时间区间、相同的筛选条件、相同的统计口径。分别记录修复前数值、修复后数值和源系统复算值，三者对比。差异收敛的判断标准应在排查开始时就约定，例如计数类指标偏差为零，时长类指标偏差在约定误差范围内。达到标准才算恢复，未达到则回到对应层级继续排查，不跳过验证直接关闭问题。
建立记录与通知机制
口径变更和刷新异常都应有记录。口径变更记录写清变更内容、生效时间、影响指标和通知对象；刷新异常记录写清发生时间、影响范围、处置方式和恢复时间。变更或异常发生后，主动通知看板使用人群，避免他们在数据未收敛时做出判断。
定期对账与文档维护
预防复发的核心是定期对账和口径文档维护。对账频率可按指标重要程度设定，核心指标每周或每迭代对账一次，其余指标每月一次。对账内容是用源系统复算值与看板值比对，记录偏差并跟踪处理。口径文档要写明每个指标的定义、统计范围、时间字段、聚合规则和责任人，指标调整时同步更新文档，文档维护责任落到具体角色而非笼统的“数据团队”。
把症状分类表、口径对照清单、采集核对记录和验证记录归档保存，下次出现同类差异时可直接对照历史记录，缩短定位时间。
常见问题
看板与源系统只差几条记录，还需要走完整排查流程吗？
少量差异同样值得定位，因为偏差幅度小不代表原因简单。建议先做抽样比对：从差异时间段导出源系统明细，逐条在看板中查找缺失或数值不同的记录，观察差异是否集中在某一状态、某一工作项类型或某个时间边界。若差异集中在特定状态，多半是状态映射遗漏；若集中在时间段末尾，多半是刷新时点未到。定位到具体环节后，只需针对该环节核对，不必重走全部流程。
口径核对时源系统复算结果与看板一致，但用户仍反馈数值不对，怎么处理？
这种情况通常说明看板与源系统在既定口径下是一致的，差异来自用户使用的筛选条件或对指标含义的理解。可以让用户提供其查看时的页面、筛选条件和时间范围，按相同条件复算一次，对比结果。若复算一致，问题在口径沟通而非数据，应把该指标的定义、统计范围和时间字段补充到口径文档，并在看板页面标注口径说明。若复算不一致，则回到口径四维度继续核对。
手动触发重算后数值反而偏差更大，应该怎么止损？
立即停止重算任务，回滚到处置前保存的备份状态，并记录重算的时间范围、影响指标和偏差变化。偏差扩大常见于重算范围覆盖不全、重算期间源系统仍有数据变更，或重算依赖的中间表本身存在旧值。回滚后先确认备份数据可用、看板恢复原值，再缩小重算范围重新验证：只选一个确认存在旧值的时间段试算，与源系统比对通过后再扩大范围。重算期间应避开业务高峰并提前通知使用人。
多个指标同时停止更新，和单个指标异常的处理顺序有什么不同？
多个指标同时停止更新，通常指向任务级问题，例如刷新任务失败、调度中断或数据源连接异常，应优先查看最近一次成功刷新的时间戳和任务执行日志，确认失败原因后按刷新链路处置步骤处理。单个指标异常更可能是该指标的采集过滤、字段映射或计算逻辑出错，应回到采集与映射层，用抽样比对定位具体记录。两类问题的排查起点不同，先判断影响面再选择路径，可以避免在错误的层级上耗费时间。
定期对账的频率和责任人怎么定比较实际？
对账频率可按指标重要程度分层：核心指标每周或每迭代对账一次，其余指标每月一次，对账内容是用源系统复算值与看板值比对并记录偏差。责任人应落到具体角色，例如指标口径由指标负责人维护，对账执行由数据或效能管理岗承担，异常处置由对应模块负责人跟进。口径文档要写明每个指标的定义、统计范围、时间字段、聚合规则和责任人，指标调整时同步更新。频率和分工需结合团队规模与指标数量调整，不宜照搬固定模板。
