研发数据权限要解决的是“谁能看哪一层数据、能做什么操作、例外怎么批”的问题。可执行的做法分四步：先按敏感度把数据分成原始明细、聚合指标、对外呈现三层，再按角色写出权限矩阵，然后把规则配置到具体看板和报表，最后用申请审批、定期复核和审计记录验证执行效果。本文给出可直接填写的数据分级表、角色权限矩阵、申请单模板和完成检查清单，适用于正在搭建或修订研发度量权限机制的团队。
要点总览（TL;DR）
- 研发数据权限按三个维度分级：敏感度分原始明细、聚合指标、对外呈现三层，数据范围分个人、团队、部门、全组织，操作类型分查看、导出、修改、分享。
- 角色矩阵按“角色×数据层级×操作类型”编写，默认遵循最小权限，导出和分享单独授权，数据所有者对口径和可见范围负最终责任。
- 权限要落到具体看板和报表：可见范围按团队或项目设置，导出留痕，聚合指标与明细下钻分开控制，新看板继承默认权限。
- 例外权限走申请审批，申请单写明用途和期限，临时权限到期回收，季度或半年度复核授权名单与人员变动。
- 机制是否生效看证据：分级表覆盖全部看板、无绕过审批的导出通道、审计日志可查、复核有记录、离职转岗权限及时回收。
研发数据权限先分哪几层、按什么标准分
分级是权限设计的第一步，目的是让“这条数据该给谁看”有统一判断依据，而不是每次靠人拍板。建议同时用三个维度切分：敏感度决定数据本身的开放程度，数据范围决定可见边界，操作类型决定同一份数据可以做什么。
按敏感度划分三层。原始明细数据指未聚合的个体记录，例如某位开发人员单个需求的停留时长、单次代码提交量、个人缺陷数；聚合指标数据指经过汇总的团队或项目级结果，例如迭代交付周期、需求吞吐量、缺陷密度；对外呈现数据指用于汇报、对外披露或跨部门共享的结论性数据，例如季度效能趋势和整体达成率。判断一条数据属于哪一层，重点看三个问题：是否含个人信息，是否含薪酬或绩效评价，是否能反推到具体个人。任一答案为“是”，就应按更高敏感层处理。
按数据范围划分个人、团队、部门、全组织四级，与敏感度交叉使用。个人层数据默认只对本人和直接主管可见；团队层对团队成员及团队负责人可见；部门层对部门管理者可见；全组织层经数据所有者确认后开放。按操作类型划分查看、导出、修改、分享四类，其中导出和分享的风险高于查看，应单独授权。
| 层级 | 示例数据 | 敏感原因 | 默认可见范围 |
|---|---|---|---|
| 原始明细 | 个人需求停留时长、个人提交量、个人缺陷数 | 可反推到个人，可能关联绩效评价 | 本人、直接主管；数据管理员按需 |
| 聚合指标 | 团队迭代交付周期、项目需求吞吐量、缺陷密度 | 团队间可比，可能间接反映个人表现 | 团队成员、团队负责人、部门管理者 |
| 对外呈现 | 季度效能趋势、整体达成率、汇报用图表 | 影响面广，口径需统一 | 经数据所有者确认后按范围开放 |
这张表是后续所有配置的依据。完成标志是：组织内每一类看板和报表都能对应到表中某一层，且每层都写明了默认可见范围。分级结果需要数据所有者签字确认，避免口径在配置阶段被随意放宽。
角色与权限矩阵怎么定：谁看什么、谁批什么
分级解决“数据分几层”，角色矩阵解决“人和权限怎么对应”。常见四类角色：数据所有者对某类数据的口径和可见范围负最终责任，通常是效能度量负责人或研发管理部门负责人；数据管理员负责日常配置、账号与权限维护；看板使用者按岗位查看授权范围内的数据；审计方独立检查权限执行情况，不参与日常审批。
矩阵的行是角色，列是“数据层级×操作类型”的组合。填写时先给默认值，再标注例外。默认遵循最小权限：使用者只获得完成当前工作所必需的层级和操作，导出、分享、修改默认关闭，需要时走申请流程。数据所有者对本角色负责数据的口径定义和可见范围调整拥有最终决定权，管理员执行配置，两者职责分开，避免配置权与定义权集中在同一人手中。
| 角色 | 原始明细·查看 | 聚合指标·查看 | 对外呈现·查看 | 导出 | 修改配置 | 审批职责 |
|---|---|---|---|---|---|---|
| 数据所有者 | 按需 | 是 | 是 | 是 | 审批口径与范围变更 | 数据范围与口径变更 |
| 数据管理员 | 按需 | 是 | 是 | 按授权 | 是 | 常规权限申请 |
| 团队负责人 | 本团队 | 本团队 | 是 | 申请后 | 否 | 本团队临时申请初审 |
| 看板使用者 | 本人 | 本团队 | 是 | 申请后 | 否 | 无 |
| 审计方 | 只读核查 | 只读核查 | 只读核查 | 否 | 否 | 复核与抽查 |
矩阵填写完成后，应附一份角色职责说明，写清每个角色的决策边界：谁能批准跨团队查看、谁能批准导出原始明细、谁负责季度复核。完成标志是矩阵覆盖全部角色与数据层级组合，且每个“是”都能追溯到具体责任人。
配置到看板与报表：访问控制怎么落地
矩阵写在文档里只是约定，配置到看板和报表上才真正生效。配置时按对象逐项登记，形成清单，避免遗漏或重复授权。
- 看板可见范围按团队或项目设置。团队看板默认对本团队成员和负责人开放，跨团队查看需申请。项目看板跟随项目成员关系，成员变动时权限同步调整。
- 导出单独授权并留痕。查看权限不自动包含导出权限。导出原始明细需单独申请，系统记录导出人、时间、数据范围和用途，便于事后核查。
- 聚合指标与明细下钻分开控制。允许查看团队聚合指标，不等于允许下钻到个人明细。下钻入口按角色开放，未授权用户只能看到汇总值。
- 新看板继承默认权限。新建看板默认继承所属团队或项目的可见范围，创建人需在发布前确认敏感层级并补充导出设置，防止新看板成为权限盲区。
| 配置对象 | 可见角色 | 导出权限 | 负责人 |
|---|---|---|---|
| 团队迭代效能看板 | 团队成员、团队负责人 | 仅负责人可导出聚合数据 | 团队负责人 |
| 个人效能明细报表 | 本人、直接主管 | 默认关闭，申请后开放 | 数据管理员 |
| 部门季度汇报看板 | 部门管理者、数据所有者 | 数据所有者可导出 | 数据所有者 |
在ONES研发效能管理解决方案中，管理者可以从统一入口查看多项目、多团队、多流程的效能表现，报表制作与工作汇报也有对应的数据展示支持。团队在配置这类看板时，可把上面的清单作为核对依据，逐项确认可见范围和导出设置；具体的权限配置方式与审计能力，建议在选型或实施阶段向厂商核实。
申请、审批与定期复核机制怎么建
默认权限之外的需求通过申请流程处理，关键是让每次例外都有记录、有期限、有人负责回收。权限申请单至少包含以下字段：申请人及所属团队、申请的数据范围（层级、看板或报表名称）、用途说明、需要的操作类型、使用期限、审批人。用途写得越具体，审批判断越有依据。
审批人按数据层级确定：聚合指标和对外呈现数据由数据管理员审批；原始明细数据由数据所有者审批；跨部门范围申请增加申请方负责人会签。审批时限建议约定为两个工作日内响应，超时提醒升级。临时权限必须设置到期时间，到期自动回收，确需延长的重新提交申请，避免临时权限长期滞留。
定期复核按季度或半年度执行，复核清单包括：当前所有授权名单、每项授权的申请依据、到期未回收的临时权限、离职和转岗人员权限状态。复核人由数据所有者和审计方共同担任，复核结论记录在案，发现的问题明确整改责任人和完成时间。
| 复核检查项 | 通过标准 | 证据 |
|---|---|---|
| 授权名单完整性 | 每项授权都有对应申请单 | 申请单与授权记录对照表 |
| 临时权限回收 | 到期权限全部关闭或已续期 | 到期清单与回收记录 |
| 人员变动处理 | 离职、转岗权限在约定时限内调整 | 人事变动与权限变更记录 |
示例：一个研发团队的权限落地过程
以下为演示情景，用于说明流程如何连续运转，不对应真实客户案例。某研发团队有12名成员，使用迭代效能看板跟踪交付数据，同时维护一份含个人绩效相关指标的明细报表。
分级阶段，团队把迭代交付周期、需求吞吐量归为聚合指标，把个人需求停留时长、个人缺陷数归为原始明细，把季度汇报图表归为对外呈现。角色分配上，研发经理担任数据所有者，效能专员担任数据管理员，团队负责人和成员为看板使用者，质量部门指定一人担任审计方。
一次临时导出申请的流转：团队成员因季度复盘需要导出近三个月团队聚合指标，提交申请单，写明用途为复盘材料、期限三天。数据管理员在两个工作日内审批通过，开通导出权限并记录导出范围。三天后权限到期自动回收，申请人如需继续使用重新提交。
季度复核时，审计方对照授权名单发现一名已转岗成员的明细报表查看权限未及时调整，仍保留原团队范围。复核结论要求数据管理员在三个工作日内收回并重新按新岗位授权，整改结果记入复核记录。这次发现说明复核不能只看新增申请，还要核对人员变动带来的存量权限。
完成检查：权限机制是否真的生效
机制是否生效，看证据而不是看制度文件是否发布。以下清单可逐项核对，每项都应有明确负责人和可查记录。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 分级表与矩阵覆盖度 | 全部看板和报表都能对应到数据层级与角色权限 | 分级表、权限矩阵、看板清单 | 数据所有者 |
| 导出通道受控 | 不存在绕过审批的导出方式 | 导出授权记录与系统配置截图 | 数据管理员 |
| 审计日志可用 | 权限变更与导出行为可查，保留周期已明确 | 日志查询记录、保留策略说明 | 审计方 |
| 复核按期完成 | 最近一次复核有结论和整改记录 | 复核报告 | 数据所有者、审计方 |
| 人员变动回收及时 | 离职、转岗权限在约定时限内调整 | 人事变动与权限变更对照记录 | 数据管理员 |
检查中发现的问题应形成整改清单，明确责任人和完成时间，并在下一次复核时验证关闭情况。权限机制的价值在于让数据开放有边界、例外有记录、责任可追溯，这套检查清单可以按季度重复使用，作为机制持续运转的验收依据。
常见问题
研发数据里哪些内容最需要单独控制权限？
优先控制三类内容：一是可反推到个人的原始明细，例如个人需求停留时长、个人提交量、个人缺陷数；二是与绩效评价、薪酬相关的数据；三是导出和分享动作。判断标准是三个问题——是否含个人信息、是否含薪酬或绩效评价、是否能反推到具体个人，任一答案为“是”就按更高敏感层处理。团队聚合指标可以相对开放，但下钻到个人明细的入口要单独授权。
团队规模不大，还需要做完整的角色矩阵和审批流程吗？
规模小的团队可以简化角色数量，例如数据所有者和数据管理员由两人分担，审批环节合并为一次确认，但分级和导出留痕建议保留。原因是权限风险主要来自两处：原始明细被随意扩散，以及导出后脱离系统管控。团队人数少时，复核频率可以从季度调整为半年，但人员转岗、离职时的权限回收仍要及时执行。机制复杂度应与数据敏感度和人员流动频率匹配，不必照搬大组织的全套流程。
看板权限配置好了，为什么还要单独管导出？
查看权限只约束数据在系统内的可见范围，导出会把数据带到系统之外，后续的传播和使用不再受看板控制。因此导出应作为独立操作授权，并记录导出人、时间、数据范围和用途。原始明细的导出尤其要单独审批，聚合数据的导出可以按角色开放。检查时重点确认是否存在绕过审批的导出通道，例如截图、复制粘贴或第三方工具拉取，这些通道同样需要在制度中说明约束方式。
定期复核应该重点看什么，容易漏掉哪些情况？
复核不能只看新增申请，存量权限同样要核对。重点包括：每项授权是否有对应申请单、临时权限是否到期回收、离职和转岗人员的权限是否已按新岗位调整。实践中容易漏掉的是人员变动带来的存量权限，例如转岗后仍保留原团队的明细查看范围。复核人建议由数据所有者和审计方共同担任，结论记录在案，发现问题明确整改责任人和完成时间，并在下一次复核时验证关闭情况。
选型研发效能工具时，权限方面要核实哪些能力？
建议在选型或实施阶段向厂商核实四点：看板与报表的可见范围能否按团队、项目或角色配置；导出能否单独授权并留下记录；聚合指标与明细下钻能否分开控制；审计日志能否查询权限变更和导出行为，保留周期多长。ONES研发效能管理解决方案提供统一入口查看多项目、多团队、多流程的效能表现，并支持报表制作与工作汇报的数据展示（F1、F2）；具体权限配置方式与审计能力需向厂商确认。把这些问题列入选型清单，比只看功能列表更能判断权限机制能否落地。
