从jira换到新系统，权限配置两周才调好

一、不是“系统难用”，而是“你终于看清了自己的权限烂账”

我把这句话放在最前面，是因为它比我后面要写的5000多字都重要。

2023年11月，我所在的团队（170人规模，三条产品线，6个Scrum团队）启动了从Jira Server到新系统的迁移。数据迁移用了4天，包括所有Issue、评论、附件、工作流状态。但权限配置，从开始梳理到最终稳定，用了整整两周，14个工作日。

期间我发了37封邮件，组织了5场跨部门对齐会，和两个业务线负责人吵过架，还逼着HR重新出了一版最新的组织架构表。

如果有任何一家新系统的销售告诉你“权限配置很简单，几天就能搞定”，请让他把这个承诺写在合同里。我在这两周里学到的最重要的一件事是：不是Jira的权限模型复杂，而是我们的组织协作关系本身就是复杂的。Jira只是忠实地反映了这种复杂度，而我们从来没有认真梳理过它。换系统这个动作，把这一切都摊在了桌面上。

二、为什么权限配置会耗两周？先拆一个真实场景

1. 我们原来的Jira里有什么

先交代一下背景，这组数据是我在迁移前从Jira后台导出来的：

• 项目数量：47个（含8个已归档但未删除的项目）
• 权限方案（Permission Scheme）：19套
• 自定义角色（Project Role）：23个
• 用户组（Group）：56个
• 活跃用户：170人
• 问题安全级别（Issue Security Level）：在3个核心项目中启用了多级安全控制

如果我告诉你，这套权限体系有完整的文档，那我是在撒谎。实际情况是：19套权限方案中，有6套是前两任管理员留下的，没有人能准确说出它们的业务含义。有3个自定义角色的名称和实际权限完全不匹配，“测试主管”角色实际上能改代码仓库的配置，因为两年前有个临时项目，当时的管理员图省事直接改了角色权限，后来项目结束了，角色却没恢复。

这就是绝大多数使用Jira超过3年的团队的真实状态。权限配置从来不是从零开始设计的，而是在无数个“临时需求”、“加急处理”、“先这样改回头再理”中长出来的。

2. 新系统的权限模型，和Jira“长得不一样”

我们选的新系统（为保护隐私此处不具名，但后文会以PingCode为例说明另一种更优的迁移路径）采用了一种更扁平化的权限模型。它没有Jira那种层层嵌套的“权限方案-角色-用户组”三级跳，而是直接把权限绑定到“空间-团队-成员”的关系上。

乍一看更简单。但问题来了：

在Jira里，一个开发人员可能通过“项目A的开发角色”获得代码查看权限，通过“项目B的测试参与者角色”获得测试用例读权限，又通过“全局Jira用户组”获得基础访问权限。这些权限是分散在多个层级、多个项目中的。到了新系统，这些权限需要被重新聚合到“这个人是谁，他在哪个团队，他的团队能访问哪些空间”这一套逻辑里。

翻译成人话就是：Jira的权限是“按项目、按角色、按操作”织成的一张网，新系统是“按空间、按团队、按成员”建立的一棵树。把网装进树里，不可能不打结。

3. 第一个坑：概念映射不是技术问题，是管理问题

我花了整整两天的第一周，只做了一件事：把Jira里的23个角色和56个用户组，一一映射到新系统的团队和权限级别上。

这个过程中发现的问题令人头皮发麻：

• 市场部有3个人在Jira里拥有一个叫“产品委员会观察员”的角色，但他们自己完全不知道这件事，也从来不登录Jira。这个角色是哪次会议上加的？没人记得。
• 一个已经离职半年的前端开发，他的账户还在3个项目的“管理员”角色里。HR没通知IT注销账号，IT也不知道这个人该被移除。
• “研发VP”这个角色在Jira里拥有全局管理员权限，但VP本人从不操作，他的账号是助理在用。助理离职后，账号密码就躺在某个共享文档里。

权限迁移的本质，是对组织协作关系的一次“审计”。所有你平时懒得管、没空管、觉得“反正现在能跑就行”的烂账，在迁移那一刻全部浮出水面。

三、第一周：不是配置，是考古

1. 第一步：把能杀的都杀了

