4. 跨团队需求字段方案

跨团队需求管理最容易失控的地方，不是流程本身，而是字段。每个团队都按自己的习惯建字段，A 团队用“需求来源”，B 团队用“来源渠道”，C 团队干脆把来源写在描述里；业务价值有的填数字，有的填“高/中/低”，有的留空。等到需要跨团队汇总、排序、做版本决策时，数据无法对齐，Jira 里的信息就退化成“能看不能算”。本节要解决的核心问题，是把需求信息结构化：哪些字段必须全局统一，哪些字段允许项目级自治，以及如何用字段配置把团队标识、需求来源、业务价值、验收标准这些关键信息固定下来。

一、先分清全局字段与项目级字段

Jira 的字段本质上分为两类：系统字段和自定义字段。系统字段如“摘要”“描述”“经办人”“优先级”“截止日期”由 Jira 内置，跨项目天然一致；自定义字段则需要我们规划。规划的第一原则是：凡是需要跨团队比较、汇总、筛选、排序的信息，必须做成全局自定义字段；凡是只服务单个团队内部工作习惯的信息，尽量留在项目级或干脆不建。

全局字段通过字段配置方案（Field Configuration Scheme）和字段配置（Field Configuration）控制“是否显示、是否必填、是否可编辑”。一个字段可以出现在多个项目的界面里，但不同项目可以设置不同的必填与可选状态。项目级字段则通常通过项目自己的界面方案（Screen Scheme）和字段配置来隔离，避免污染其他团队。

判断一个字段该不该全局化，可以用三个问题快速决策：第一，它是否参与跨团队报表或版本排序？第二，它是否会被两个以上团队同时使用？第三，它的取值是否需要统一枚举？三个问题中任意两个为“是”，就应做成全局字段。

二、关键字段设计：团队标识、需求来源、业务价值、验收标准

下面给出四个核心字段的推荐设计。字段类型和取值需要结合 Jira 实际能力选择，示例中的选项值属于合理假设，可根据组织实际情况调整。

团队标识建议拆成“提出团队”和“承接团队”两个字段，而不是一个“团队”字段。跨团队需求的关键矛盾往往发生在提出方与承接方之间，拆开后可以分别筛选“我们提出的需求”和“我们承接的需求”，在版本规划时能快速看清负载分布。

需求来源必须用统一枚举，不能自由填写。推荐值包括客户反馈、内部工单、战略规划、合规要求、技术债。统一枚举后，可以统计“本版本有多少需求来自合规要求”，这对审计和优先级判断非常关键。

业务价值建议用数字字段而非“高/中/低”。数字可以排序、可以加权计算，也便于和成本字段一起做优先级模型。如果组织使用 WSJF（加权最短作业优先），可以进一步拆成“用户业务价值”“时间紧迫性”“风险降低/机会开启”“工作量”四个数字字段，用公式计算优先级。示例：某需求用户业务价值 8、时间紧迫性 5、风险降低 3、工作量 4，则 WSJF = (8+5+3)/4 = 4.0，数值越高越优先。

验收标准建议用多行文本，并在团队规范中约定格式。推荐 Given/When/Then 结构，例如：“Given 用户已登录且购物车非空，When 点击结算，Then 生成订单并跳转支付页”。验收标准必填，可以显著减少“需求描述模糊、开发反复确认”的沟通成本。

三、字段配置如何落地

规划完字段后，需要在 Jira 管理后台完成配置。典型操作路径如下（以 Jira Data Center/Server 为例，Cloud 版菜单名称略有差异）：

1. 进入“管理” → “问题” → “自定义字段”，新建上述字段。
2. 为每个字段配置“上下文（Context）”，限定适用项目范围。
3. 进入“界面（Screens）”，把字段加入需求类问题的创建/编辑界面。
4. 进入“字段配置（Field Configurations）”，设置必填、可选、隐藏。
5. 进入“字段配置方案”，把字段配置分配给对应项目。
6. 进入“界面方案”，把界面分配给项目，确保字段可见。
7. 用“权限方案”控制谁能编辑业务价值等敏感字段。

配置完成后，建议用一个真实需求做验证：新建一条需求，检查团队标识、需求来源、业务价值、验收标准是否都出现且必填生效；再用 JQL 查询验证跨项目筛选是否可用，例如：

project in (PAY, ORDER, RISK)
AND "需求来源" = "合规要求"
AND "业务价值" >= 60
ORDER BY "业务价值" DESC

如果这条 JQL 能正确返回结果，说明字段已经全局可用、取值统一、可排序。反之，如果某个团队的需求查不出来，通常是字段上下文没有覆盖该项目，或界面方案没有把字段加进去。

四、字段治理的常见坑

第一，字段建得太多。每个字段都会增加填写成本，建议核心字段控制在 8–12 个以内，其余信息放进描述或子任务。第二，枚举值随意增加。需求来源每加一个值，历史数据的可比性就下降一次，应设置审批机制。第三，全局字段被项目级覆盖。如果某团队私自把“业务价值”改成文本，跨团队排序就会失效，必须通过权限和字段配置锁住类型。第四，验收标准写成一句话。验收标准不是描述，而是可验证的条件，建议在需求评审时逐条检查。

最后强调一点：字段方案不是一次配置就结束的。建议每季度回顾一次字段使用率，把连续两个版本无人填写的字段归档或删除，把新出现的共性需求评估是否升级为全局字段。字段是需求信息的骨架，骨架清晰，跨团队协作才不会在信息层面反复返工。