jira工作台自定义，每人一套导致混乱

一、混乱的源头不在Jira，而在“全员管理员思维”

不是Jira变难用了，是我们把一套本应“先设计、再使用”的项目管理骨架，活生生用成了“谁都能往上面挂东西”的自由涂鸦板。

我最早意识到这个问题的严重性，是在一次跨项目复盘会上。两个并行Scrum团队的Scrum Master在投影仪上分别打开自己的Jira看板，一个用“待办/开发中/测试中/完成”，另一个用“Backlog/In Progress/Code Review/Ready for QA/UAT/Closed”。表面上只是状态列不同，但当天晚上我和他们细聊后才发现：同样的“In Progress”，A团队意味着“开发已认领”，B团队却意味着“代码正在写且已关联分支”。而“既然状态都不同，那我们在燃尽图里统计的‘进行中工作量’根本就不是一个东西”，这句话，是其中一个Scrum Master的真实原话。

我做研发管理咨询这些年，碰到过上百例类似的场景。而令我意外的是，几乎所有陷入“Jira越用越乱”的团队，都没有意识到一个反常识事实：混乱的根源，极少来自工具能力不足，而是管理者在第一时间开放了过多不必要的自定义权限。我们太习惯用“给所有人自由”来表达信任，却忽略了项目管理工具首先是组织流程的强制映射，其次才是个人的效率看板。

为什么会这样？因为Jira的设计逻辑本身就是“给你最好的零件，但你必须自己画图纸”。它的字段配置方案、界面方案、工作流方案、权限方案，彼此之间是可以任意组合的：同一个项目，A看板绑一个工作流方案、B看板绑另一个工作流方案，底层再共享同一个权限方案，这种组合能力强大到连Atlassian自己都不得不推出“Advanced Roadmaps”来画清楚关系。但当团队规模超过30人，且各小组都有人掌握“修改工作流”的权限时，你面对的就不再是一套Jira，而是三四套语义不同、逻辑互斥、数据无法合并的独立小型项目管理工具。

我见过最极端的案例：一家70人规模的SaaS公司，用了三年Jira后，全公司共有43个不同的工作流方案，其中“开发中”这个状态在不同工作流中出现了11种名称，“In Dev”“Development”“Coding”“Dev In Progress”“Developing”“研发中”“研发进行中”“开发-进行”“Code”“写代码中”“Dev-Doing”。当CTO要求拉出“当前全公司研发进度”时，Jira管理员花了整整2天时间写JQL合并规则，最后的报表仍然因为状态间的流转逻辑不一致而无法自洽。

这不是工具的Bug，这是管理的系统Bug。

二、我在PingCode做Jira迁移评估时看到的真实差距

2024年下半年，我以外部顾问身份参与了三个从Jira迁移到PingCode的评估项目。客户分别是120人的金融科技团队、200人的硬件研发团队、以及一家350人规模的AI公司。他们最初找到我的理由几乎一模一样：Jira用着用着，管理层不再能看懂底下的项目进度了。

但我要先澄清一个容易被误会的点：这种混乱不是因为PingCode一定比Jira“强”，而是因为两者的默认管控哲学完全相反。Jira默认给你一盒乐高零件，让你自己搭；PingCode默认给你一排已经装好的房间，你可以调整家具但不能拆承重墙。

以工作流管理这个最容易暴露出混乱的模块为例，我对比了它们在真实使用场景下的管控路径：

做完这组对比后，那家金融科技客户的项目总监说了句让我记到现在的话：“如果Jira是一套操作系统，我们现在需要的是一个把所有系统调用都封装好的容器。我们没时间，也没精力再去教一个新入职的高级工程师‘为什么你这个项目里的Ready for QA在隔壁项目里叫待测试’。”

这其实揭示了一个更深层的管理问题：当组织超过100人以后，你需要的不是更强的自定义能力，而是更强的管控能力。你需要的不是让每个人都能创建自己的完美工作台，而是让所有人站在同一套信息底盘上，再在这个基础上做适度的个人效率调整。

三、为什么“每人一套自定义工作台”在小团队看起来是效率，在大团队一定是灾难

1. 超过40人后，沟通成本开始吞噬自定义收益

很多人反驳我说：“自定义工作台可以让我只看到我关心的任务，这是我的效率工具。”我完全同意，在团队规模不超过30人、且项目不超过3个并行时，这种效率是真实存在的。我自己在带一个12人的Scrum团队时，也会让每个人保存三五个高度个人化的筛选器。