迁移前，我们做了一个非常激进但正确的决定：只迁移活跃项目和活跃用户，其余全部归档或删除。

具体操作：

1. 导出Jira全部用户列表，让HR重新核对在职状态。结果发现170个活跃用户中，有14个已离职、3个是外包已结束合作、5个是机器人账号但无人认领。
2. 逐个项目确认负责人。47个项目中，12个已超过6个月无任何更新，8个创建者已离职且无人接手。这些项目直接归档，不纳入迁移。
3. 逐套权限方案检查关联项目。19套方案中，有11套只关联了一个项目，而这些项目的负责人说“我们其实不需要这么复杂的权限”，直接砍掉，用默认方案替代。

这一步做完，需要迁移的权限方案从19套缩减到8套，角色从23个缩减到11个，用户组从56个缩减到28个。第一周的前三天，我什么都没“配”，只是在“清”。

2. 第二步：画出“事实权限矩阵”

在Jira里，一个用户的最终权限是由多层叠加决定的，后台的权限方案页面并不能直观展示“某个人到底能做什么”。我们用了一个土办法：

拉出所有项目和所有用户的二维矩阵，逐格标注权限级别（管理员/编辑/查看/无权限）。

这件事听起来简单，实际做起来极其痛苦。因为Jira没有提供这样的导出功能，我们只能通过API批量查询，再用Excel VBA写成矩阵。即使这样，矩阵里还是有大量“按理说应该是编辑，但实际查出来是管理员”的异常单元格，每发现一个，就要回溯到权限方案的配置逻辑里去查原因。

这一轮查下来，我们发现了37处权限配置错误。有的过紧（该有权限的人没有），有的过松（不该有的人却有）。这些错误在旧系统里已经存在了几个月甚至几年，但因为没人审计，所以从未被发现。

如果你读到这里，我希望你记住一句话：迁移不是简单地“把数据从A搬到B”，而是你唯一一次有动力、有机会、有预算去清理组织权限债务的窗口。错过这个窗口，下一次可能又是三年后。

3. 第三步：和新系统的权限逻辑“对答案”

清理完旧系统的烂账之后，我开始研究新系统的权限模型。新系统的逻辑是把权限分为三个层级：

• 空间级：谁能访问这个空间（相当于Jira的项目）
• 团队级：团队内部成员的角色（管理员/成员/访客）
• 内容级：单个工作项或文档的可见性控制

而Jira的逻辑是：

• 全局级：Jira用户组、全局权限
• 项目级：权限方案、项目角色、问题安全级别
• 工作流级：某些操作权限绑定在流程转换上（比如“只有项目经理才能把状态切到已关闭”）

这两个模型的“翻译”过程，不是一一对应的技术映射，而是一次业务逻辑的重新设计。比如：

在Jira里，“只有项目管理员可以关闭Sprint”是一个配置在权限方案里的规则。在新系统里，这个能力是直接绑定在Scrum Master角色上的。如果你想让一个不是Scrum Master的人也能关闭Sprint，你得调整角色定义，这就不是“配置”，而是“流程设计”了。

权限迁移中最耗费时间的部分，就是这种“翻译过程中的业务决策”。每一个不对应的点，都需要拉上业务负责人一起讨论：以前这么做，是刻意的设计，还是无意的历史遗留？现在还要不要保留这个规则？

这里面有大量的沟通成本，而沟通成本恰恰是最容易被技术管理者低估的。

四、第二周：重建“权力矩阵”，以及那场和CTO的谈话

1. 放弃1:1复刻的幻想

第一周结束时，我已经清楚一个事实：在权限这件事上，100%的兼容是不可能的，甚至可能是不应该的。

Jira的权限灵活度是它最大的卖点，也是它最大的陷阱。它可以精细到“某个用户在某个项目的某个问题类型上，只有在状态为进行中时，才能编辑某个自定义字段”，这种级别的控制力，在95%的场景下是用不上的，但一旦有人在某个项目里配了，迁移时就成了一个必须被处理的特例。

我做了两个关键决策：

