研发平台状态配置要解决的是把业务规则变成平台能执行的规则：有哪些状态、允许怎么流转、谁能操作、变更后通知谁。落地时可按“状态集合—流转规则—权限与通知”三层推进：先梳理业务对象与状态清单，再定义流转矩阵，然后配置权限与校验，最后用一条真实需求或缺陷走通全流程并留存配置文档。
要点总览（TL;DR）
- 状态配置先定业务对象：需求、任务、缺陷、工单各自一套主状态定义，同义状态合并，避免多套叫法并存。
- 状态定义表至少包含状态名称、状态类别、是否终止态、对应看板列和进入条件，主状态数量控制在五到八个。
- 流转规则用“当前状态×目标状态”的矩阵表达，每条流转挂接触发条件、必填字段和校验规则，回退、撤销、重开单独定义。
- 权限按角色分配，与流转矩阵配合：矩阵定义能怎么走，角色定义谁能走，越权变更需拦截并留审计记录。
- 上线前用一条真实需求或缺陷走完整生命周期，验证流转、必填、越权拦截、通知与报表口径，并归档配置说明与变更记录。
先定对象：状态配置要挂在哪个业务对象上
状态配置的起点是确定业务对象。研发平台里常见的对象包括需求、任务、缺陷、工单，它们各自有独立的生命周期：需求从提出到验收关闭，缺陷从提交到验证关闭，工单从受理到处理完成。把这些对象的状态混在一张表里，后续流转规则和权限判断都会失去边界。
梳理时按对象逐个列出生命周期，每个对象只保留一套主状态定义。如果同一对象在不同团队有不同叫法，例如“处理中”“开发中”“进行中”并存，应合并为一个状态，把差异放到字段或标签里表达。状态命名直接使用业务人员日常沟通的词汇，避免为了平台配置另造一套术语。
这一步的交付物是业务对象与状态清单，建议按“对象—状态—含义”三列记录，含义一栏写清进入该状态的条件和离开该状态的常见去向。清单经业务负责人确认后再进入下一步，可以减少后续返工。
| 业务对象 | 状态示例 | 含义说明 |
|---|---|---|
| 需求 | 待评审 | 需求已提交，等待业务与技术共同确认范围 |
| 需求 | 开发中 | 需求已排期，研发人员正在实现 |
| 缺陷 | 待验证 | 修复已完成，等待测试确认 |
| 工单 | 处理中 | 已指派处理人，正在定位或解决 |
状态集合怎么设计：状态、类别与终止态
状态集合的设计目标是让每个状态都能被看板、报表和自动化规则一致地识别。建议为每个状态定义四个字段：状态名称、状态类别、是否终止态、对应看板列。状态类别用于聚合统计，常见取值包括未开始、进行中、已完成、已关闭；终止态表示该状态下不再发生常规流转，例如“已关闭”“已取消”。
状态与看板列、报表口径要一一对应。看板列可以按状态类别分组，报表按类别统计周期内的完成量，避免直接按状态名称统计导致口径随命名调整而波动。状态数量需要控制：一个对象的主状态通常控制在五到八个，超过这个范围时先检查是否存在可以合并的同义状态，或可以把细分差异放到子状态、标签、字段中表达。
下表是一张可直接填写使用的状态定义表，字段说明和示例并列，团队按自己的对象替换示例内容即可。
| 字段 | 填写说明 | 示例 |
|---|---|---|
| 状态名称 | 业务日常使用的名称，全平台统一 | 开发中 |
| 状态类别 | 未开始/进行中/已完成/已关闭 | 进行中 |
| 是否终止态 | 是/否，终止态不再常规流转 | 否 |
| 对应看板列 | 该状态在看板上落入的列 | 进行中列 |
| 进入条件 | 满足什么条件可以进入该状态 | 需求已排期且已指派负责人 |
流转规则怎么配：流转矩阵与触发条件
流转规则回答“从哪个状态可以改到哪个状态，以及改之前要满足什么条件”。用流转矩阵表达最直观：行是当前状态，列是目标状态，单元格填写是否允许以及附带条件。矩阵填完后，平台配置就有了明确依据，评审时也便于业务和技术逐格确认。
每条允许的流转需要挂接三类信息：触发条件（例如必须已指派处理人）、必填字段（例如转“待验证”时必须填写修复说明）、校验规则（例如关联的测试用例必须已执行）。条件与流转绑定，可以避免状态被随意推进后留下不完整的数据。
| 当前状态 | 目标状态 | 触发条件 | 必填字段 |
|---|---|---|---|
| 待评审 | 开发中 | 评审通过且已排期 | 负责人、计划完成时间 |
| 开发中 | 待验证 | 代码已提交并关联变更记录 | 修复说明或实现说明 |
| 待验证 | 已完成 | 验证通过 | 验证结论 |
| 待验证 | 开发中 | 验证不通过，退回处理 | 退回原因 |
回退、撤销、重开属于特殊流转，需要单独定义。回退通常允许从验证或完成状态退回进行中，并要求填写原因；撤销用于误操作纠正，应限制在短时间内且记录操作人；重开用于已关闭对象重新进入流程，建议要求关联原单并说明重开理由。特殊流转同样进入矩阵，不留在平台默认行为里。
角色与权限：谁能改状态、谁只读
流转矩阵定义“能怎么走”，角色权限定义“谁能走”。两者配合的方式是：先按职责划分角色，例如需求提出人、研发负责人、测试人员、项目管理员，再为每个角色标注对每类对象的状态操作权限，包括可查看、可流转、可回退、可关闭。权限按角色分配而不是按个人逐一配置，人员变动时只需调整角色归属。
字段级权限与状态联动可以解决“同一状态下不同角色看到不同信息”的问题。例如缺陷在“待验证”状态下，测试人员可编辑验证结论，研发人员只读；进入“已关闭”后，除管理员外均只读。越权变更需要在平台层拦截，并保留审计记录，记录操作人、原状态、目标状态、时间和变更原因，便于事后追溯。
| 角色 | 可查看状态 | 可流转操作 | 字段编辑范围 |
|---|---|---|---|
| 需求提出人 | 全部 | 提交评审、验收关闭 | 需求描述、验收结论 |
| 研发负责人 | 全部 | 排期、开始开发、提交验证 | 负责人、计划时间、实现说明 |
| 测试人员 | 全部 | 验证通过、验证退回 | 验证结论、缺陷关联 |
| 项目管理员 | 全部 | 全部，含撤销与重开 | 全部 |
通知、自动化与报表口径的衔接
状态变更后的联动要围绕“谁需要知道、系统该做什么、数据怎么统计”来配置。通知对象按状态和角色确定：进入“待验证”通知测试负责人，进入“已完成”通知需求提出人，发生回退时通知原处理人。通知时机放在状态变更成功之后，避免流转失败仍发出消息。
自动化动作需要设定边界。常见做法包括状态变更后自动指派下一环节处理人、子任务全部完成后自动推进父工作项状态、需求状态同步到来源工单。ONES 的自动化规则提供“任务与需求的状态联动：全部任务完成后，自动完成来源需求”“父子工作项状态联动：全部子任务完成后，自动完成父工作项”等预置模板，也支持需求状态同步到来源工单的处理结果；规则由 Project 管理员在「配置中心」的「自动化规则」页面管理，运行日志可展示规则运行状态，便于排查未触发或误触发的情况。配置自动化时应明确触发条件、执行动作和例外情况，例如“自动关闭”只对超过约定时间且无新回复的工单生效，避免把仍需处理的对象误关。
报表与看板按状态类别聚合，而不是按状态名称逐项统计。这样状态名称调整时报表口径保持稳定，跨团队对比也有共同基准。需要区分“已完成”和“已关闭”时，在类别下再按终止态拆分即可。
| 联动类型 | 触发点 | 动作 | 配置边界 |
|---|---|---|---|
| 通知 | 进入待验证 | 通知测试负责人 | 仅状态变更成功后发送 |
| 自动化 | 全部子任务完成 | 自动完成父工作项 | 父工作项无未完成关联项时生效 |
| 自动化 | 需求状态变更 | 同步到来源工单处理结果 | 仅对已关联工单生效 |
| 报表 | 按周期统计 | 按状态类别聚合完成量 | 类别定义全平台统一 |
上线前用一条真实业务走通：验证与检查
配置完成后，选一条真实需求或缺陷，从创建开始走完整生命周期，每一步都按设计检查：状态能否按矩阵流转、必填字段是否生效、无权限角色是否被拦截、通知是否送达正确对象、自动化是否按预期触发、报表数字是否与手工核对一致。走查中发现的问题回到对应配置项修正，而不是在流程里临时绕行。
异常场景要专门验证：越权账号尝试流转是否被拦截并留下审计记录；必填字段为空时是否阻止提交；对象长期停留在某一状态时是否有提醒或升级机制；回退和重开是否要求填写原因。这些场景覆盖后，配置才算具备可运行性。
最后留存配置说明文档与变更记录。文档写清对象、状态定义、流转矩阵、角色权限和联动规则，变更记录写清每次调整的原因、影响范围和确认人。后续新增对象或调整流程时，以这份文档为基线修改，避免平台配置与业务约定脱节。
- 状态清单经业务负责人确认，同义状态已合并
- 流转矩阵覆盖常规流转与回退、撤销、重开
- 角色权限对照表覆盖全部状态操作，越权拦截已验证
- 通知与自动化规则逐条触发验证，运行日志可查
- 报表按状态类别聚合，数字与手工核对一致
- 配置说明文档与变更记录已归档
常见问题
状态配置应该由业务团队还是平台管理员主导？
建议业务负责人主导状态语义，平台管理员负责配置实现。业务负责人确认对象、状态名称、含义和流转条件，管理员把这些内容翻译成平台里的状态、流转规则和权限设置。两边分工明确后，配置评审时逐项对照业务清单，可以减少“平台配了但业务不认”的返工。
状态数量已经很多，怎么判断哪些可以合并？
先看两个状态在业务沟通中是否被当作同一件事处理，例如“处理中”“开发中”“进行中”如果指向同一段工作，就合并为一个状态。再看差异能否用字段或标签表达，例如不同缺陷类型可以共用一个“处理中”状态，用类型字段区分。合并后主状态通常控制在五到八个，超出时优先检查同义状态和可下沉到字段的细分差异。
回退和重开要不要单独配置，还是沿用常规流转？
建议单独定义。回退通常从验证或完成状态退回进行中，要求填写退回原因；重开用于已关闭对象重新进入流程，建议关联原单并说明理由；撤销用于误操作纠正，应限制时间窗口并记录操作人。把这些特殊流转写进流转矩阵，平台配置和后续审计都有依据，也能避免它们以默认行为悄悄发生。
状态变更后的自动化规则怎么避免误触发？
每条自动化规则要写清触发条件、执行动作和例外情况。例如“全部子任务完成后自动完成父工作项”需要确认父工作项没有其他未完成关联项；“自动关闭”只对超过约定时间且无新回复的工单生效。ONES 的自动化规则提供父子工作项状态联动、需求状态同步到来源工单等预置模板，由 Project 管理员在「配置中心」的「自动化规则」页面管理，运行日志可查看规则运行状态，便于排查未触发或误触发的情况。
配置上线后业务规则调整了，怎么改才不破坏已有数据？
以配置说明文档为基线修改，先评估影响范围：涉及哪些对象、哪些状态、哪些角色和自动化规则。新增状态通常比删除状态安全，删除前先确认没有在途对象停留在该状态。调整流转矩阵时同步更新权限对照表和自动化规则，改完后用一条真实业务再走一遍，并把变更原因、影响范围和确认人记入变更记录。