但问题发生在组织扩张的那一刻。当团队突破40人，并行项目超过5个，且开始出现“开发A同时参与项目1和项目3，测试B被项目2和项目4共享”这种矩阵式协作时，每多一套自定义工作台，就相当于在组织内部多创造了一门只有自己听得懂的方言。

我用一个真实的沟通成本模型来说明这一点。假设一次跨项目同步需要涉及3个角色：前端、后端、测试，每个人都在自己的Jira上保存了不同的问题筛选条件、不同的列显示字段和不同的看板泳道配置。当项目经理说“我们过一下当前所有待测试的需求”，会发生什么？

前端打开自己的过滤器，显示35个问题；后端打开自己的过滤器，显示28个问题（他把“自测中的”也筛掉了）；测试打开自己的过滤器，显示41个问题（她把“被阻塞的”也算进去了）。在接下来的15分钟内，这三个人不是在讨论需求本身，而是在讨论“你的过滤器是什么条件”“为什么我的比你多了7个”“你那个‘待测试’是哪个状态的？”，这就是沟通税。而沟通税的税率，会随着团队规模呈指数级增长。

2. 工作流节点数量的失控

“每个人都可以加一个自己觉得需要的状态”，这是我见过的最危险的管理行为之一。

工作流中的每一个状态节点，本质上是一个承诺交互点，而不是一个描述标签。它意味着“当issue进入这个状态时，一定有一个角色做了某个明确动作，并且当前负责人有责任把它移出这个状态”。但在失控的自定义环境下，很多团队增加状态节点时完全不过脑子：觉得某个状态“好像存在”、觉得“我们和别的团队不同”、更有甚者只是为了“看板好看”。

那家拥有43个工作流方案的SaaS公司里，我统计发现其中19个工作流里包含了一个叫“待确认”的状态。这个状态在前端团队的工作流里意味着“UI稿还没给出”，在后端团队的工作流里意味着“接口定义未对齐”，在测试团队的工作流里又意味着“这个Bug复现不了”。这个词在公司内部被用了三年，没有任何人、任何文档界定过它的确切含义，当一个状态名所有人都在用却没人能给出统一定义时，它就不是一个管理节点，而是一个垃圾桶。

在PingCode的实际配置中，我亲眼见过他们的实施顾问要求客户在工作流设计阶段先回答三个问题：

1. 这个节点是谁负责把issue放进去的？
2. 从放进来到移出去，是否有且仅有一个明确的角色负责？
3. 如果未来要度量“在这个节点上平均停留多久”，这个时长数据是否对管理有解释力？

如果三个问题里有一个回答是模糊的，PingCode的实施顾问会直接建议这个节点不要创建，或把它归并到上游或下游节点中。这套前置判断机制，看起来是在限制自由，实质上是在保护流程的语义纯度。

3. 字段填写的“巴洛克化”

和状态节点失控并发的，是字段的无限增长。我统计过前文提到的那家SaaS公司：在所有项目的所有issue类型中，一共出现了127个自定义字段。其中33个字段在全公司仅被一个项目使用，21个字段从未出现在任何筛选器或报表中，还有一个叫“开发预估复杂度”的字段，在创建两年后，该字段下有值的issue仅占全部issue的11%。

这背后的心理机制很简单：当一个人拥有“新增字段”的权限，且不需要为字段的长期维护成本买单时，他就会在任何不确定的时刻选择“先加上再说”。

这种行为的后果是累积性的。一个新人打开一个需求工单，从上往下滚动要经过三个屏幕，优先级、模块、标签、版本、客户、迭代、关联需求、关联缺陷、原始需求链接、需求来源、需求评审人、评审日期……在这堆信息里，他真正需要看的只是标题、描述、验收标准和当前状态。剩下的十几个字段，不仅没有提供额外价值，反而显著增加了他的认知负荷。

在我协助一家150人团队从Jira迁移到PingCode的过程中，我们在字段梳理阶段做了一个大胆的决定：将原来Jira中的91个自定义字段砍到34个。砍的原则是：

1. 过去6个月内，有值的issue占比低于30%的字段直接删除；
2. 只被一个项目使用、且该项目负责人无法清晰解释其管理价值的字段删除；
3. 信息与其他字段严重重叠的字段合并或移除。

这个动作带来一个立竿见影的效果：需求创建页面的平均填写时间从4分12秒降到了1分38秒。没有人抱怨字段不够用了，因为被砍掉的那些字段，从来也没有被真正“用”过。

四、两种解决思路：用Jira自己治自己，还是换一套管控底座

