数据所有者、系统所有者和指标所有者分别对应三条管理线：数据所有者管数据内容，决定数据能不能用、谁能用；系统所有者管系统运行，保证数据按时按量到达；指标所有者管指标含义，保证指标算得对、说得清。三者的边界在数据从源头流向看板的每个交接点体现，项目团队提供源头事实，数据治理角色制定规则并仲裁冲突。
要点总览（TL;DR）
- 数据所有者管数据内容：口径、质量规则、访问权限与留存策略，决定数据能不能用、给谁用。
- 系统所有者管系统运行：采集管道、同步任务、存储与可用性，保证数据按约定时间和范围到达。
- 指标所有者管指标含义：定义、计算公式、统计范围、阈值与异常解读，保证指标算得对、说得清。
- 交接点按“源头记录→数据汇聚→指标计算→看板呈现”划分，断点先判断是记录没产生、数据没到达，还是口径没对齐。
- 项目团队对源头记录的真实与及时负责，数据治理角色制定标准并仲裁跨角色口径争议。
三句话分清三类所有者
判断一件事该由谁负责，可以先看它落在哪条线上：涉及数据口径、质量、权限和生命周期，找数据所有者；涉及采集管道、同步任务、存储和可用性，找系统所有者；涉及指标定义、计算公式、阈值和解读，找指标所有者。这三类角色共同覆盖度量数据从产生到使用的完整链条，但各自的核心负责对象不同。
可以用三个问句快速对号入座：
- “这份数据准不准、能不能给这个团队看？”——问数据所有者。
- “数据为什么没同步过来、看板为什么打不开？”——问系统所有者。
- “这个指标怎么算的、为什么这个月变高了？”——问指标所有者。
三者共同承担的部分是数据可信。数据所有者保证内容可信，系统所有者保证到达可信，指标所有者保证解释可信。任何一环缺失，看板上的数字都无法支撑决策。因此三者需要在规则层面协同，而不是各自守住一段就结束。
职责边界：各自负责什么、不负责什么
把负责项和不负责项并列写清楚，边界才具备可操作性。以下按五类角色展开，其中项目团队和数据治理角色是三类所有者之外的必要补充。
| 角色 | 负责项 | 不负责项 |
|---|---|---|
| 数据所有者 | 某一类度量数据的口径、质量规则、访问权限、留存与归档策略；决定数据能否用于特定用途 | 工具选型与部署；指标算法与阈值设定；采集管道的日常运维 |
| 系统所有者 | 采集管道、同步任务、存储容量、系统可用性与故障恢复；保证数据按约定时间和范围到达 | 业务口径解释；指标计算公式；数据授权给谁使用 |
| 指标所有者 | 单个指标的定义、计算公式、统计范围、阈值与异常解读；指标变更的说明与通知 | 源数据的采集与清洗；底层系统的稳定性；数据访问权限审批 |
| 项目团队 | 源头记录的真实、完整与及时；工作项状态、工时、缺陷等原始信息的准确录入 | 指标口径制定；系统运维；跨团队数据授权决策 |
| 数据治理角色 | 制定数据标准与命名规则；仲裁跨角色的口径争议；审定数据分级与授权原则 | 日常数据运维；单个指标的日常解读；具体项目的记录质量 |
数据所有者的关键动作是“定规则并授权”。例如某类交付数据能否开放给跨部门查看、保留多久、出现质量问题时按什么标准判定，这些由数据所有者决定。工具选型和指标算法不在其职责内，避免把内容责任和系统责任混在一起。
系统所有者的关键动作是“保到达”。同步任务失败、数据延迟、存储告警由系统所有者处理。业务口径的争议不归系统所有者裁决，否则容易出现“系统能跑通就算没问题”的误判。
指标所有者的关键动作是“定含义”。一个指标统计哪些工作项、按什么时间口径截取、阈值定在哪里、数值波动如何解释，由指标所有者负责。源数据是否完整属于项目团队和数据所有者的范围，指标所有者可以提出数据质量要求，但不承担采集责任。
三者如何衔接：一条数据从产生到看板的流转
静态职责清单解决“谁管什么”，动态流转解决“在哪里交接”。一条研发效能数据通常经过源头记录、数据汇聚、指标计算、看板呈现四个环节，每个环节之间都有明确的交接点。
| 环节 | 交接内容 | 交出方 | 接收方 | 交接完成的标志 |
|---|---|---|---|---|
| 源头记录到数据汇聚 | 工作项状态、工时、缺陷等原始记录 | 项目团队 | 系统所有者 | 记录按约定字段和频率进入采集管道 |
| 数据汇聚到指标计算 | 清洗后的数据集与质量标记 | 系统所有者、数据所有者 | 指标所有者 | 数据集口径确认，质量异常已标注 |
| 指标计算到看板呈现 | 指标结果、阈值与解释说明 | 指标所有者 | 指标使用者 | 看板数值可追溯，口径说明随图可见 |
第一个交接点的常见断点是记录缺失或状态回填不及时。此时先看项目团队的录入规范是否明确，再看系统所有者的采集任务是否覆盖了对应字段。归属判断的顺序是：记录本身没产生，归项目团队；记录产生了但没被采集，归系统所有者。
第二个交接点的常见断点是数据集口径与指标定义不一致。例如指标要求按完成时间统计，数据集却只保留了创建时间。这类问题由数据所有者与指标所有者共同确认口径，数据治理角色在双方无法达成一致时仲裁。
第三个交接点的常见断点是指标数值被误读。看板展示了数字但缺少口径说明，使用者按自己的理解解读。此时责任在指标所有者，需要补充定义、统计范围和变更记录。在 ONES 的效能管理场景中，交付效率、交付质量、进度情况、资源效率等数据可以统一展示，Performance 能将 Project 中的业务数据同步到报表与图表中，这类承载方式让指标结果和口径说明放在同一入口，减少呈现环节的解读偏差；具体同步范围与配置以实际使用为准。
容易混淆的相邻概念
边界问题经常被误判成其他主题。以下几组概念需要区分清楚，避免把职责问题错放到指标体系设计或工具链集成里。
数据所有者与数据管理员
数据所有者对数据“能不能用、给谁用”做决策并承担结果责任；数据管理员执行日常维护动作，如权限开通、数据清洗、质量巡检和问题登记。数据管理员向数据所有者报告，遇到规则未覆盖的情况提交数据所有者决定。把两者混为一谈，容易出现“谁维护谁说了算”的越权决策。
指标所有者与指标使用者
指标所有者对定义、计算和解释负责，指标使用者依据指标做判断和行动。使用者发现数值异常时，应向指标所有者提出疑问，由指标所有者确认是计算问题、数据问题还是业务真实变化。使用者不自行修改口径，指标所有者也不替使用者做业务决策。
系统所有者与工具链集成配置
系统所有者关注承载数据的工具与管道是否稳定运行；工具链集成的接口配置、字段映射和连接规则属于集成设计范畴。接口配置变更可能影响数据到达，但配置方案本身由集成设计方确定，系统所有者负责变更后的运行验证与故障处理。两者在变更窗口和回滚方案上需要协同。
指标定义与接口配置的归属
指标定义归研发效能指标体系，包括指标名称、公式、统计范围、阈值和解释规则；接口配置归研发工具链集成，包括数据源连接、字段映射和同步策略。一个指标算得不对，先判断是定义问题还是数据到达问题：定义问题找指标所有者，数据未按约定到达找系统所有者，两者都排除后再查源头记录。
一个例子与三种常见误解
以“需求交付周期”指标为例，演示三类所有者各自的动作。该指标统计需求从进入开发到上线的时间长度。指标所有者负责定义起止时间点、统计哪些需求类型、按什么粒度呈现、周期变长时如何拆解原因。数据所有者负责确认需求状态数据的口径统一、历史数据是否可追溯、哪些团队可以查看该指标。系统所有者负责需求状态变更记录能否按时同步到数据集、同步任务失败时能否及时发现并补数。项目团队负责在需求流转时及时更新状态，避免停留在旧状态导致周期被拉长。数据治理角色在“上线时间以发布记录还是以状态变更为准”这类争议上做出裁定。这是一个演示情景，用于说明判断方法。
实际工作中，三类边界常被三种误解打乱：
- 误解一：数据有问题就找系统所有者。系统所有者只保证数据按约定到达。数值口径不对、权限给错人、历史数据该不该保留，属于数据所有者；指标算法不对属于指标所有者。先判断问题出在到达、内容还是含义，再找对应角色。
- 误解二：指标口径争议由数据所有者单方决定。数据所有者决定数据能否使用和授权范围，指标的计算口径由指标所有者提出并维护。跨团队的争议由数据治理角色按既定标准仲裁，单方决定容易造成口径反复变更。
- 误解三：项目团队只负责填数，不承担质量责任。源头记录的真实与及时是项目团队的职责。状态长期不更新、工时随意填写，会让下游所有环节失真。项目团队按规范记录，数据所有者和指标所有者才能在这个基础上做质量判定和解释。
把这三条线记住，大多数职责问题可以在几分钟内找到归属：先问是内容、运行还是含义，再看交接点在哪一环断开，最后确认是否需要数据治理角色介入仲裁。
常见问题
如果看板上的数字和业务感受不一致，应该先找谁？
先按“到达、内容、含义”的顺序排查。确认数据是否按约定时间同步到位，这一步归系统所有者；再看源数据口径与权限是否符合预期，归数据所有者；最后核对指标的定义、统计范围和计算方式，归指标所有者。三者都排除后，再回到项目团队的源头记录检查状态更新是否及时。把排查顺序固定下来，可以避免一发现问题就默认是系统故障。
指标所有者调整了计算公式，需要通知哪些角色？
指标变更会影响看板数值和历史对比，指标所有者应至少通知数据所有者、系统所有者和主要指标使用者。数据所有者关注变更后数据是否仍符合授权与留存要求，系统所有者确认计算所依赖的数据集是否已覆盖新口径，使用者需要知道数值变化来自口径调整而非业务波动。变更说明和生效时间随指标一起保留，便于后续追溯。
项目团队记录不规范导致指标失真，责任算谁的？
源头记录的真实与及时属于项目团队职责，记录缺失或状态长期不更新造成的失真，首先由项目团队按录入规范整改。数据所有者和指标所有者可以提出质量要求和判定标准，但不替代项目团队做记录。如果记录规范本身不明确，由数据治理角色牵头补充标准，再回到项目团队执行。
数据所有者和系统所有者可以是同一个人吗？
在团队规模较小、数据种类不多的情况下，同一人兼任两类角色是常见做法，但需要在规则上把两类决策分开记录：哪些决定属于数据能否使用和授权，哪些属于系统运行与故障处理。兼任时容易出现“系统能跑通就认为数据没问题”的倾向，建议在质量判定和权限审批上保留独立复核，或由数据治理角色定期检查。
跨团队对指标口径争执不下时，谁来做最终裁定？
指标的计算口径由指标所有者提出并维护，跨团队争议由数据治理角色按既定标准仲裁。裁定结果应形成书面记录，明确适用范围和生效时间，避免同类争议反复出现。数据所有者参与讨论，重点确认裁定后的数据授权与使用范围是否随之调整。
