我他妈讨厌 Jira（2022）

原文 ↗ Hacker News 讨论 ↗

Jira 是 Atlassian 无处不在的问题和项目跟踪器，却因缓慢、过度可配置、并且很容易被管理层武器化为充满必填字段、复杂工作流和 KPI 表演的迷宫而遭到强烈批评。许多工程师认为，人们真正讨厌的是 Jira 与糟糕组织文化的组合；而另一些人则坚持认为，与 GitHub/GitLab issues、Phabricator/Phorge、Linear 或内部系统等更简单的工具相比，这个产品的设计本身就会主动鼓励复杂性和不良实践。少数人报告了正面体验：当 Jira 被严格治理、保持简单，并主要作为轻量级 Kanban 或缺陷跟踪器使用时，它表现不错，这也凸显了它的影响在很大程度上取决于它如何——以及由谁——来配置。

对 Jira 的总体情绪

  • 许多评论者表达了强烈的厌恶；有些人称它是他们使用的最糟糕工具。
  • 少数人表示喜欢 Jira，或者至少在简单使用时觉得它“还行”。
  • 也有人认为，这些抱怨往往把 Jira 与对公司官僚主义和大型组织的更广泛不满混为一谈。

工具 vs. 配置 vs. 文化

  • 一个强烈的主题是：“真正”的问题在于组织如何配置和强制使用 Jira，而不是软件本身。
  • 过度配置的实例（大量自定义字段、复杂工作流、多块看板）会造成混乱和摩擦。
  • 另一些人反驳说，如果大多数组织都会把一个工具配坏，那这说明的是工具设计糟糕，而不只是用户不好。
  • Jira 被描述为一个“工具箱”或“瑞士军刀”：功能强大，但如果没有治理和一个称职的管理员，就像一把巨大的误伤武器。

UX、性能和技术问题

  • 常见抱怨包括缓慢、CPU 占用高，以及别扭的拖放行为，尤其是在 Cloud 上。
  • 搜索功能被广泛批评为很差，常常连按精确标题都找不到问题。
  • 有些人提到奇怪的分页决策（例如先加载最旧的评论）以及会抢走焦点的 UI 小毛病。
  • 据说自托管 / Data Center 版本比 Cloud 更快，也更稳定。

Jira、敏捷与流程

  • Jira 往往与一些不受欢迎的做法捆绑在一起：Scrum 仪式、故事点、计划扑克，以及 KPI 驱动的管理。
  • 有人说 Jira + Scrum “令人窒息”，而 Jira + Kanban 还能接受；也有人认为无论流程如何，Jira 都不好用。
  • 还有几位认为 Jira 鼓励过度关注工单和指标，而不是实际的工程实践和沟通。

对比与替代品

  • 受到称赞或更受偏爱的工具包括 Linear、Pivotal Tracker、Shortcut/Clubhouse、Phabricator/Phorge、GitHub/GitLab issues、OpenProject、Smartsheet，以及简单的电子表格或仓库里的 Markdown。
  • 一些工具（Rally、Azure DevOps、IBM CCM、某些 Microsoft 产品）被描述得更糟，以至于让 Jira 相比之下显得不错。
  • 更简单的跟踪器据说“更能扩展”，因为它们避免了 Jira 的复杂性和臃肿。

Confluence 和更广泛的 Atlassian 生态

  • Confluence 经常被嘲讽为“文档去死的地方”；搜索同样是主要抱怨之一。
  • 也有人为 Confluence 辩护，认为与散落在 Word/Excel/SharePoint 中的文档相比，它是“最不坏”的文档工具。
  • 有些人很欣赏 Jira、Confluence 和 Git 托管之间的强集成，尤其是在以最小化且一致的方式使用时。

治理、规模化与管理负担

  • 更大的组织通常需要一个治理委员会，甚至需要全职 Jira 管理员，来防止字段和工作流失控膨胀。
  • 如果没有这些，实例会积累重复/未使用的字段以及不一致的工作流，尤其是在单一的全球部署中。
  • 管理端的复杂性也受到批评：找到正确设置往往需要向 Atlassian 提交支持工单。

更广泛的反思

  • 一些人认为 Jira 是为高层管理的汇报和 KPI 优化的，而不是为开发者的易用性优化的。
  • 也有人讨论，跟踪工作是否应该更多地放在 Git 里（提交、发布说明、CI），而不是 Jira 工单中。
  • 还有人主张，对足够大的公司来说，应该使用内部开发、严格定制的工具，而不是通用的企业平台。