每次咨询到这里，客户会问我的下一个问题通常是：“这些混乱，我能不能不改工具，只在Jira内部做纪律整顿？”

我的回答分两层。第一层：能，但需要的不是技术操作，而是管理层级的系统性纪律，且一旦开始，就不能松动。 第二层：如果你的组织持续在扩张，你的业务不允许管理精力被工具的“治理”占用，那考虑一个管控内置的工具就是更理性的选择。

1. 在Jira内自救：代价是管理意志

如果决定继续留在Jira，我通常会建议执行一套“收权，统一，冻结”的三步改装方案：

第一步：收回工作流创建权限。

• 除指定的Jira管理员外，任何人不得拥有“编辑工作流方案”或“创建新工作流”的权限。
• 现有的所有工作流方案全部导出，逐份审查；语义相近的状态节点强制合并为唯一命名。
• 建立一个全公司唯一的“状态词典”，每个状态名对应唯一的语义定义文档，并在Confluence或Wiki中公开。

第二步：统一字段配置方案和界面方案。

• 和业务负责人一起逐字段讨论：这个字段谁填、谁看、用来做什么决策、是否在报表中出现。
• 不能回答上面任意一个问题的字段，一律在下个迭代中移除。
• 所有项目使用同一套企业级界面方案模板，各项目只能在此基础上做“隐藏非必要字段”级别的微调，不得新增。

第三步：冻结全局配置，建立变更评审机制。

• 任何影响超过一个项目的工作流、字段、界面变更，必须走正式的变更申请流程。
• 变更申请需包含：变更原因、影响范围、迁移计划、回滚方案。
• 每季度一次全局配置评审，评审会上现场投票决定是否将某些团队级的字段或状态提升为全局级。

这套方案我陪两家公司跑过完整周期，从启动到全公司切换完成，通常需要4-6周。在这个过程中，最大的阻力既不是技术上的，也不是Jira本身的限制，而是来自于那些已经习惯了“自己建自己用”的项目负责人。当被告知不能再随意新增状态时，最常听到的反弹是：“我们的项目很特殊，必须要这个状态。”，而当我追问三次“这个状态对应的管理动作是什么”之后，超过80%的所谓“特殊状态”都被证明是冗余的。

2. 换到PingCode：代价是迁移，收益是原生管控

我从不声称“换个工具就能解决一切管理问题”，这太蠢了。但我必须客观记录一个事实：在我参与过的从Jira迁移到PingCode的项目中，迁移完成后最先减少的不是技术债，而是“沟通债”。

那句话可能是这么理解的：当一个团队不再需要花15分钟对齐“你的待测试和我的待测试是不是同一个东西”，他们多出来的时间是直接加到生产力上的。这个效果不需要任何数据分析来证明，任何一个管理者在迁移后第一周就能感受到。

PingCode在100人以上组织里的管控思路，可以总结为三个核心决策：

决策一：语义先行，字典锁定。

• PingCode中的“工作项类型”和“状态”均由全局字典管控。团队级别的项目管理员可以决定“我这个项目用字典中的哪几个状态”，但不能在字典之外创建。
• 这意味着只要这个词在PingCode的某个地方被使用了，它的语义在全公司就是唯一的。大半个跨项目沟通的混乱，在这个层面就被截断了。

决策二：功能原生集成，不需插件拼凑。

• 项目管理、代码关联、测试管理、知识管理、效能度量，这五个模块在PingCode内是一个数据库、一套权限体系、一个数据字典。
• 对比Jira而言，它需要连接Confluence、对接Zephyr、挂载EazyBI再加Bitbucket才能拼出同等能力，每一层插件的背后都可能引入额外的字段、权限和配置，进而增加混乱风险。
• 这不是“PingCode功能比Jira多”，而是PingCode的设计减少了组装过程中的管控缝隙。

决策三：对100人以上组织做迁移时有完整的数据清洗能力。

• 在迁移评估阶段，PingCode的实施团队会先对源Jira做一次全量导出，然后用自定义脚本扫描：哪些状态在不同工作流中语义重复、哪些字段空置率过高、哪些权限过度分配。
• 在迁移完成前，所有这些脏数据都会被清洗成一版干净的结构化数据。换句话说，迁移过程本身就是一次强制的、全面的Jira治理。

我为什么特意拉出“一年后字段膨胀率”这个指标？因为有一件事是Jira自救方案很难彻底堵住的：人的惯性。在Jira里，哪怕你把工作流创建权全收了，只要团队还保留着“添加自定义字段”的权限，一年以后字段数量会再次往上涨，因为每个新来的项目经理都会觉得“我的项目和之前的都不一样”。而在PingCode，由于字段也是全局字典控制，这种膨胀自然会被迫停在源头。

