研发平台业务配置要解决的是把业务规则稳定地落到平台上，让不同角色按同一套对象、字段、状态和权限协作。适用前提是规则本身已由业务负责人确认；本文聚焦平台如何承载规则，按规则盘点、配置映射、角色分工、示例落地和上线检查五步推进，并说明每一步的输入、动作与产出。
要点总览（TL;DR）
- 研发平台业务配置的起点是规则盘点：按业务对象列出需要平台承载的规则，标注责任角色与承载结论，规则定义由业务负责人确认后再进入配置。
- 把规则映射为工作项类型、字段、状态流转、权限和自动化五类配置载体，保留规则编号，使每条规则可追溯到配置项和验证方式。
- 状态流转与权限要成对设计；条件明确、动作单一的规则适合自动化，涉及判断与例外的规则保留人工评审。
- 配置过程至少明确业务负责人、配置管理员、研发团队代表和评审者四类角色，各自有输入与交付物，变更保留评审记录。
- 上线前用试点数据核对规则覆盖度、字段完整性、权限正确性、状态流转可达性和自动化运行，设定阻断项与回退条件后再分批推广。
先分清哪些业务规则该由平台承载
配置工作最常见的返工来源，是把尚未定清的业务规则直接带进平台。开始配置前，先做一次规则盘点：按业务对象逐条列出需要平台承载的规则，判断它属于业务定义问题还是平台承载问题，并标注责任角色。盘点完成后再进入配置，可以避免配置管理员替业务方做业务决策。
盘点的输入是现有制度、流程文档和团队实际做法；动作是逐条记录规则并确认归属；输出是一份业务规则盘点表。表中建议包含以下字段：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 规则描述 | 用一句话写清触发条件与期望结果 | 缺陷修复完成并验证通过后，状态由“待验证”变为“已关闭” |
| 业务对象 | 规则作用于哪类对象 | 缺陷 |
| 责任角色 | 谁对这条规则的定义负责 | 测试负责人 |
| 是否由平台承载 | 是／否／部分承载 | 是 |
| 归属主题 | 规则定义归属的业务主题 | 质量管理 |
判断“是否由平台承载”时，可以问三个问题：这条规则是否有明确的触发条件和结果？是否需要在平台上被记录、查询或统计？是否涉及多个角色的协作交接？三者都成立，通常适合由平台承载。规则本身的业务合理性、阈值设定和例外情形，属于相应业务主题的定义范围，由业务负责人确认；本文只讨论这些规则如何映射为平台配置。旧配置向新平台的搬迁属于迁移类工作，也不在本文范围内。
盘点表完成后，应由业务负责人逐条确认，确认标志是每条规则都有明确的责任角色和承载结论。未确认的规则先挂起，不进入下一阶段的配置映射。
把业务规则映射为平台配置对象
规则确认后，下一步是把每条规则拆解为平台上的具体配置项。研发平台通常通过五类载体承载业务规则：工作项类型、字段、状态流转、权限和自动化规则。映射时保留规则编号，使每条规则都能追溯到具体配置和验证方式，形成规则—配置映射表。
| 规则编号 | 业务对象 | 配置载体 | 配置值 | 验证方式 |
|---|---|---|---|---|
| R-01 | 缺陷 | 工作项类型 | 新增“缺陷”类型，关联缺陷字段组 | 新建工作项时可选该类型 |
| R-02 | 缺陷 | 字段 | 严重程度为必填单选，选项分四级 | 不填严重程度无法提交 |
| R-03 | 缺陷 | 状态流转 | 待验证→已关闭，仅测试角色可操作 | 用测试账号执行流转 |
| R-04 | 缺陷 | 权限 | 开发角色可编辑处理中状态，不可关闭 | 用开发账号尝试关闭被拒绝 |
| R-05 | 缺陷 | 自动化规则 | 关联需求全部完成后自动流转来源需求状态 | 构造子项全部完成的数据观察联动 |
状态流转与权限需要成对设计。状态变化往往同时改变可操作角色，例如“待验证→已关闭”只允许测试角色执行，那么配置时既要定义流转路径，也要确认该状态下的操作权限边界。只配状态不配权限，容易出现越权关闭；只配权限不配状态，则流转路径无法走通。建议在映射表中为每条涉及状态变化的规则同时列出流转条件和操作角色。
自动化与人工评审的取舍，取决于规则的条件是否明确、动作是否单一。条件清晰、结果唯一的规则适合配置为自动化，例如状态联动、负责人分派、父子工作项状态同步；涉及判断、例外审批或跨团队协商的规则，宜保留人工评审环节，由自动化只承担提醒或状态同步。把需要判断的规则强行自动化，往往在上线后产生大量误触发。
映射表完成后，配置管理员据此逐项配置，业务负责人复核配置值是否与规则原意一致。复核通过的标志是映射表中每一行都有对应的配置结果和可执行的验证方式。
配置工作的角色分工与交付物
业务配置涉及业务定义、平台操作和效果验证三类工作，角色不清会导致规则确认与配置执行相互等待。建议至少明确四类角色，并为每个角色约定输入和交付物。
| 角色 | 主要职责 | 输入 | 交付物 |
|---|---|---|---|
| 业务负责人 | 确认规则定义、判定承载范围、验收配置结果 | 业务制度、流程文档 | 已确认的业务规则盘点表 |
| 平台配置管理员 | 执行工作项类型、字段、状态、权限与自动化配置 | 规则—配置映射表 | 配置完成记录与映射表回填 |
| 研发团队代表 | 参与试点，反馈配置与实际工作的偏差 | 试点任务与操作说明 | 试点问题清单 |
| 评审者 | 评审配置变更，确认上线条件 | 配置记录、试点结果 | 评审结论与上线决定 |
配置变更应保留评审与变更记录，写明变更原因、影响范围和验证结果。记录的作用是在上线后出现问题时能回溯到具体变更，而不是依赖个人记忆。评审者与配置管理员可以由同一人兼任，但业务规则的确认权应留在业务负责人一侧，避免配置者同时定义规则和验证规则。
在平台承载层面，ONES Project 的自动化规则由 Project 管理员在「配置中心」的「自动化规则」页面统一管理，管理者可按需求自定义规则，并提供运行日志用于排查规则运行状态；预置模板覆盖负责人自动分配、需求与工单状态同步、父子工作项状态联动等常见场景。这类能力适合承接映射表中条件明确的自动化条目，具体可用范围以所购版本和部署方式为准。
一个配置示例：缺陷状态流转规则落地
以下示例演示一条缺陷状态规则从描述到验证的完整过程，可参照迁移到需求、任务等其他对象。示例中的角色和字段为演示情景，实际配置以团队规则为准。
规则描述：缺陷修复完成并提交验证后，状态由“处理中”变为“待验证”；测试验证通过后，由“待验证”变为“已关闭”，该操作仅测试角色可执行；验证不通过则退回“处理中”。责任角色为测试负责人。
配置内容：
- 状态集合：新建、处理中、待验证、已关闭、重新打开。
- 流转路径：处理中→待验证（开发角色提交）；待验证→已关闭（测试角色）；待验证→处理中（测试角色退回）。
- 字段：严重程度必填；验证结论在关闭前必填。
- 权限：开发角色可编辑处理中状态，不可执行关闭；测试角色可执行待验证与关闭操作。
- 自动化：缺陷关联的修复任务全部完成后，自动将缺陷状态由处理中改为待验证，并通知测试负责人。
试点验证：选取一个迭代内的缺陷数据，由测试角色和开发角色分别用各自账号执行完整流转，观察三项结果：流转路径是否全部可达、越权操作是否被拦截、自动化触发是否与实际完成情况一致。观察口径统一为“预期结果与实际结果”两列记录，出现偏差的条目进入问题清单，由配置管理员修正后重新验证。试点通过后再向其他团队推广。
上线前的配置完成检查
配置是否可用，不能只看配置项是否填完，而要看规则是否真正被平台承载并被角色正确执行。上线前按下表逐项核对，每项给出通过标准。
| 检查项 | 检查内容 | 通过标准 |
|---|---|---|
| 规则覆盖度 | 盘点表中标记为平台承载的规则是否都有对应配置 | 映射表无空缺行，每条规则可追溯到配置项 |
| 字段完整性 | 必填字段、选项值、默认值是否符合规则 | 按规则构造的数据可正常提交，缺必填项被拦截 |
| 权限正确性 | 各角色在关键状态下的可操作范围 | 用各角色账号验证，越权操作被拒绝 |
| 状态流转可达性 | 所有定义的流转路径能否走通 | 每条路径至少执行一次，无死状态 |
| 自动化运行 | 自动化规则的触发条件与结果 | 构造数据触发后结果符合预期，运行日志无异常 |
| 试点与评审记录 | 试点问题是否闭环，评审是否完成 | 问题清单全部关闭或有明确处理结论，评审结论为通过 |
阻断项指不满足即不能推广的检查项，通常包括规则覆盖度存在空缺、关键状态流转不可达、权限验证出现越权。出现阻断项时暂停推广，由配置管理员修正并重新验证；若修正涉及规则定义变化，需回到业务负责人重新确认。回退条件建议提前约定，例如试点期间同类问题反复出现且影响正常流转，则回退到上一版配置并保留变更记录。
全部检查项通过并形成评审结论后，配置即可进入推广阶段。推广时按团队分批启用，保留一段观察期，继续用运行日志和试点问题清单跟踪配置效果，使业务配置在规则变化时能够持续调整。
常见问题
业务规则还没定清楚，可以先在平台上配置起来吗？
不建议。规则定义未确认时进入配置，配置管理员容易替业务方做业务决策，后续规则调整会带来反复改配置。更稳妥的做法是先完成规则盘点，由业务负责人逐条确认责任角色和承载结论，未确认的规则挂起，确认后再进入映射与配置阶段。
哪些规则适合配置成自动化，哪些应保留人工环节？
判断依据是规则的条件是否明确、动作是否单一。条件清晰、结果唯一的规则适合自动化，例如状态联动、负责人分派、父子工作项状态同步；涉及判断、例外审批或跨团队协商的规则，宜保留人工评审，自动化只承担提醒或状态同步。把需要判断的规则强行自动化，上线后容易产生大量误触发。
配置管理员和业务负责人可以由同一人担任吗？
评审者与配置管理员可以由同一人兼任，但业务规则的确认权应留在业务负责人一侧。配置者同时定义规则和验证规则，会让规则确认失去独立校验，出现问题也难以判断是规则本身还是配置执行的问题。
试点验证要观察哪些内容，观察多久？
试点选取一个迭代内的真实数据，由各角色用各自账号执行完整流转，按“预期结果与实际结果”两列记录偏差。观察重点包括流转路径是否全部可达、越权操作是否被拦截、自动化触发是否与实际完成情况一致。观察期长度按团队节奏确定，试点问题清单全部关闭或有明确处理结论后再推广。
上线后发现配置有问题，应该改配置还是回退？
先判断问题性质。若属于配置值与规则不一致，由配置管理员修正并重新验证；若修正涉及规则定义变化，需回到业务负责人重新确认。建议提前约定回退条件，例如试点期间同类问题反复出现且影响正常流转，则回退到上一版配置并保留变更记录，便于回溯。