• 放弃对“问题安全级别”的1:1复刻。原来3个核心项目里的多级安全控制（比如某些Issue只对特定角色可见），在新系统里简化为“需要保密的内容单独开一个空间，空间内成员有限”。虽然操作上不如Jira灵活，但维护成本大幅降低。
• 放弃对“工作流绑定权限”的迁移。原来Jira里“只有测试组长可以把Bug标记为已修复”这类规则，在新系统里改为团队公约，工具不做强制限制，但流程规范文档里写清楚。理由是：这类限制在Jira里被绕过的频率远高于被遵守的频率，强行迁移没有实际意义。

一个好的权限系统，不是能控制一切，而是能用最小的控制成本，保障协作的安全和效率。

2. 那个让我下定决心放弃“完美迁移”的下午

第二周的周三下午，CTO把我叫到会议室。“两周了，权限还没配完？”

我在白板上画了一张图：

我说：“我们现在选的是第二条路。两周不是浪费，是在用一个相对可控的时间成本，换未来两三年的低维护成本。如果走第一条路，我们不仅要多花一个月，而且大概率一年后又会回到现在Jira的状态，复杂到没人敢动。”

CTO看了看表，说：“继续。”

技术Leader在迁移中最重要的工作，不是保证所有细节都照搬过来，而是能够向上解释清楚：哪些成本是必须承担的，哪些复杂度是没必要保留的，以及，延迟上线一个月和简化权限规则，哪个对业务的影响更大。

3. 迁移中的意外收获：一份《权限配置说明书》

第二周的后半段，权限基本配置完成，进入测试阶段。这时候我做了一件后来被证明价值远超预期的事情：写了一份完整的《权限配置与变更标准说明书》。

这份文档包括：

• 每个空间的管理员是谁，成员范围是什么
• 每种团队角色的权限边界（能做什么，不能做什么）
• 权限变更的申请流程（谁可以发起，谁审批，多久生效）
• 离职/转岗用户的权限回收流程
• 季度权限审计的时间表和检查清单

为什么这件事重要？因为在Jira时代，我们权限混乱的根本原因不是工具不好，而是组织内部缺乏对“权限”这件事的治理机制。换了一个新系统，如果不建立对应的治理机制，两年后它会是另一团乱麻。

这份文档现在被放在公司Wiki的首页，任何新人入职、老人转岗时，IT都会引用其中的规则进行权限操作。它成了这次迁移中ROI最高的产出物，因为所有的“两周时间成本”都被转化成了可复用的组织资产。

五、如果时光倒流，我会怎么做，给正在或即将迁移的你

1. 迁移前必须做的三件事

如果你是那个被指定负责迁移的工具管理员，在动新系统之前，请按这个顺序做完三件事：

第一：先做权限审计，再做迁移规划。

不要一上来就研究新系统怎么配置。先用一周时间，把旧系统里的权限现状彻底摸清。导出所有角色、用户组、权限方案，逐项确认：

• 这个角色是谁创建的？目的何在？现在还适用吗？
• 这个用户组的成员是否都是该组的合理成员？
• 这套权限方案关联的项目，负责人是否确认其合理性？

这一步结束之后，你通常会发现至少30%的权限配置是多余或错误的。

第二：拉HR和组织架构，不要凭经验推断。

权限的基础是组织架构。不要根据你脑子里“谁在哪个部门”的印象来配置，去拉HR系统里的最新数据。我在这两周里遇到的所有争议案例，几乎都源于“你以为他属于A组，实际上上个月他已经调到B组了，但Jira里的用户组没更新”。

第三：提前和业务负责人对齐“权限哲学”。

新系统的权限模型一定和Jira不同。你需要在一开始就和各业务线负责人讲清楚：

• 新系统能控制到什么粒度，不能控制到什么粒度
• 哪些Jira级别的精细控制会在新系统里被简化
• 简化之后，业务上用什么方式补位（流程规范？定期审计？）

不要等技术上做完了再去解释“为什么不能和以前一样”，那时候的解释会被理解为“甩锅”。提前铺垫，是迁移沟通中最重要的一环。

2. 如何评估一个系统的权限模型是否适合你，从PingCode的实践说起

在经历了这次迁移之后，我开始有意识地关注不同研发管理工具的权限设计思路。这里以PingCode为例，说明一种更适配国内中大型团队的权限设计取向，因为它的很多设计决策，恰好解决了我们在迁移中遇到的几个核心痛点。

