研发数据采集的落地顺序可以概括为：先按要回答的效能问题确定指标口径，再盘点承载这些数据的系统与字段，明确采集方式、频率与责任归属，然后建立字段映射与数据校验，最后接入看板并设置异常回补机制。本文按这条路径给出每一步的做法、产物和完成标志，覆盖从需求流转到交付周期的端到端示例，并说明各角色分工与上线检查项。指标体系的完整设计、工具链接口认证细节不在本文展开。
要点总览（TL;DR）
- 先按要回答的效能问题确定指标口径，再盘点承载数据的系统与字段，首期只采集核心指标。
- 根据数据源是否提供稳定接口、时效要求和维护成本，选择接口拉取、事件上报、定期文件导入或人工补录。
- 建立统一数据模型并编写字段映射表，按数据源配置采集任务，明确调度、重试与日志。
- 从完整性、及时性、一致性三个维度校验数据，通过抽样对账和异常回补保证可信。
- 看板只消费已校验的数据集，口径变更同步更新清单、映射和看板说明，并定期巡检采集任务。
先定指标口径，再定采集范围
研发数据采集的第一步是回答“这些数据用来判断什么”。直接从系统里把能拿到的字段全部同步过来，常见结果是数据量很大、看板上却没人用，或者同一个“交付周期”在不同报表里算出不同结果。先定口径，采集范围才有边界。
做法是从效能问题反推指标。团队如果关心“需求交付是否变慢”，对应指标是需求交付周期；关心“返工是否偏多”，对应指标是缺陷重开率或缺陷逃逸率；关心“发布是否稳定”，对应指标是发布频率与发布后故障数。每个问题写下一到两个指标即可，首期不宜铺开。
每个指标需要写清四件事：计算口径（分子、分母、起止时间点如何取）、统计周期（按周、按迭代还是按自然月）、数据来源系统、口径负责人。以需求交付周期为例，口径要明确起点是需求创建还是进入开发，终点是上线还是验收通过，是否剔除挂起时长。这些定义不写清，后续字段映射和看板展示都会反复返工。
指标还要区分核心与观察两类。核心指标进入首期采集和看板，观察指标先记录定义、暂不接入，等核心链路跑稳后再扩展。这样可以把首期采集范围控制在可校验的规模内。
本步的交付物是一份指标—数据源对照清单，建议包含以下列：
| 指标名称 | 计算口径 | 统计周期 | 来源系统 | 指标类型 | 负责人 |
|---|---|---|---|---|---|
| 需求交付周期 | 需求创建至上线的时间，剔除挂起时长 | 按周 | 需求与任务系统、发布记录 | 核心 | 效能负责人 |
| 缺陷重开率 | 重开缺陷数 / 关闭缺陷数 | 按迭代 | 缺陷跟踪系统 | 核心 | 质量负责人 |
| 构建成功率 | 成功构建次数 / 总构建次数 | 按天 | 流水线 | 观察 | 工具管理员 |
完成标志是：每个首期指标都有唯一口径、明确来源系统和签字确认的负责人，团队对“这个数字怎么算”没有分歧。
盘点数据源与采集方式
口径确定后，逐一确认每个指标的数据实际存放在哪个系统、哪个字段。研发数据常见的来源有五类：需求与任务系统承载工作项的状态流转与时间点；代码仓库提供提交记录、分支与合并信息；流水线提供构建与部署记录；缺陷跟踪系统提供缺陷生命周期；发布记录提供版本上线时间与范围。盘点时要记录系统名称、可访问的接口或导出能力、字段清单和系统负责人。
采集方式有四种，选择依据是数据源是否提供稳定接口、时效要求和维护成本：
| 采集方式 | 适用条件 | 时效 | 主要成本 |
|---|---|---|---|
| 接口拉取 | 源系统提供稳定 API，数据量大且需定期更新 | 分钟级到小时级 | 需处理分页、限流与鉴权 |
| 事件上报 | 源系统支持 webhook 或消息推送，需要近实时反映状态变化 | 秒级到分钟级 | 需保证接收端可用与幂等 |
| 定期文件导入 | 源系统只能导出报表或数据文件，或数据量小、变化慢 | 天级 | 需约定文件格式与放置位置 |
| 人工补录 | 数据无系统承载，如线下评审结论、外部依赖时间 | 按需 | 需明确补录责任人与截止时间 |
采集频率要与业务节奏匹配。构建成功率按天或按次采集即可支撑周度回顾；需求状态变化如果用于识别流转阻塞，事件上报比每日拉取更合适。频率过高会增加源系统压力和运维负担，频率过低则会让看板失去指导当周动作的价值。
增量与全量的选择同样取决于数据特征。工作项、缺陷这类会持续变更状态的实体，首轮做一次全量初始化，之后按更新时间增量拉取；发布记录、版本清单这类数量有限且需要完整历史的实体，可以每次全量同步。增量采集要确认源系统提供可靠的更新时间字段，否则容易漏数。
本步交付物是数据源清单与采集方式决策表，每个数据源写明采集方式、频率、增量或全量、责任人和失败联系人。完成标志是：首期指标涉及的每个字段都能在清单中找到归属系统与采集方式，没有“待确认”项遗留到开发阶段。
字段映射与采集任务落地
不同系统的字段命名和取值规则各不相同，直接拼接会导致同一实体在不同报表中无法对齐。需要先建立统一数据模型，再做字段映射。统一模型的关键实体包括：工作项（需求、任务、缺陷的统一抽象）、提交、构建、缺陷、发布。每个实体定义一组标准字段，例如工作项包含唯一标识、类型、状态、创建时间、进入开发时间、完成时间、所属项目。
字段映射表按“源系统—源字段—目标实体—目标字段—转换规则—空值处理”逐行编写。转换规则要写具体，例如状态值“已上线”映射为“已发布”，时间字段统一转换为同一时区，枚举值做大小写归一。空值处理要明确：是保留为空、用默认值填充，还是该记录不进入统计。映射表是后续校验和口径变更时的主要依据，需要版本管理。
采集任务按数据源分别配置，每个任务写明调度周期、依赖关系、失败重试次数与间隔、日志保留位置。任务之间常有依赖，例如发布记录同步应在工作项状态同步之后执行，否则会出现“已上线但状态未更新”的短暂不一致。失败重试要设置上限，超过上限转入告警而不是无限重试。
敏感字段与权限边界在配置阶段就要划定。人员绩效相关字段、客户信息字段是否进入采集范围，需要与数据归属方确认；采集账号使用最小权限，只读取必要字段；看板展示层按角色控制可见范围，避免原始明细数据被无差别查看。
如果团队使用 ONES，工作项、缺陷、迭代等业务数据本身在 ONES Project 中产生，ONES Performance 可实时同步 Project 中的业务数据，减少手工整理数据源的工作（依据官网解决方案页面表述，实际时效以部署环境为准）。此时字段映射的重点转向外部系统数据与 ONES 内业务数据的对齐，例如代码仓库的提交如何关联到工作项、流水线构建如何对应到发布记录。
本步完成标志是：映射表覆盖首期全部指标所需字段，采集任务能按调度稳定产出数据，日志中可查到每次运行的开始时间、处理条数和失败原因。
数据校验与质量兜底
采集任务跑通不等于数据可信。需要从三个维度做校验：完整性检查记录数与关键字段的空值率，例如某天工作项同步条数是否与源系统新增数接近、状态字段是否存在大量空值；及时性检查数据延迟，确认最新一条记录的时间与当前时间的差距在约定范围内；一致性检查跨系统关联，例如发布记录中的版本号能否在流水线构建记录中找到对应构建。
对账采用抽样比对的方法：从源系统按条件抽取若干条记录，与采集后的数据进行逐字段核对，重点检查状态转换时间点和关联标识。抽样应覆盖正常流转、跨项目关联、状态回退等不同情况。首期上线前建议做一次全量对账，之后按周抽样。
缺失与重复数据的回补流程要提前定义。发现某段时间数据缺失时，先定位是源系统未产生数据、接口调用失败还是映射规则丢弃，再按时间范围触发重跑；重复数据按唯一标识去重，并记录去重规则。回补操作要留痕，避免同一时间段被反复覆盖导致口径漂移。
异常告警要绑定责任人。任务失败、数据量突降超过阈值、关键字段空值率超标，都应触发通知到具体的人，而不是发到无人认领的群。告警信息中包含任务名称、异常类型、影响时间范围和初步排查入口。
本步交付物是数据质量检查清单与异常处理流程，检查清单按指标列出校验项、阈值、检查频率和责任人。完成标志是：连续若干个采集周期内，三类校验均通过或异常已在约定时限内闭环。
接入看板与持续维护
看板展示层与采集层要职责分离。采集层负责把数据按统一模型落库并保证质量，展示层只消费已校验的数据集，不在看板侧做复杂的口径计算。这样口径调整只需改一处，看板不会各自为政。看板按读者组织：管理者看多项目、多团队的趋势与对比，团队负责人看本团队的流转与阻塞，一线看与自己相关的工作项明细。
指标口径变更时，同步更新三处：指标—数据源对照清单中的口径定义、字段映射表中的转换规则、看板上的指标说明。变更要有记录，注明变更原因、生效时间和影响的历史数据范围，必要时对历史数据做重算并标注口径版本。
采集任务需要定期巡检，检查内容包括任务成功率、数据延迟、源系统接口变更、账号权限到期。巡检结果与任务配置一起纳入版本记录，任何调度、映射或阈值的调整都可追溯。
采集范围随业务演进扩展时，沿用同一套流程：新增指标先补口径，再补数据源与映射，校验通过后接入看板。不要为了赶进度跳过校验直接上图，否则后续修正成本更高。
ONES Performance 提供从选取数据集、自定义报表到图表展示的使用路径，并可从统一入口查看多项目、多团队、多流程的效能表现（依据官网解决方案页面表述，具体指标项与展示形式以实际配置为准）。对于业务数据已在 ONES 内产生的团队，可以把采集层的部分工作收敛到这一链路上，把精力放在外部系统数据的对齐和校验上。
一个完整示例：从需求流转到交付周期数据
以下示例演示如何采集“需求从创建到上线”的周期数据，场景为演示设定，用于说明各环节的输入、动作与输出。
目标是得到一个可按周统计的需求交付周期指标，口径为需求创建时间到首次上线时间的间隔，剔除标记为挂起的时长。涉及的源系统有三个：需求与任务系统提供需求创建时间、状态流转记录和挂起标记；代码仓库提供与需求关联的提交记录；发布记录提供版本上线时间及包含的需求清单。
采集方式上，需求与任务系统采用接口增量拉取，按更新时间每半小时同步一次；代码仓库通过事件上报接收合并请求事件，用于建立提交与需求的关联；发布记录数据量小且需要完整历史，采用每日全量导入。字段映射时，需求唯一标识作为主键贯穿三个系统，状态值统一映射为“待处理、开发中、待测试、已上线”四类，时间字段统一时区。
校验环节做三项检查：每日核对新增需求条数与源系统是否一致；检查最新同步时间与当前时间差距是否在半小时内；抽取若干已上线需求，比对发布记录中的上线时间与需求状态变为“已上线”的时间是否吻合。发现某周数据缺失时，按时间范围重跑该周的增量任务，并核对重跑前后的记录数。
完成标志是：连续四周的周度交付周期数据可稳定产出，抽样对账无差异，看板上能按团队和项目维度查看趋势，异常告警能在约定时限内响应。
角色分工与完成检查
采集流程涉及四类角色，职责与交付物如下：
| 角色 | 主要职责 | 输入 | 交付物 |
|---|---|---|---|
| 效能负责人 | 确定要回答的效能问题，定义指标口径，确认首期范围 | 业务关注点、历史报表问题 | 指标—数据源对照清单 |
| 数据工程师 | 盘点数据源，设计统一模型与字段映射，配置采集任务与校验规则 | 指标清单、各系统字段说明 | 字段映射表、采集任务配置、质量检查清单 |
| 工具管理员 | 提供系统接口权限与账号，配合接口变更通知，维护源系统数据规范 | 采集需求、权限申请 | 可用接口与账号、变更通知记录 |
| 团队负责人 | 确认本团队数据口径的合理性，使用看板并反馈异常 | 看板与指标说明 | 口径确认意见、数据异常反馈 |
上线前逐项核对以下检查项：口径是否经效能负责人和团队负责人确认；首期指标的字段映射是否全部完成且无空值处理遗漏；采集任务是否连续运行并通过完整性、及时性、一致性校验；看板是否按角色配置可见范围并能正常刷新；异常告警是否绑定到具体责任人；映射表与任务配置是否已纳入版本记录。
首期上线的最小完成条件是：核心指标全部可稳定产出，抽样对账通过，看板可供目标读者使用，异常有明确处理人。观察指标、更多项目范围和更细的展示维度可以在后续迭代中按同一流程扩展。
常见问题
首期采集应该覆盖多少指标比较合适？
首期建议只接入核心指标，数量控制在三到五个，确保每个指标都有唯一口径、明确来源系统和负责人。观察指标先记录定义、暂不接入，等核心链路跑稳后再按同一流程扩展。这样可以把采集范围控制在可校验的规模内，避免因指标过多导致映射和校验工作积压。
源系统没有提供接口，还能做研发数据采集吗？
可以。如果源系统只能导出报表或数据文件，可以采用定期文件导入，约定文件格式和放置位置，按天或按周同步。对于完全没有系统承载的数据，比如线下评审结论或外部依赖时间，可以设置人工补录，明确补录责任人和截止时间。选择采集方式时，优先考虑数据时效要求和长期维护成本，接口拉取和事件上报适合需要较高时效的场景，文件导入和人工补录适合变化慢或数据量小的场景。
怎么判断采集到的数据是否准确？
从三个维度检查：完整性看记录数和关键字段空值率是否与源系统接近；及时性看最新数据时间与当前时间的差距是否在约定范围内；一致性看跨系统关联字段能否对应，比如发布记录的版本号能否在流水线构建记录中找到。首期上线前做一次全量抽样对账，之后按周抽样，覆盖正常流转、跨项目关联和状态回退等情况。发现异常时按时间范围重跑并记录去重规则。
指标口径中途调整，采集和看板要怎么同步？
口径变更时同步更新三处：指标—数据源对照清单中的口径定义、字段映射表中的转换规则、看板上的指标说明。变更要记录原因、生效时间和影响的历史数据范围，必要时对历史数据做重算并标注口径版本。采集任务和映射表纳入版本管理，确保调整可追溯。
使用 ONES 的团队，采集工作可以简化到什么程度？
如果业务数据本身在 ONES Project 中产生，ONES Performance 可实时同步 Project 中的业务数据，减少手工整理数据源的工作（依据官网解决方案页面表述，实际时效以部署环境为准）。此时字段映射的重点转向外部系统数据与 ONES 内业务数据的对齐，例如代码仓库提交如何关联到工作项、流水线构建如何对应到发布记录。采集层的校验和异常回补仍需按本文方法建立。
