2. Cloud产品矩阵与选型决策

Atlassian Cloud 并不是“把 Server 版搬到云上”这么简单。它是一组围绕团队协作、工作管理、服务交付三条主线重新设计的产品组合。对准备迁移的企业来说，真正需要回答的问题不是“哪个产品功能最强”，而是“哪一组产品组合，能以可接受的成本，覆盖我们当前和未来两年的协作与交付场景”。本节围绕 Jira Cloud、Confluence Cloud、Jira Service Management Cloud（JSM Cloud）三个核心产品，拆解功能差异、定价模型与适用场景，并给出一份可直接填写使用的企业产品选型矩阵。

一、三个核心产品的定位差异

Jira Cloud 是工作项与项目执行的主干。它管理的是“有状态、有负责人、有流转”的工作：需求、任务、缺陷、迭代、发布。它的核心能力是工作项类型、工作流、看板/Scrum 板、版本与史诗层级、JQL 查询和自动化规则。Jira Cloud 的定价按“用户数 × 版本档位”计费，分为 Free（10 用户以内）、Standard、Premium、Enterprise 四档。关键分水岭在 Premium：从这一档开始提供 Advanced Roadmaps（跨项目规划）、沙箱环境、审计日志、99.9% SLA；Enterprise 再叠加多实例组织、数据驻留、Atlassian Guard 等治理能力。

Confluence Cloud 是知识沉淀与协作空间。它管理的是“内容、页面、空间、权限”以及围绕内容的评论与协作。核心能力包括空间与页面树、模板、宏、白板、数据库视图、页面版本历史与协作编辑。定价同样按用户数分档，但它的价值密度与 Jira 不同：Confluence 的用户往往远多于 Jira，因为阅读者、非研发职能也会进入。因此 Confluence 的选型重点不是“功能够不够”，而是“要不要为全员购买付费席位，还是用访客（Guest）与公开链接控制成本”。Premium 档提供分析、审计日志、沙箱；Enterprise 提供数据驻留与集中治理。

Jira Service Management Cloud 是服务请求与 IT 服务管理（ITSM）平台。它管理的是“请求、事件、变更、问题、资产”这类服务交付对象。核心能力包括请求类型与门户、SLA 计时、队列与值班（On-call）、事件管理、变更日历、资产与配置管理（Assets/CMDB）、知识库联动。JSM 的定价模型与 Jira 有本质区别：它按“代理（Agent）”计费，而不是按所有用户计费。也就是说，提交请求的员工（客户/请求者）是免费的，只有实际处理请求的服务台人员才需要付费席位。这一点对成本结构影响极大——一个 5000 人的企业，可能只需要 30 个 JSM Agent 席位。

二、定价模型背后的成本逻辑

三个产品的计费口径差异，直接决定了企业选型的成本结构。Jira 和 Confluence 按“所有需要登录的用户”计费，JSM 按“处理请求的 Agent”计费。这意味着：

• Jira 的成本随研发与项目人员规模线性增长。如果企业有 800 名研发和项目经理，Jira 就是 800 个席位。此时 Premium 与 Standard 的差价，需要与 Advanced Roadmaps、沙箱、审计日志带来的治理收益做权衡。
• Confluence 的成本取决于“谁需要编辑”。如果大量员工只是阅读制度文档，应优先评估 Guest 访客机制或公开链接，而不是给全员购买付费席位。Guest 通常不计入付费席位，但权限与空间管理需要提前设计。
• JSM 的成本取决于“谁在服务台值班”。一个 5000 人的企业，可能只有 30 名 IT 服务台人员需要 Agent 席位，其余 4970 人作为请求者免费提交工单。这是 JSM 在成本上最容易被低估的优势。

需要特别提醒：JSM 的 Agent 席位与 Jira 的席位是分开计算的。如果同一名工程师既在 Jira 中做研发，又在 JSM 中处理事件，他需要同时拥有 Jira 席位和 JSM Agent 席位。选型时必须把这类“重叠人员”单独列出，否则预算会明显偏低。

三、版本档位的治理能力分界

三个产品都采用 Free / Standard / Premium / Enterprise 四档结构，但每一档的治理能力并不完全相同。对企业迁移而言，真正需要关注的是 Premium 和 Enterprise 两档，因为治理、审计、数据驻留、沙箱这些能力几乎都集中在这两档。

如果企业有等保、数据出境或行业合规要求，数据驻留和审计日志往往是硬性门槛，这意味着至少需要 Premium，部分场景直接锁定 Enterprise。反之，如果只是小团队试点，Standard 甚至 Free 就足够，不必为治理能力提前付费。

四、企业产品选型矩阵

下面给出一份可直接填写使用的选型矩阵。它的逻辑是：先按“团队类型”确定主产品，再按“治理要求”确定版本档位，最后按“人员角色”确定席位数量。矩阵中的示例数据为合理假设，用于说明填写方式，企业应根据自身实际情况替换。

产品选型矩阵（示例）

| 团队/场景        | 主产品      | 版本档位  | 席位口径           | 示例数量 | 关键判断依据               |
|------------------|-------------|-----------|--------------------|----------|----------------------------|
| 研发交付团队     | Jira Cloud  | Premium   | 研发+项目经理      | 320      | 需要 Advanced Roadmaps     |
| 产品与设计协作   | Confluence  | Standard  | 编辑者             | 180      | 阅读者走 Guest             |
| IT 服务台        | JSM Cloud   | Premium   | Agent              | 30       | 需要多队列 SLA 与值班      |
| HR 共享服务      | JSM Cloud   | Standard  | Agent              | 12       | 请求者免费，流程较简单     |
| 全员知识阅读     | Confluence  | Free/Guest| 访客               | 4200     | 只读，不占付费席位         |
| 高管项目组合视图 | Jira Cloud  | Premium   | 高管用户           | 25       | 只读 Advanced Roadmaps     |

重叠人员检查：
- 既在 Jira 又在 JSM 的工程师：18 人 → 需同时购买两类席位
- 既在 Confluence 又在 Jira 的编辑者：150 人 → 分别计入各自席位

填写这份矩阵时，最容易出错的地方是“重叠人员”和“只读用户”。建议先把所有人员按角色拆成三类：编辑/处理者（必须付费）、请求者/阅读者（尽量免费）、跨产品重叠者（需要重复计费）。把这三类人数算清楚，再套用版本档位，预算就不会出现大的偏差。

五、选型决策的常见误区

第一个误区是“先买最高档，反正以后用得上”。Premium 和 Enterprise 的单价明显高于 Standard，如果企业当前没有审计、沙箱、数据驻留的硬性要求，提前购买会造成持续浪费。更稳妥的做法是先用 Standard 跑通迁移，等治理需求明确后再升级——Atlassian Cloud 支持档位升级，且通常按剩余周期折算。

第二个误区是“JSM 可以替代 Jira”。两者管理对象不同：Jira 管工作项，JSM 管服务请求。研发迭代用 Jira，IT 工单用 JSM，二者通过关联和自动化打通，而不是互相替代。把研发任务塞进 JSM，会失去敏捷板、版本、史诗等能力；把服务请求塞进 Jira，会失去 SLA、门户、值班等能力。

第三个误区是“Confluence 所有人都要付费”。实际上，大量阅读型用户可以通过 Guest、公开链接或仅查看权限来控制成本。关键是在迁移前就设计好空间权限模型，而不是迁移后再逐个调整。