📚 课程目录第3章请求类型与工作项架构

3. 请求类型与工作项架构

在 Jira Service Management（JSM）中，服务目录是面向用户的门面，而请求类型、工作项类型、字段与屏幕方案则是支撑这个门面的骨架。很多团队在初期只关注“能不能提交工单”，结果上线后出现字段混乱、审批缺失、报表无法统计等问题。本节的核心任务，是把“用户看到什么”与“系统内部怎么存”这两层结构对齐，形成一套可维护、可扩展的请求类型架构。

一、先理清四个概念的分工

JSM 的请求模型由四个层次组成，它们各自承担不同职责：

服务目录（Service Catalog）：面向请求者的入口，按业务场景分组，例如“办公支持”“账号权限”“网络接入”。用户从目录进入后选择具体服务。
请求类型（Request Type）：用户实际点击的“服务项”，例如“申请新邮箱”“重置 VPN 密码”。它决定用户看到哪些字段、表单如何呈现、提交后走什么流程。
工作项类型（Work Type / Issue Type）：Jira 平台层的分类，例如“服务请求”“事件”“变更”“问题”。请求类型最终会映射到某个工作项类型，决定它在 Jira 中的行为与报表归属。
字段与屏幕方案（Field & Screen Scheme）：控制字段在创建、查看、编辑、转换等环节的显示与必填状态。屏幕方案把字段组织成不同屏幕，再绑定到工作项类型和操作上。

四者的关系可以概括为：服务目录组织请求类型，请求类型映射到工作项类型，工作项类型绑定字段与屏幕方案。任何一层错位，都会导致用户看到不该看的字段，或后台缺少必要的数据。

二、请求类型的设计原则

请求类型不是越多越好。一个常见的误区是把每个细小的需求都做成独立请求类型，结果服务目录膨胀到几十项，用户找不到入口，管理员也难以维护。合理的做法是按“用户意图”聚合，而不是按“后台动作”拆分。

例如，“申请新邮箱”和“申请邮箱别名”在后台可能都走同一套账号创建流程，但对用户来说意图不同，可以保留为两个请求类型，共享同一个工作项类型和屏幕方案。相反，“重置 VPN 密码”和“重置邮箱密码”如果字段和审批完全一致，可以合并为一个“密码重置”请求类型，通过一个“系统”下拉字段区分。

设计时建议遵循三条规则：

一个请求类型对应一个明确的用户意图，名称用用户能看懂的业务语言，而不是技术术语。
字段数量控制在 5～8 个以内，只保留流程真正需要的字段。每增加一个字段，都要问“没有它流程能不能走通”。
请求类型必须映射到唯一的工作项类型，避免同一请求类型在不同项目间行为不一致。

三、字段与屏幕方案的落地方法

字段设计的关键是区分“创建时必填”和“处理时必填”。请求者提交时只需要提供他能回答的信息，例如姓名、部门、用途；而“资产编号”“审批人”“预计完成时间”这类字段，应该放在处理阶段的编辑屏幕或转换屏幕上，由服务台或审批人填写。

在 JSM 中，屏幕方案通过“屏幕”与“操作”的绑定来实现这一点。典型配置如下：

屏幕名称	绑定操作	包含字段	必填控制
创建屏幕	创建请求	姓名、部门、用途、期望完成时间	姓名、部门、用途必填
查看屏幕	查看请求	全部字段（只读）	无
处理屏幕	编辑 / 处理	资产编号、审批人、处理备注	资产编号、审批人必填
关闭屏幕	关闭请求	解决方案、关闭备注	解决方案必填

这样配置后，请求者提交时不会看到“资产编号”这类他无法回答的字段，而处理人在接手后必须补齐关键信息，保证数据完整。

四、建立服务目录与请求类型的映射关系

映射关系的本质是“分组归属”。一个服务目录可以包含多个请求类型，但一个请求类型只能属于一个服务目录（在 JSM 的默认结构中）。建立映射时，建议用一张映射表来管理，避免口头约定导致后期混乱。

以下是一个可参考的映射示例，假设我们为“IT 服务台”项目设计目录结构：

服务目录：账号与权限
  ├─ 请求类型：申请新邮箱
  │    工作项类型：服务请求
  │    屏幕方案：邮箱申请屏幕方案
  ├─ 请求类型：重置 VPN 密码
  │    工作项类型：服务请求
  │    屏幕方案：密码重置屏幕方案
  └─ 请求类型：申请系统访问权限
       工作项类型：服务请求
       屏幕方案：权限申请屏幕方案

服务目录：网络与接入
  ├─ 请求类型：申请网络端口
  │    工作项类型：服务请求
  │    屏幕方案：网络端口屏幕方案
  └─ 请求类型：报告网络故障
       工作项类型：事件
       屏幕方案：故障报告屏幕方案

服务目录：硬件与资产
  ├─ 请求类型：申请显示器
  │    工作项类型：服务请求
  │    屏幕方案：硬件申请屏幕方案
  └─ 请求类型：申请设备更换
       工作项类型：变更
       屏幕方案：变更申请屏幕方案

这张映射表可以直接作为配置检查清单。每新增一个请求类型，就补一行；每调整一个屏幕方案，就核对它绑定的工作项类型是否正确。映射关系清晰后，后续的自动化规则、SLA 设置和报表统计都能找到稳定的锚点。

实践建议：在正式配置前，先用一张电子表格把“服务目录 → 请求类型 → 工作项类型 → 屏幕方案 → 关键字段”五列填满，与业务方确认后再进入 JSM 后台操作。这样可以避免反复修改已上线的请求类型，减少对用户的影响。

注意：请求类型一旦被用户使用并产生工单，修改其绑定的工作项类型或删除字段可能导致历史数据异常。建议在测试项目中先验证映射关系，确认无误后再迁移到生产项目。

总结来说，请求类型与工作项架构的设计，核心是“用户意图”与“系统行为”之间的翻译。服务目录负责让用户找得到，请求类型负责让用户填得对，工作项类型负责让系统管得住，字段与屏幕方案负责让数据收得全。四层对齐之后，服务目录与请求类型的映射关系就是一张可执行、可审计的配置地图。