2. Jira核心概念与术语体系
在Jira中，所有服务流程最终都落在几个基础对象上。理解这些对象，不是背术语，而是理解“谁承载业务、谁控制流转、谁决定可见性、谁约束操作”。如果把这些对象混为一谈，配置时就会出现典型问题：把权限配在字段上、把流程状态当成看板列、把项目当成团队、把屏幕当成权限边界。下面按“业务承载—流转控制—视图呈现—交互约束—安全边界”的顺序，把Jira核心对象及其在服务流程中的角色讲清楚。
Issue：服务流程的最小业务单元
Issue（问题/工单）是Jira中最基本的业务对象。一次服务请求、一个缺陷、一项变更、一个子任务，最终都以Issue的形式存在。Issue本身不是“一张表单”，而是一个带有唯一Key（如 HELP-1024）、类型（Issue Type）、状态（Status）、经办人（Assignee）、报告人（Reporter）、优先级（Priority）以及若干自定义字段的数据记录。
在服务流程中，Issue的角色是“承载业务事实”。例如一个IT服务请求，Issue上会记录：请求人、影响系统、紧急程度、期望完成时间、当前处理人、处理过程评论、附件日志。Issue Type决定了它走哪条工作流、用哪套屏幕、显示哪些字段。常见Issue Type包括：服务请求、事件、问题、变更、子任务。其中“子任务”不能独立存在于项目下，必须挂在某个父Issue上，适合把一次变更拆成“开发—测试—发布”多个执行项。
Issue的关键字段中，Status表示当前所处流程节点，Resolution表示关闭原因（如已解决、无法复现、重复、不予处理），两者常被混淆：Status是“现在在哪”，Resolution是“为什么结束”。在服务台场景中，只有Status进入“已完成”且Resolution被设置，报表中的“解决率”才准确。
Project：业务边界与配置容器
Project（项目）是Issue的归属容器，也是权限、工作流、屏幕、字段配置的挂载点。一个Project通常对应一条业务线、一个产品、一个服务目录或一个团队的服务范围。Project有Key（如 OPS、DEV），Issue Key由Project Key加序号组成。
Project在服务流程中的角色是“边界”。它决定了：哪些人可以创建Issue、哪些人可以浏览、哪些人可以流转、使用哪套工作流、显示哪些字段。Jira中Project分为公司管理项目（Company-managed）和团队管理项目（Team-managed）。公司管理项目适合需要统一流程、统一权限、跨团队报表的服务体系；团队管理项目适合小团队快速自治，但配置共享能力较弱。服务流程通常建议核心服务台使用公司管理项目，以保证权限方案、字段配置、工作流可复用。
Workflow：状态、转换与流转规则
Workflow（工作流）定义Issue从创建到关闭所经历的状态和转换。它由三部分组成：Status（状态）、Transition（转换）、Condition/Validator/Post Function（条件、校验、后置动作）。
例如一条服务请求工作流可以设计为：待受理 → 处理中 → 待验证 → 已完成，并允许处理中 → 已挂起、待验证 → 处理中（验证不通过打回）。每个转换可以配置：只有“服务台成员”角色才能执行“受理”；执行“完成”时必须填写Resolution；执行“升级”后自动把经办人改为二线组。这些规则不是装饰，而是服务流程的硬约束。
需要特别区分：Workflow的Status与Board的Column不是一回事。Board列是状态到列的映射，一个列可以映射多个状态，也可以只映射一个状态。如果映射混乱，看板会出现“卡片在列里但状态不对”的现象。
Board：面向团队的可视化视图
Board（看板）是基于过滤器（Filter）或项目查询结果的可视化视图，分为Scrum Board和Kanban Board。Board不存储数据，它只是“查询+列映射+泳道”的展示层。Board在服务流程中的角色是“让流转可见”：服务台用Kanban看板按状态列展示待受理、处理中、待验证、已完成；研发团队用Scrum看板按Sprint展示任务。
Board的关键配置包括：Filter（决定显示哪些Issue）、Columns（状态到列的映射）、Swimlanes（泳道，如按优先级或经办人分组）、Quick Filters（快捷过滤，如“仅我的”“仅高优先级”）。在服务流程中，常用泳道按“紧急程度”分组，让P1事件始终浮在最上方。
Screen、Field与Field Configuration：交互与数据约束
Screen（屏幕）决定Issue在创建、编辑、查看、转换时显示哪些字段。Field（字段）是Issue上的数据项，分为系统字段（如Summary、Assignee、Priority）和自定义字段（如“影响系统”“变更窗口”“客户编号”）。Screen Scheme把不同操作映射到不同屏幕，例如创建屏幕只显示必填字段，编辑屏幕显示全部字段，转换屏幕只显示流转所需字段。
Field Configuration（字段配置）控制字段是否必填、是否隐藏、描述和渲染类型。它与Screen的区别是：Screen决定“看不看得见”，Field Configuration决定“可不可编辑、是否必填”。在服务流程中，常见做法是：创建时“影响系统”必填，处理中“根因”必填，关闭时“解决方案”必填。这样既保证数据完整，又不让请求人在创建时面对过多字段。
Permission Scheme：安全边界与操作授权
Permission Scheme（权限方案）是Project级别的授权集合，决定“谁可以对Issue做什么”。它包含Browse Projects、Create Issues、Edit Issues、Transition Issues、Assign Issues、Administer Projects等权限项，每项可授予用户、组、项目角色或Issue角色。
在服务流程中，权限方案是安全边界。典型配置是：请求人属于“服务台客户”角色，只能Browse、Create、Comment；服务台成员属于“服务台代理”角色，可以Transition、Assign、Edit；二线工程师属于“开发”角色，可以处理技术子任务但不能关闭客户工单。需要强调的是：权限方案不控制字段级可见性，字段级安全要用“字段安全级别”或“Issue安全级别”实现。
对象之间的协作关系：以一次服务请求为例
把上述对象串起来看，一次IT服务请求的完整链路是：请求人在Project（如HELP）中创建Issue，Issue Type为“服务请求”；创建时经过Screen校验必填字段（影响系统、紧急程度）；创建后进入Workflow的“待受理”状态；服务台成员通过Permission Scheme获得Transition权限，将Issue流转到“处理中”；Board按列映射把“待受理”“处理中”“待验证”“已完成”展示出来；处理过程中，Field Configuration要求填写根因；关闭时校验Resolution必填。整个过程中，Issue是数据载体，Project是边界，Workflow是规则，Board是视图，Screen/Field是交互约束，Permission Scheme是安全边界。
常见混淆与判断依据
| 容易混淆的对象 | 核心区别 | 判断依据 |
|---|---|---|
| Status vs Resolution | Status是当前节点，Resolution是关闭原因 | 看Issue是否已结束，结束必须有Resolution |
| Workflow Status vs Board Column | Status是流程节点，Column是展示列 | 一个Column可映射多个Status，反之不成立 |
| Screen vs Permission Scheme | Screen控制字段可见/可编辑，Permission控制操作授权 | “看不到字段”查Screen，“不能流转”查Permission |
| Project vs Board | Project是数据容器，Board是查询视图 | Board可以跨Project查询，Project不能跨Board存在 |
| Field Configuration vs Screen | 前者控制必填/隐藏，后者控制显示位置 | 字段在屏幕上但不可编辑，查Field Configuration |
理解这些对象的关键，不是记住定义，而是建立“数据—规则—视图—约束—权限”的分层意识。当服务流程出现问题时，可以按这个分层快速定位：数据不对查Issue和Field，流转不对查Workflow，展示不对查Board，操作不对查Screen和Permission Scheme。这样，Jira的配置才不是零散开关的堆叠，而是一套可解释、可维护的服务流程支撑体系。