研发流程自动化把需求、开发、测试、发布中重复且规则明确的管理动作，固化为可执行的触发条件、流转规则和校验规则。本文按“选环节—定规则—分角色—做配置—查效果”的顺序，给出可落地的步骤、角色交付物与检查清单，聚焦规则驱动的流程自动化。
要点总览（TL;DR）
- 研发流程自动化从高频、规则清楚、跨角色交接多的环节切入，用重复频率、规则明确度、交接次数三个维度打分排序，先做收益最直接的环节。
- 落地按五步推进：梳理现状流程、定义工作项类型与状态机及必填字段、配置自动流转与校验通知、小范围试运行收集卡点、上线固化，每步都有输入、动作、输出和完成标志。
- 角色分工按流程负责人定规则、研发管理者确认业务口径并验收、工具管理员配置维护、一线执行者反馈卡点划分；小团队可合并角色，规则变更的评审环节应保留。
- 上线的基本完成标志是规则可复现、异常有出口；运行中重点看流转时长、卡点分布和规则绕过比例，不达标时先修规则定义，再调工具配置。
先定规则：哪些研发流程环节值得自动化
研发流程自动化适合从“高频、规则清楚、交接多”的环节切入。判断一个环节是否值得自动化，先看它是否反复发生、判断条件能否写成明确规则、是否涉及多个角色来回交接。三个条件同时成立的环节，自动化收益最直接；只满足一两个的，可以先记录，暂不投入配置。
可以用一张简单的评分表筛选。每个候选环节按1～3分打分，总分高的优先进入规则梳理。
| 筛选维度 | 判断问题 | 高分特征 | 低分特征 |
|---|---|---|---|
| 重复频率 | 这个动作每周或每个迭代发生多少次 | 每天或每个迭代多次发生 | 偶发、按季度或按项目发生 |
| 规则明确度 | 触发条件和判断条件能否写成“满足A则进入B” | 条件可枚举、判断标准一致 | 依赖经验判断、标准因人而异 |
| 跨角色交接次数 | 完成这个动作需要几个角色传递信息或确认 | 三个及以上角色接力 | 单人独立完成 |
需要区分两类动作。适合规则自动化的动作包括：需求提交后按类型自动进入评审、开发完成后自动转测试、测试通过后触发发布审批、缺陷严重等级变化时通知相关负责人、字段缺失时阻止状态推进。需要人工判断的动作包括方案取舍、风险评估、优先级争议裁决、是否允许例外放行。后一类不宜整体自动化，可以只把前置信息收集和后置记录归档做成自动动作，判断本身仍由人完成。
筛选完成后输出一份待自动化环节清单，至少包含：环节名称、发生频率、规则描述、涉及角色、当前耗时、优先级、暂不自动化的原因。清单按优先级排序，作为后续规则梳理的输入。完成标志是每个候选环节都有明确的“做或不做”结论和依据，而不是把所有环节都列进来。
核心操作步骤：从规则梳理到自动流转上线
规则落地可以按五步推进。每一步都应有明确的输入、动作、输出和完成标志，避免配置到一半发现规则本身没对齐。
第一步：梳理现状流程
输入是待自动化环节清单和现有流程说明。动作是把该环节的现状画成一条链路，标注每个节点的触发条件、判断条件、流转去向、责任角色和当前使用的表单或记录方式。输出是一张现状流程图和问题标注。完成标志是能说清“什么情况下从哪个状态走到哪个状态”，并且找出现状中靠口头通知、手工改状态、私下确认的地方。
第二步：定义工作项类型、状态机与必填字段
输入是现状流程图。动作是确定用哪类工作项承载该流程，例如需求、任务、缺陷或发布单；定义状态集合和允许的流转路径；为每个状态设置进入条件和必填字段。输出是规则定义表和状态机配置说明。完成标志是任意一个状态都能回答“谁能进入、进入前必须填什么、进入后由谁处理”。
| 规则要素 | 要写清的内容 | 示例 |
|---|---|---|
| 触发条件 | 什么事件启动流程 | 需求单创建并提交 |
| 判断条件 | 按什么字段或结果分流 | 需求类型为“功能需求”且影响范围为大 |
| 流转去向 | 满足条件后进入哪个状态、交给谁 | 进入“技术评审”，指派给架构负责人 |
| 必填字段 | 进入该状态前必须补齐的信息 | 评审结论、预计工作量、关联版本 |
| 通知规则 | 状态变化时通知谁、以什么方式 | 状态变更通知当前处理人和流程负责人 |
第三步：配置自动流转、字段校验与通知规则
输入是规则定义表。动作是在工具中把规则配置为可执行逻辑：状态变更由条件触发，字段不满足时阻止提交，关键节点自动通知相关角色。输出是可运行的流程配置和配置说明文档。完成标志是用测试数据走一遍主路径和至少一条异常路径，结果与规则定义表一致。
第四步：小范围试运行并收集卡点
输入是已配置好的流程。动作是选择一个团队或一个迭代试运行，记录每次流转的实际耗时、被卡住的位置、执行者绕过规则的操作。输出是试运行问题清单。完成标志是主路径可以稳定走通，异常情况有明确出口，试运行团队能说清规则要求。
第五步：上线与固化
完成标志有两条：规则可复现，即相同输入得到相同流转结果；异常有出口，即不满足条件时有明确的退回、挂起或人工审批路径，而不是让执行者手工改状态绕过。达到这两条后，把规则定义表、状态机说明和配置记录归档，作为后续变更的基线。
角色与交付物：谁定规则、谁维护、谁验收
流程自动化建设需要四类角色配合。小团队可以合并角色，但规则变更的评审环节应保留，否则规则容易随个人习惯漂移。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 流程负责人 | 定义流程目标、规则口径和状态机，判断哪些环节自动化 | 待自动化环节清单、规则定义表、状态机说明 |
| 研发管理者 | 确认业务口径，裁决规则冲突，验收自动化效果 | 规则评审结论、试运行验收意见 |
| 工具管理员 | 在工作项工具中配置状态、字段、自动流转和通知，维护配置记录 | 流程配置说明、变更记录、试运行问题清单 |
| 一线执行者 | 按规则提交和流转工作项，反馈卡点与不合理规则 | 卡点反馈、规则绕过情况说明 |
规则变更走一条固定路径：任何人可提出变更申请，说明要改的规则、原因和影响范围；流程负责人评估是否影响其他环节；研发管理者确认业务口径；工具管理员执行配置并记录版本；变更后在原试运行范围验证一次。变更记录应包含变更前后规则、生效时间和验证结果。
各角色在关键节点的交付物要能对应上：流程负责人交付的规则定义表是工具管理员的配置依据；工具管理员交付的配置说明是研发管理者验收的对象；一线执行者的卡点反馈是下一轮规则修订的输入。交付物之间能追溯，规则才不会停留在文档里。
示例：一条需求流转规则的完整配置
以下示例为演示情景，用于说明规则如何从文字描述落到工作项配置，不代表任何具体产品的实际界面。
示例场景与触发条件。某团队希望需求提交后自动进入评审，避免需求长期停留在“待处理”。触发条件设为：需求单创建并提交，且“需求类型”和“影响范围”两个字段已填写。未填写时不允许提交，从源头保证信息完整。
状态流转与必填字段设置。状态机设为“草稿—待评审—评审中—已排期—开发中—已完成”，并允许“评审中”退回“待评审”。关键配置如下：
| 当前状态 | 触发动作 | 判断条件 | 流转去向 | 必填字段 |
|---|---|---|---|---|
| 草稿 | 提交 | 需求类型、影响范围已填 | 待评审 | 需求描述、提出人、期望版本 |
| 待评审 | 开始评审 | 已指派评审人 | 评审中 | 评审人、评审时间 |
| 评审中 | 评审通过 | 评审结论为通过 | 已排期 | 评审结论、预计工作量、目标版本 |
| 评审中 | 评审不通过 | 评审结论为退回 | 待评审 | 退回原因、补充材料说明 |
异常分支与回退处理。评审超过约定时间未处理时，自动通知评审人和流程负责人，状态保持“评审中”并标记超时；评审人无法判断时，可转交上级评审，转交需填写转交原因；需求在“已排期”后发生范围变更，退回“待评审”重新走评审，原评审结论保留为历史记录。异常分支的原则是每种卡点都有下一步动作，而不是停在原地。
输入、动作与输出。输入是需求单及已填字段；动作是提交、指派、评审、通过或退回；输出是状态变化记录、评审结论、通知记录和超时标记。运行一段时间后，可以统计各状态停留时长和退回次数，判断规则是否合理。
在把这类规则落到工作项工具时，ONES 可以通过工作项类型、状态流转、字段校验和通知规则承载上述配置，让需求按设定条件自动进入下一节点，并在字段缺失或超时时给出提示。具体可配置项以团队实际使用的版本和部署方式为准，选型时可重点核验状态机是否支持条件流转、必填字段能否按状态设置、通知能否按角色触发。
完成检查：上线前与运行中的核对项
判断自动化是否真正生效，分上线前和运行中两个阶段核对。上线前看规则是否完整可执行，运行中看规则是否被遵守、是否产生新的卡点。
上线前检查
- 规则覆盖：待自动化清单中的每个环节都有对应配置，主路径和异常路径都能走通。
- 字段完整性：每个状态的必填字段已设置，缺失时确实阻止流转。
- 权限设置：各角色只能执行其职责范围内的操作，审批和退回权限明确。
- 通知规则：关键节点通知到正确的人，通知内容包含工作项和处理要求。
- 异常出口：退回、挂起、转交、超时提醒都有明确配置，执行者无需手工改状态。
- 配置记录：规则定义表、状态机说明和配置版本已归档，可追溯。
运行中检查
- 流转时长：统计各状态平均停留时间和超时比例，找出耗时最长的节点。
- 卡点分布：按团队、工作项类型、状态统计积压位置，判断是规则问题还是执行问题。
- 规则绕过情况：统计跳过必填字段、手工改状态、线下确认后补录的比例，绕过比例高说明规则与实际工作不匹配。
- 退回与返工：统计退回次数和原因分布，频繁退回的节点需要重新审视判断条件。
不达标时按顺序调整：先修规则定义，确认触发条件、判断条件和必填字段是否与实际工作一致；再调工具配置，检查流转条件、权限和通知是否配置正确；最后才考虑增加提醒或考核。绕过比例高时，优先访谈一线执行者，找到规则与实际操作脱节的地方，而不是简单加强管控。检查清单建议每个迭代或每月核对一次，把结果记入流程改进记录，作为下一轮规则修订的依据。
常见问题
规则已经写清楚了，试运行时一线执行者仍然手工改状态绕过，应该先改规则还是先加强管控？
先查规则与实际工作脱节的地方。绕过比例高通常说明必填字段过多、判断条件与实际判断方式不一致，或者异常情况没有配置出口，执行者只能手工处理。建议访谈执行者，记录每次绕过的具体原因，按“先修规则定义、再调工具配置、最后才考虑提醒或考核”的顺序处理。规则本身合理、配置也正确时，再讨论执行纪律。
小团队人手有限，四类角色合并后，哪些职责不能省？
角色可以合并，规则变更的评审环节建议保留。至少要有一个人对规则口径负责，一个人确认业务口径，配置执行与变更记录由同一人承担也可以。变更时说明改什么、为什么改、影响哪些环节，并在原试运行范围验证一次。缺少评审和记录，规则容易随个人习惯漂移，后续排查问题时找不到变更依据。
流程自动化上线后，多久核对一次比较合适，核对结果怎么用？
可以按迭代或按月核对一次，节奏与团队的计划周期对齐。核对内容包括各状态平均停留时间、超时比例、积压集中位置、跳过必填字段和手工改状态的比例、退回次数与原因分布。结果记入流程改进记录，作为下一轮规则修订的输入；连续多个周期稳定的规则可以减少核对频次，波动大的节点优先复查。
需求在排期后发生范围变更，原评审结论怎么处理？
建议退回评审状态重新走一遍评审，原评审结论保留为历史记录，不覆盖。重新评审时重点看变更部分对工作量、目标版本和关联需求的影响，必填字段中补充变更说明。这样既保证变更经过确认，也保留完整的决策轨迹，便于后续追溯为什么调整了排期。
把规则落到工作项工具时，选型应重点核验哪些配置能力？
重点核验三项：状态机是否支持按条件流转，必填字段能否按状态分别设置并在缺失时阻止提交，通知能否按角色或字段触发。此外确认退回、挂起、转交、超时提醒等异常路径可以配置，配置变更是否留有记录。ONES 可以通过工作项类型、状态流转、字段校验和通知规则承载这类配置，具体可配置项以团队实际使用的版本和部署方式为准。
