划定AI效能分析的数据边界，核心是把“分析需要什么数据”和“组织允许用到什么程度”分开定义再对齐。可执行的做法是先按分析问题列出最小必要数据项，再为每项标注来源、粒度、聚合层级、用途、可见角色、保留期限和脱敏方式，形成一份可评审的清单，最后用权限配置、抽样核验和定期复核确认边界持续有效。
要点总览（TL;DR）
- 先按分析问题倒推最小必要数据，每个数据项都要能追溯到具体问题，写不出判断价值的不纳入。
- 用七个字段把边界写成可评审的条目：来源系统、字段与粒度、聚合层级、使用目的、可见角色、保留期限、脱敏方式。
- 边界制定与执行按研发管理者、数据或平台负责人、HR或合规角色、团队负责人分工，各自留下清单、评审记录或解读记录。
- 进入AI分析的数据收敛到聚合层，AI输出作为辅助线索，涉及个人的结论由人复核后才能使用。
- 用清单完整性、权限日志、聚合抽样和AI输出复核逐项验证边界是否生效，并约定越界后的处置动作。
先定分析问题，再倒推最小必要数据
数据边界失控，常见起点是先接通各系统数据，再回头找用途。更稳妥的顺序相反：先写清这一轮要回答哪些效能问题，再逐项倒推需要什么数据。分析问题决定了数据项的范围，也决定了哪些字段可以不要。
把分析问题按类型分组，每组对应一类数据。例如：
- 交付节奏类问题（迭代是否按期完成、需求从提出到上线的周期多长）对应工作项状态变更时间、迭代起止时间、需求流转记录。
- 需求流转类问题（需求在哪个环节积压、返工比例多少）对应需求状态历史、变更记录、关联缺陷数。
- 代码活动类问题（提交与合并频率、评审停留时长）对应代码提交记录、合并请求时间戳、评审意见数。
- 协作负载类问题（成员同时承担多少任务、跨项目投入分布）对应工作项负责人、所属项目、计划工时与实际工时。
每个数据项后面写两句话：用它回答哪个问题，缺了它会怎样。写不出判断价值的数据项，本轮不纳入。这一步的产物是一份按分析问题组织的最小必要数据清单，至少包含数据项、对应分析问题、用途说明、必要性等级四列。必要性等级分“必须”和“可选”：必须字段缺失会导致分析结论不成立，可选字段只影响分析精细度，可以在权限或合规受限时舍弃。
完成标志是：清单中每个数据项都能追溯到至少一个分析问题，且没有“先采着以后可能有用”的条目。
数据边界清单：每项数据要写清的七个字段
最小必要数据清单回答“要哪些数据”，边界清单回答“每项数据允许怎么用”。把每项数据展开为七个字段，边界就从原则变成了可评审的条目。
| 字段 | 填写内容 | 示例 |
|---|---|---|
| 来源系统 | 数据从哪个系统或表产生 | 项目管理工作项状态历史 |
| 字段与粒度 | 具体字段名及记录粒度 | 工作项ID、状态、变更时间，单条变更记录 |
| 聚合层级 | 分析时呈现到哪一层 | 团队级周均值，不呈现个人明细 |
| 使用目的 | 对应哪个分析问题 | 识别需求在评审环节的停留时长 |
| 可见角色 | 哪些角色能看原始数据、哪些只能看聚合结果 | 数据负责人可见明细，团队负责人看团队聚合 |
| 保留期限 | 原始数据与分析结果各保留多久 | 原始明细保留90天，聚合结果保留1年 |
| 脱敏方式 | 个人标识如何处理 | 以成员编号替代姓名，小组人数不足时合并展示 |
个人明细与团队聚合的区分规则要单独写明：明细层仅用于数据核对与异常回溯，访问范围限定到数据负责人；进入分析看板和AI输入的数据一律为聚合层。聚合层级的选择与小组样本量挂钩，人数过少的团队合并到上一级组织展示，避免通过聚合结果反推个人。
常见填写错误有三类：聚合层级写成“按需”，等于没有约束；使用目的写成“效能分析”这类笼统表述，无法判断越界；保留期限留空，导致数据无限期沉淀。填写时逐项检查是否具体到可执行，例如“按需”应改为“团队级月度聚合”。
角色分工与交付物：谁定边界、谁用数据、谁复核
边界清单只有落到具体角色和交付物上才会被执行。建议按四类角色分工，规模较小的团队可以一人兼多职，但职责要分开写明。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 研发管理者 | 提出分析问题，确认数据项与分析目标的对应关系 | 分析问题清单、最小必要数据清单 |
| 数据或平台负责人 | 维护边界清单，配置数据接入、聚合与权限 | 边界清单、权限配置记录、脱敏规则说明 |
| HR或合规角色 | 评审个人数据的使用目的、保留期限与可见范围 | 评审意见与签署记录 |
| 团队负责人 | 在授权范围内使用聚合结果，解释本团队数据异常 | 结果解读记录、异常说明 |
AI分析结果的解读责任要明确归属：AI输出的是基于聚合数据的观察和建议，由提出分析问题的研发管理者或对应团队负责人负责判断是否成立、是否采取行动。AI输出不直接进入人员评价流程，涉及个人的结论必须由人结合上下文复核后才能使用。
在工具层面，边界清单、评审记录和权限配置需要可追踪的载体。ONES 的 AI 研发管理方案围绕真实项目、真实知识和真实权限运行，基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等工作上下文，围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与资源合理性建议。这些能力适合承载“清单评审—权限开通—结果解读”的流程记录，具体的字段级采集范围和角色粒度仍需结合团队配置确认。
从明细到聚合：脱敏、聚合与AI使用规则
数据进入AI分析前后要经过两道收敛：采集时收敛到最小必要字段，分析时收敛到聚合层级。规则可以按以下条目落地。
- 个人明细最小化采集：只采集分析问题明确需要的字段，成员姓名、联系方式等标识字段在进入分析数据集前替换为编号。
- 明细访问限制：原始明细仅对数据负责人开放，访问需留日志；其他角色通过聚合看板获取结果。
- 聚合层级与样本保护：按团队或项目聚合，小组人数低于设定阈值时合并到上一级展示，避免个体被识别。
- AI输入限定：送入AI分析的数据为聚合结果和必要的上下文说明，不直接投喂个人明细。
- AI输出定位：AI输出作为辅助判断的线索，用于提示风险方向、生成待核实的问题清单，不直接生成人员绩效结论或排名。
- 异常回溯路径：聚合结果出现异常波动时，由数据负责人按清单授权范围回溯明细，记录回溯原因与结论，回溯记录纳入复核材料。
这些规则要写成条目并附在边界清单之后，与清单同步评审。规则调整时同步更新清单中的对应字段，避免文档与执行脱节。
示例：一个迭代效能分析的数据边界清单
以下为演示情景，用于说明清单如何填写，不代表任何具体团队的真实数据。
场景：某研发团队希望分析最近三个迭代的交付节奏，找出需求在流转中的积压环节。对应分析问题有两个：迭代内需求完成率为何波动；需求在评审与开发环节各停留多久。
| 数据项 | 来源系统 | 字段与粒度 | 聚合层级 | 使用目的 | 可见角色 | 保留期限 | 脱敏方式 |
|---|---|---|---|---|---|---|---|
| 工作项状态变更 | 项目管理工作项 | 工作项ID、状态、变更时间，单条记录 | 团队级按周聚合 | 计算各环节停留时长 | 数据负责人看明细，团队负责人看聚合 | 明细90天，聚合1年 | 成员以编号替代 |
| 迭代范围与完成情况 | 迭代管理 | 迭代ID、计划项数、完成项数 | 迭代级 | 计算完成率 | 研发管理者、团队负责人 | 1年 | 无需个人标识 |
| 需求变更记录 | 需求管理 | 需求ID、变更类型、变更时间 | 团队级月度 | 识别范围变更对节奏的影响 | 研发管理者、数据负责人 | 6个月 | 去除提出人姓名 |
链路运行方式：数据负责人按清单接入上述字段，完成脱敏与聚合，生成团队级停留时长与完成率指标；研发管理者将聚合指标和迭代背景说明提交给AI分析，得到“评审环节停留偏长”的观察和若干待核实问题；团队负责人结合本团队实际排期解释异常，形成结论记录。示例中的取舍是：成员个人维度的任务分布数据本轮不纳入，因为当前分析问题聚焦流程环节而非个人负载；如需分析协作负载，应另立分析问题并补充对应数据项与边界字段。
完成检查：边界是否真正生效
边界建立后需要验证它是否在执行中生效，而不是停留在文档里。可按以下检查表逐项核对。
| 检查项 | 通过标准 |
|---|---|
| 清单完整性 | 每个数据项七个字段均已填写，无“按需”“待定”等模糊表述 |
| 评审记录 | 清单经过研发管理者、数据负责人与合规角色评审并留有签署记录 |
| 权限与访问日志 | 明细访问仅限授权角色，日志可查；聚合看板权限与清单中的可见角色一致 |
| 聚合一致性抽样 | 抽取若干团队，核对聚合结果与明细汇总一致，偏差在可解释范围内 |
| AI输出复核 | 抽查AI分析结论，均有对应的人工解读记录，未出现直接用于人员评价的输出 |
| 复核周期 | 按季度或半年复核一次；新增分析问题、接入新数据源、组织调整时触发即时复核 |
发现越界后的处置动作要事先约定：暂停相关数据接入或权限，由数据负责人记录越界范围与影响，合规角色评估是否需要通知相关人员，修订清单后重新评审再恢复。处置记录与复核记录一并归档，作为下一轮检查的输入。
常见问题
团队规模很小，一人兼多个角色时，数据边界还需要分开写职责吗？
需要分开写，但可以合并到同一个人身上。职责分开写的作用是让每类判断都有明确归属：谁提出分析问题、谁维护清单与权限、谁评审个人数据的使用目的、谁解释结果异常。小团队里同一个人既提问题又配权限时，建议在清单评审记录中分别注明这两项职责的确认过程，避免“自己定、自己用、自己解释”缺少复核环节。
分析问题中途变化，已经采集的数据怎么处理？
新增分析问题属于即时复核的触发条件。处理顺序是：先补充该问题对应的最小必要数据项和边界字段，经评审后再接入数据；原问题不再需要的数据项，按清单中的保留期限到期清理，或提前停止采集并记录原因。已经进入AI分析的聚合结果，如果对应问题已撤销，应在复核记录中标注停用，避免旧结论继续被引用。
聚合结果里某个小组人数很少，怎么避免被反推出个人？
在边界清单的聚合层级字段中预设样本阈值，人数低于阈值的小组合并到上一级组织展示，或只呈现跨团队的合计值。同时检查时间维度：按周聚合且小组人数少时，连续几周的波动也可能指向个人，可以改为月度或季度聚合。阈值和合并规则要写进清单，与脱敏方式一并评审。
AI给出的效能分析结论和团队负责人的判断不一致时，以哪个为准？
以人的判断为准，AI输出定位为辅助线索。团队负责人结合排期变化、人员变动、需求范围调整等上下文解释数据，形成结论记录；如果认为AI观察不成立，应写明不成立的理由和依据。这类分歧记录本身就是复核材料，可以帮助下一轮调整分析问题的提法和数据项范围。
发现有人越权查看了个人明细，应该怎么处置？
先暂停相关数据接入或权限，由数据负责人记录越界范围、涉及的数据项和影响面；合规角色评估是否需要通知相关人员；修订清单中的可见角色或权限配置后重新评审，再恢复使用。处置记录与复核记录一并归档，作为下一轮检查的输入。处置动作要在边界建立时就事先约定，避免事发时临时决定。