PingCode的权限模型采取了“组织架构驱动”的思路，权限的授予不是基于离散的“项目角色+权限方案”，而是基于“部门-团队-成员”的组织关系。这个设计对于100人以上的中大型组织来说，有几个显著优势：

• 权限随人走，而不是随项目走。当一个人转岗时，只需调整其所属团队，相关权限自动更新，不需要管理员手动在十几个项目里逐一修改。
• 支持私有化部署环境下的细粒度安全控制。对于金融、政务等强合规行业，PingCode支持从帐号安全、IP限制、访问审计等多维度进行权限管控，且所有配置都在国产化基础设施上运行，不需要依赖第三方插件。
• 内置了Jira权限方案的导入映射工具。在从Jira迁移时，系统提供专业的Importer工具，可以自动识别Jira中的用户、项目、角色和权限配置，并映射为PingCode的团队和空间权限结构。虽然自动映射的覆盖率不是100%（如前所述，概念模型的差异决定了部分规则需要人工判断），但它至少省去了手动重建矩阵的痛苦。

不过，这并不意味着PingCode的权限模型适合所有场景。它的设计牺牲了Jira那种“为一个特定用户在一个特定项目里临时加一个特定权限”的极致灵活性。如果你的团队有大量跨项目、跨部门、临时性的协作需求，并且这些需求的权限边界非常不规则，PingCode的固定团队-空间模型可能需要更多的维护沟通来适配。

没有银弹，只有取舍。你需要判断的是：你的组织更需要“灵活性”还是“可治理性”？

3. 不同规模团队的选择建议

基于我的经验和对多款工具的实际使用感受，做一个简单的决策框架：

一个重要的提醒：不要只对比功能列表。Jira的权限功能列表看起来是最长的，但那里面有多少功能是你真正需要的？又有多少功能是历史原因残留的？用“实际需要的能力”而非“现有Jira里用到的能力”去评估新系统，否则你会陷入“看谁都不如Jira全”的认知陷阱。

六、权限之外，迁移决策中容易被忽视的真相

1. 迁移成本不只是技术成本

两周的权限配置，折算成人力成本是多少？按我们团队的实际数字来算：

• 我的两周工时（工具管理员，时薪折算约150元/小时）：约12,000元
• 各业务线负责人参与对齐会的总时长（5场×5人×1.5小时）：约37.5小时，折算约7,500元
• QA测试和验证的人力投入：约3人×3天，折算约7,200元
• 直接人力成本合计：约26,700元

这个数字本身不大。但如果你把它和“一个Jira Server年度许可费”放在一起对比，很多人可能会得出一个危险的结论：“迁移多花了不到三万块，新系统一年省十几万许可费，还是划算的。”

错。这个算法漏掉了迁移期间的业务效率折损。在那两周里，有两个Scrum团队因为权限不稳定，暂时退回了Jira操作，导致新系统里的Sprint数据不完整。还有一个项目的发布因为“测试人员看不到需求描述”的权限问题延迟了半天。这些间接损失没有精确的数字，但它们真实存在，而且比直接人力成本高一到两个量级。

迁移成本核算的正确口径是：直接人力成本 + 业务效率折损 + 用户学习适应成本 + 可能的回滚风险准备金。如果你只算了第一项，你会严重低估迁移的真实代价。

2. “兼容”这个词，要拆开了看

几乎每一家宣称“兼容Jira”的工具，指的都是数据层面的兼容，能导入Issue、能导入工作流、能导入附件。但权限逻辑的兼容，是另一个维度的命题。

原因很简单：数据模型是相对标准化的（一个Issue就是一个工作项，一个Comment就是一条记录），但权限模型是每家工具自己的架构设计，不具备跨产品的标准。就像你可以把一份Word文档导出为PDF，但你不能指望PDF的编辑权限控制逻辑和Word完全一样。

所以当销售说“我们支持Jira迁移”的时候，你要追问三句话：

1. “迁移工具能处理权限方案和角色的自动映射吗？映射率能到多少？”
2. “映射不了的规则，有没有清晰的文档说明哪些需要人工判断？”
3. “你们有没有原厂迁移服务，还是只有工具自己跑？”

以PingCode为例，它的Jira Importer虽然能自动识别用户、项目、工作项和属性的映射，但对于复杂的自定义权限场景，仍然有一部分需要导入后人工复核。这不是工具能力不够，而是任意两个权限模型之间，必然存在“语义鸿沟”，认识到这一点，你就不会对任何工具抱有不切实际的期望。

