研发管理工具的权限模型怎么设计：按角色还是按项目分权

新同事入职三天还在挨个找人开权限、外包人员离场两周账号还留着、项目负责人看不到本项目的成本字段，这些问题的根源是同一个：权限模型没有先确定分权维度。研发管理工具的权限设计绕不开一个分歧，按角色分权还是按项目分权。两者管的并不是同一件事。

一、先把两个维度分开看

1. 角色分权：以人为主体的功能授权

角色分权把权限先给角色，再由角色赋给用户，用户不直接持有权限，业界称这套做法为RBAC，即基于角色的访问控制。它由Ferraiolo与Kuhn在1992年提出，1996年由Sandhu等人整理为RBAC0到RBAC3的模型族，2000年前后整合为统一的NIST RBAC模型，2004年成为ANSI/INCITS 359-2004标准，2012年修订为INCITS 359-2012。它回答的是：这个人能不能创建需求、关闭Bug、执行发布。

2. 项目分权：以数据为主体的范围授权

项目分权以项目为管理单元，先确定成员属于哪些项目，再由成员关系决定可见和可修改的数据。它回答的是：这个人能看到哪个项目的数据。

3. 两个维度是交叉关系

功能授权决定能做哪些动作，数据范围决定对哪份数据做，两者的组合才是完整的权限。功能权限宽、数据范围窄，适合职能管理；功能权限窄、数据范围宽，适合整体跟踪；两者都受限的是项目内执行角色；两者都放开的是平台管理员。角色决定能进哪类区域，项目决定能进哪几个房间，缺一个都走不通。

下表对比两种分权方式在授权对象与失效信号上的差别。

两类失效信号并不重叠。同时出现角色不够用和项目间数据串了，问题通常不在模型本身，而在缺少分层。

二、按角色分权的适用边界

1. 它换掉的是重复授权

团队只有五个人时，权限可以口头说清；到几十人、上百人，逐个授权既慢又容易漏。角色分权的价值在于用一次配置替换掉多次重复配置。

2. 角色膨胀来自按岗位名建角色

同一个叫经理的岗位，可能分别负责需求排期、交付进度和审批付款。角色应按职责定义，而不是按职位名称定义。当角色数量接近甚至超过人数，通常说明颗粒度切错了。

3. 它管不到数据范围

同一个测试角色，在甲项目只需看用例和Bug，在乙项目可能要接触客户提交的敏感信息。角色本身无法表达这种差别，需要再叠加一层数据范围规则。

组织稳定、职能边界清楚、项目间数据敏感度接近时，角色分权足以支撑；项目多、数据边界复杂时，单独使用会比较吃力。

三、按项目分权的适用边界

1. 它换掉的是隔离成本

把成员授权挂在项目上，入项即授权、出项即回收。外部协作者和跨部门借调人员只需挂到具体项目，不必先进入组织架构。

2. 同一件事要配多次

一个人参与五个项目，就要在五处各配一次权限。常见降本方式有三种：用项目模板复用成员组合，把多个项目归组后统一授权，给跨项目共用的需求池单独设规则。

3. 全局视角容易缺失

项目分权只覆盖项目内部。组织级统计口径、跨项目效能看板、平台级配置权限，都需要在项目之外单独设计，否则容易出现单个项目看得清、合并后对不上的情况。

项目之间需要数据隔离、人员流动频繁、存在外部协作者时，以项目为主骨架更贴合实际。

四、三层叠加的落权结构

多数中大型团队的做法不是二选一，而是分层叠加。

1. 组织层定功能上限

先定义有哪几类职责，每类职责对应哪些功能动作。这一层只回答最多能做什么。

2. 项目层定数据范围

角色确定后，由项目成员关系决定该角色在项目内的作用范围。同一个人在不同项目里可以拥有不同身份，这是项目分权的主要价值。

3. 字段与操作层定敏感动作边界

最小权限原则要求每个主体只持有完成当前任务所需的最小权限，这一思路最早由Saltzer与Schroeder在1975年的论文中系统提出。落地时通常对删除、批量导出、权限配置以及成本、合同这类字段单独设阈值，必要时补一道审批。

三层的关系可以概括为：角色给能力，项目给范围，规则给边界。

五、判断与治理

1. 五个判断问题

• 员工是否同时参与多个项目，且项目之间需要数据隔离？
• 同一岗位在不同项目承担的工作是否基本一致？
• 是否存在外部协作者、外包或跨部门借调？
• 有没有必须限制到字段级别的信息，比如成本、合同、客户资料？
• 谁负责权限复核，多久复核一次？

前两问指向项目分权，第三问决定要不要保留项目级临时授权，后两问决定是否需要补上角色层和字段层。其中数据是否需要隔离、职责是否稳定，是最关键的两个判断。

2. 三个高频误区

• 按岗位名称建角色，角色越建越多。
• 认为进入项目组就应看到全部数据，忽略字段级差异。
• 权限只加不减，人员调动后旧权限长期留存。

3. 权限复核的常规动作

入项授权、出项回收写进固定流程；每季度复核一次，重点检查长期未使用的高权限；角色清单、项目成员清单和例外授权集中留存，便于追溯；敏感操作保留操作日志。

六、常见问题

1. 同一个人被授予多个角色时，权限是叠加还是取最大？

按并集计算，但受约束规则限制。角色权限叠加后，再由职责分离规则排除互斥组合，例如发起付款与审核付款一般不允许由同一人同时持有。

2. 权限调整之后，什么时候开始生效？

取决于会话机制。多数系统在用户下次登录或会话刷新时重新计算有效权限，已登录的会话可能沿用旧权限直到过期，因此紧急回收权限时往往需要同时失效在线会话。

3. 项目已经结束，历史数据还要不要保留访问权限？

建议保留只读，收回写入。项目结项后数据常用于复盘与审计，完全收回访问会影响追溯；而可编辑权限继续保留，容易造成历史数据被改动。

4. 权限体系上线后最常见的返工原因是什么？

数据范围规则缺位。功能权限在上线前通常梳理得比较完整，数据范围却常被默认成全员可见，等出现越权查看再补，返工量和沟通成本都更高。