五、管理者应该做什么：一个可执行的行动路线

好。现在假设你是一个带领60人以上研发团队的VP、CTO或技术总监，你在看完前面所有内容后可能会问我：“说人话，我明天该做什么？”

我建议你按以下顺序行动：

1. 做一次Jira现状扫描（不需要技术背景）

不需要你亲自上Jira点按钮，但需要你让Jira管理员为你拉出四份数据：

1. 全公司当前有多少套激活的工作流方案（然后问：为什么？）；
2. 列出所有状态节点的名称，把语义相近的标同一颜色（你会看到一片彩虹）；
3. 自定义字段总数及每个字段的使用率（使用率=有值的issue/issue总量）；
4. 拥有“项目管理员”权限的用户数量。

这四组数字你甚至不需要会写JQL。就只看这四组数的绝对值，如果第二个数字让你产生了“这上面一堆词难道不是同一个意思吗”的疑问，那恭喜，你已经亲自证明了混乱的存在。

2. 判断你属于哪一类问题

根据我的经验，这类混乱通常可以归为三类，每一类对应不同的解决重点：

3. 无论选哪条路，先把这四件事做掉

在决定到底是“Jira内部自救”还是“迁移PingCode”之前的评估期，有几件事我建议你本周就开始做，而且它们对所有路径都成立：

（1）立即收敛权限。

• 将所有项目的“管理工作流”“管理字段配置”权限集中到不超过两个人手中。
• 这个动作你不需要等任何评估结果，它本身就正确。

（2）冻结新增状态节点。

• 用邮件或内部公告正式通知：即日起，除非经过Jira管理委员会评审通过，任何人不得新增工作流状态。
• 这一条的执行力，将直接测试出你的管理团队是否真正认同“统一管控”这件事。

（3）清理空置字段。

• 拉出全公司自定义字段列表，标记出使用率低于20%的字段，和业务负责人一个一个确认是否可删除。
• 删一个无用的字段，比增加任何新功能都更能提升工具的可用性。

（4）统一全公司的“唯一真相看板”。

• 在每个项目中，强制要求存在一个由管理员维护的、只读的、配置统一的“全项目视图看板”。
• 这个看板用全公司相同的列、相同的泳道、相同的卡片字段，任何人在任何项目里打开它看到的都是同一个信息结构。
• 团队成员个人的工作台可以保留，但它们只是“个人效率层”，而“全项目视图”是信息对齐的底线。

六、总结：自由和秩序，从来不是一个开关，而是一个刻度

说一句可能会得罪人的话：Jira的“强大自定义能力”，在相当多数的企业里，被当成了一块遮盖管理惰性的遮羞布。 “反正你们需要什么就自己加”，这句话的背后，往往意味着管理者放弃了为团队界定“工作长什么样”的责任。

我见过真正把Jira用得井井有条的团队，他们的共同点不是“技术能力强”，而是“管理者有极强的秩序意识”。他们的Jira管理员不是被扔在角落里默默配置的运维角色，而是深度参与项目流程设计、有权在会议上说“这个状态不能加”的人。

我也见过成千上万用Jira用得痛苦不堪的团队。他们痛苦的根源，从来不是工具贵、界面丑或者响应慢。他们痛苦的是：花了巨大的成本部署了一套管理系统，最终却因为没有人在一开始说“这个不能乱动”，而把系统变成了一个谁都不愿意认真看的数字坟场。

如果你正在经历同样的混乱，我的建议很简单：

1. 先用本文第五部分的那四组数据扫描你自己的Jira。看到那堆数字以后，你的判断会比任何顾问都更准。
2. 如果数字还在可控范围，立即启动内部治理，不要等。
3. 如果数字已经大到让你觉得“要治不知道从哪里下手”，那就考虑是否借助一次工具迁移，完成你早就该做的流程清理。
4. 不管选哪条路，第一条行动项永远是：把权限收回来。

项目管理工具从来不该是让每个人拥有自己王国的权力令牌。它应该是一面镜子，让团队在同一个视角下看清同一件事，然后用一致的语言、一致的节奏去完成它。至于这份秩序是你的Jira管理员一个字一个字抠出来的，还是一个像PingCode这样原生管控的工具帮你守住的，这不重要。重要的是，明天早上晨会的时候，你们打开同一个看板，看到的是同一组数字，讨论的是同一个现实。