3. 简单系统保底线，复杂系统留后门

我用一个可能引发争议的观点来总结这一节：

权限配置的复杂度，和组织的真实协作复杂度是正相关的。如果你发现一个系统的权限配置“简单到不需要思考”，那它大概率是以牺牲了某些控制能力为代价的。反过来，如果一个系统能配置出极其复杂的权限矩阵，那么它的维护成本和出错概率也在同步上升。

选择哪一端，取决于你的组织治理风格：

• “规则驱动型”组织：倾向于用工具强制规则，宁可前期配置复杂一些，也要减少人为判断的空间。这类组织在迁移时可以接受较长的配置周期。
• “信任驱动型”组织：倾向于工具做基础保障，复杂控制靠流程规范和团队自律。这类组织在迁移时可以接受简化的权限模型，上线更快，但需要配套更强的文化和流程能力。

我们在迁移中选了后者，不是因为它更好，而是因为我们的真实协作状态本来就是偏信任驱动的，Jira里那些复杂的权限规则，90%的时间里并没有真正被“用到”，只是在后台“存在着”。把它们去掉，反而让权限体系重新和组织的真实运作方式对齐了。

七、迁移完成之后，才是真正的开始

1. 上线第一个月的“权限急救”

即使做了所有准备工作，上线后的第一周依然会出现大量权限问题。我们的情况是：

• 上线第一天，收到了47条权限相关的工单
• 其中32条是“我本来应该能访问X但实际不能”，权限配得太紧
• 9条是“我发现我能访问Y但我不应该能”，清理时漏掉的异常权限
• 剩下6条是“我不知道新系统怎么操作”的误报

这个阶段的关键策略是：快速响应，但不要立即修改核心规则。对于个案问题，先通过临时权限解决（比如把某个人手动加到一个空间里），等积攒到一定数量后，再判断是“个案”还是“规则有缺陷”。如果每遇到一个个案就去改全局规则，你会陷入无限的水床效应，这边按下去，那边鼓起来。

我们在第一周只做了个案处理。第二周汇总所有工单后，发现其中有3类问题属于规则缺陷，才统一修正了全局配置。这个节奏控制，避免了“改来改去始终不稳定”的陷阱。

2. 建立一个“活”的权限治理机制

迁移完成不是终点，是治理的起点。我们现在每个月做一次权限审计，审计内容很简单：

• 本月离职人员是否已回收所有权限？
• 本月转岗人员是否已更新团队归属？
• 本月新建空间是否按标准配置了权限？

这三项检查，加上HR系统和工具的账号联动（离职即自动冻结），让我们的权限管理从“应激反应”变成了“常态化运维”。在Jira时代，我们每季度才会做一次审计，而且经常因为“太忙”而跳过。现在一个月一次，每次半小时，效果反而更好。

频率提高、单次成本降低，这就是治理机制设计的核心逻辑。

3. 回头看，那两周值不值

如果现在有人问我：“从Jira换到新系统，你最庆幸自己做对了什么？”

我的答案是：我没有把权限配置当作一个“技术迁移任务”来做，而是把它当作一次“组织治理的补课”。

那两周里，我搞清楚了过去三年都没搞清楚的权限关系；我推动了HR和IT在账号管理上的流程打通；我和每条业务线的负责人就“权限的边界在哪里”达成了明确的共识；我还留下了一份可以给下一任管理员看的文档。

所以那两周不叫“配置”，叫“还债”。还的是我们长期欠下的组织治理债。

如果你正在筹划从Jira迁移到新系统，请把那两周（或更长时间）纳入你的计划。不要把它当作意外延迟，而要把它当作预期之内的、有价值的投资。投资的对象不是工具，而是你的团队未来几年高效协作的底座。

最后，我留一个具体的行动建议：

在你打开新系统的管理后台之前，先打开一个空白文档，写下三行字：

• 谁需要访问什么？（访问范围）
• 谁能做什么操作？（操作边界）
• 当规则出现模糊地带时，谁来拍板？（决策机制）

这三行字想清楚了，你会发现权限配置本身反而快得多。而那两周，真正花时间的根本不是“配置”，是“想清楚”。