2. Jira项目空间设计

在跨团队需求与版本管理工程中，Jira项目空间设计不是“建几个项目”这么简单，而是决定需求如何被提出、如何被拆解、如何被追踪、如何被发布的基础设施。很多团队在初期只建一个“大项目”，所有团队的需求、任务、缺陷都堆在一起，结果导致看板混乱、权限失控、版本无法对齐。要解决这个问题，核心思路是：用公司管理项目承载跨团队需求与版本，用团队管理项目承载各团队内部执行，两者通过问题链接和版本映射形成组合模式。

一、两种项目类型的职责边界

Jira中的“公司管理项目”通常指由项目管理员统一维护、面向多个团队或整个产品线开放的项目。它的特点是：工作流相对统一、权限方案集中管理、版本字段由发布经理控制、需求来源广泛。它适合承载跨团队需求池、产品路线图、版本发布计划。而“团队管理项目”由各团队自行维护，工作流可以按团队习惯定制，权限更封闭，适合承载团队内部任务、子任务、技术改进、缺陷修复。两者不是替代关系，而是上下游关系：公司管理项目中的需求经过评审后，拆解为团队管理项目中的执行任务，执行完成后通过链接回写状态。

二、项目角色与权限方案配置

跨团队场景下，权限设计要遵循“最小可见、按需编辑”的原则。公司管理项目建议设置以下角色：项目管理员负责项目配置、工作流和权限方案维护；发布经理负责版本创建、发布范围确认和版本关闭；产品负责人负责需求录入、优先级排序和验收；跨团队干系人拥有只读权限，可查看路线图和版本进度。团队管理项目中，团队负责人拥有项目配置权限，团队成员可创建、编辑、流转任务，其他团队默认只读或不可见。

权限方案建议使用Jira的“权限方案”功能集中管理，而不是在每个项目中单独配置。例如创建一个名为“跨团队标准权限方案”的权限方案，分配给公司管理项目和所有团队管理项目，再通过项目角色绑定具体人员。这样当人员变动时，只需调整角色成员，无需逐个项目修改。以下是一个可参考的权限方案配置示例：

权限方案名称：跨团队标准权限方案
适用项目：PROD-ROADMAP、TEAM-ALPHA、TEAM-BETA

项目角色与权限映射：
- Administrators（项目管理员）：
    管理项目、管理权限方案、管理工作流、删除问题
- Release Managers（发布经理）：
    创建版本、编辑版本、发布版本、归档版本
- Product Owners（产品负责人）：
    创建问题、编辑问题、分配问题、管理版本范围
- Team Leads（团队负责人）：
    管理Sprint、编辑团队看板、分配任务、关闭子任务
- Team Members（团队成员）：
    创建子任务、编辑自己创建的问题、流转任务状态、记录工时
- Stakeholders（跨团队干系人）：
    浏览项目、查看问题、查看版本、添加评论（不可编辑字段）

问题安全级别：
- 公司管理项目：默认“内部公开”，敏感需求设为“产品负责人及以上”
- 团队管理项目：默认“团队可见”，跨团队干系人仅可查看已链接需求

三、项目分类与命名规范

当组织中有多个产品线、多个团队时，项目分类和命名规范直接影响查找效率和权限继承。建议按“业务域 + 项目类型 + 团队标识”三层结构分类。例如：业务域分为“交易域”“用户域”“基础平台”；项目类型分为“公司管理项目”和“团队管理项目”；团队标识用短代码表示。项目Key建议采用“业务域缩写-类型缩写-团队代码”的格式，如TRD-ROADMAP表示交易域路线图项目，TRD-ALPHA表示交易域Alpha团队项目。这样在Jira项目列表中可以通过Key前缀快速筛选，也便于后续用JQL批量查询。

四、多团队项目空间搭建任务

假设某产品线包含Alpha和Beta两个团队，共同交付V2.3.0版本。搭建任务可以按以下顺序执行：

1. 创建公司管理项目：选择“公司管理项目”模板，Key设为PROD-ROADMAP，项目负责人设为产品负责人。配置问题类型为“需求”“史诗”“版本发布”，工作流采用“待评审 → 已确认 → 开发中 → 待发布 → 已发布”。
2. 创建团队管理项目：分别为Alpha和Beta创建“团队管理项目”，Key设为TEAM-ALPHA和TEAM-BETA。问题类型保留“任务”“子任务”“缺陷”，工作流按团队习惯配置，例如Alpha采用“待办 → 进行中 → 待测试 → 完成”。
3. 配置权限方案：创建“跨团队标准权限方案”，按上述角色映射分配权限，并将该方案关联到三个项目。
4. 建立版本映射：在公司管理项目中创建版本V2.3.0，在Alpha项目中创建Alpha-S8，在Beta项目中创建Beta-S5。通过版本描述字段记录映射关系，例如“Alpha-S8 对应 V2.3.0 的交易模块”。
5. 验证链接与状态回写：在公司管理项目中创建一条需求PROD-ROADMAP-101，拆解为TEAM-ALPHA-45和TEAM-BETA-32，使用“实现”链接类型关联。当团队任务完成后，通过自动化规则将状态回写到需求，触发需求进入“待发布”。

五、常见配置陷阱

在实际搭建中，最容易出现三类问题。第一，权限方案未统一：每个团队单独配置权限，导致人员变动时遗漏某个项目，出现“该看到的人看不到、不该改的人能改”。第二，版本字段混用：公司管理项目用“Fix Version”表示计划版本，团队项目也用“Fix Version”表示Sprint，导致版本报表无法对齐。建议团队项目用“Sprint”字段管理迭代，用“Fix Version”只记录实际发布版本。第三，链接类型不规范：有人用“关联”，有人用“阻塞”，有人用“实现”，导致追溯关系混乱。建议在项目配置中统一链接类型，并在团队规范中明确：需求拆解用“实现”，依赖关系用“阻塞”，参考关系用“关联”。

完成以上配置后，一个可运行的多团队项目空间就搭建好了。它的核心价值在于：公司管理项目提供跨团队的统一视图和版本控制，团队管理项目保留各团队的执行灵活性，权限方案和版本映射把两者粘合在一起，使需求从提出到发布的全过程可追溯、可度量、可审计。