1. 研发协同平台全景
在研发团队中，工具往往不是“越多越好”，而是“各司其职、彼此咬合”。Jira 与 Confluence 是 Atlassian 体系里最常被同时部署的两款产品，但它们解决的问题并不相同：Jira 关注“事情如何被推进”，Confluence 关注“知识如何被沉淀与共享”。理解两者的定位差异与互补关系，是搭建研发协同平台的第一步。
一、定位差异：一个管“流动”，一个管“沉淀”
Jira 的核心对象是工作项（Issue）。一个 Issue 可以是一个需求、一个缺陷、一个任务或一个子任务，它天然带有状态、负责人、优先级、迭代、版本等字段。Jira 的价值在于让工作项在工作流（Workflow）中流动：从“待办”到“进行中”，再到“待验证”“已完成”。每一次状态流转都对应一次责任交接，也留下可追溯的时间线。
Confluence 的核心对象是页面（Page）。页面可以承载需求背景、技术方案、接口约定、会议纪要、复盘总结、操作手册等。Confluence 的价值在于让知识以空间（Space）和页面树的方式组织起来，支持多人协作编辑、评论、版本对比和权限控制。它不推动任务流转，但为任务提供上下文和依据。
可以用一句话概括：Jira 回答“谁在什么时候把什么做完了”，Confluence 回答“为什么这样做、怎么做、做完后留下了什么”。
二、互补关系：从“需求提出”到“知识沉淀”的闭环
两者不是替代关系，而是上下游与双向引用关系。一个典型的需求生命周期中，Confluence 页面先承载需求背景与方案评审，评审通过后在 Jira 中创建对应的 Epic 或 Story；开发过程中，Jira Issue 的评论和附件记录执行细节；上线后，Confluence 页面更新为最终方案与运维说明。Jira 的 Issue 可以嵌入 Confluence 页面链接，Confluence 页面也可以嵌入 Jira 的 Issue 过滤器，形成双向可跳转的引用网络。
这种互补关系带来的直接好处是：决策有依据、执行有记录、复盘有素材。如果只有 Jira，团队会看到大量“已完成”的 Issue，却不知道当时为什么这样设计；如果只有 Confluence，文档很完整，但没人知道每个需求当前卡在谁手里、预计何时交付。
三、典型研发场景中的分工
在敏捷迭代场景中，产品经理通常在 Confluence 中编写需求说明和验收标准，评审通过后拆解为 Jira 中的 Story 并排入 Sprint。开发人员每天在 Jira 看板上拖动卡片更新状态，遇到技术难点时在 Confluence 中记录方案对比和最终选型。测试人员依据 Confluence 中的验收标准在 Jira 中创建 Bug 并关联原始 Story。迭代结束后，团队在 Confluence 中撰写回顾纪要，把改进项转化为下一迭代的 Jira 任务。
在故障处理场景中，值班人员在 Jira 中创建高优先级 Bug 并指派处理人，处理过程中的临时命令、日志片段和根因分析先记录在 Confluence 的故障页面中，事后整理为正式的事故报告。这样既保证了故障处理的时效性，又避免了知识只停留在聊天记录里。
在版本发布场景中，发布负责人用 Jira 的版本（Version）功能汇总本次发布包含的所有 Issue，确认完成状态；同时在 Confluence 中维护发布说明和回滚步骤。发布完成后，Jira 的版本报告与 Confluence 的发布记录互相印证，形成完整的交付证据链。
四、协同价值：从“工具堆叠”到“平台能力”
当 Jira 与 Confluence 被正确连接后，团队获得的不只是两个工具，而是一种可追溯的协同能力。具体体现在三个层面：
- 决策可追溯：每个需求背后的方案讨论、评审结论和变更原因都留在 Confluence 页面中，Jira Issue 通过链接直接跳转，避免“只知结果不知原因”。
- 执行可度量：Jira 的燃尽图、累积流图、版本报告提供量化数据，Confluence 中的迭代目标与回顾纪要提供定性解释，两者结合才能判断“快”是否等于“好”。
- 知识可复用：新成员加入时，通过 Confluence 页面树了解项目背景和规范，通过 Jira 看板了解当前工作节奏，上手路径清晰，减少口口相传的损耗。
需要强调的是，Jira 与 Confluence 的协同不是自动发生的。如果团队只把 Confluence 当作“网盘”存放文档，把 Jira 当作“任务清单”记录待办，两者之间没有链接、没有引用、没有共同的生命周期，那么平台价值就会退化为两个孤立工具。真正发挥协同价值的关键，是在流程设计阶段就明确：哪些信息属于“流动中的工作项”，哪些信息属于“沉淀下来的知识”，以及两者在什么节点互相引用。