研发平台业务配置的落地顺序可以概括为：先把口头约定整理成可配置对象，再按“工作项类型—字段—状态流转—权限—自动化”逐层配置，每层用样例数据验证，最后形成配置清单与变更记录。本文聚焦平台如何承载已经定义清楚的业务规则，规则本身的业务定义仍由对应业务主题负责。
要点总览（TL;DR）
- 配置从一份待配置规则与配置对象对照清单开始，每条规则都要有业务确认人，避免配置人员替业务做判断。
- 平台配置按“工作项类型—字段—状态流转—权限—自动化”五层顺序推进，每层有明确的输入、输出和完成标志，顺序颠倒容易返工。
- 业务负责人负责规则定义与验收，平台管理员负责实施与变更记录，团队代表用真实数据参与验证，交付物统一归入配置档案。
- 上线前检查配置完整性、权限越权和流转断点，用真实样例数据覆盖正常路径与异常路径，通过后再进入日常维护。
- 配置变更走申请与评审，变更记录与配置文档同步更新，人员交接时整体移交配置档案。
配置前先定清楚：哪些业务规则要落到平台上
配置的起点是一份待配置规则与配置对象对照清单。没有这份清单就直接进平台点配置，常见结果是字段越加越多、状态越改越乱，最后没人说得清某个字段为什么存在。清单的作用是把“我们平时是这么做的”转成“平台上需要配置什么”，让配置动作有据可依。
先划清一条边界：业务规则的定义属于业务侧，比如需求评审要经过哪几个角色、缺陷按什么标准分级、什么情况下允许关闭工作项，这些由业务负责人确认；平台配置负责的是把这些规则映射成工作项类型、字段、状态、权限和自动化规则。同一条规则可能既需要业务定义，也需要平台承载，两者要分开记录，避免配置人员替业务做判断。
提取待配置规则的常用来源有三类：现有流程图或流程说明文档、正在使用的模板（需求模板、测试用例模板、周报模板等）、审批单和流转记录。逐条阅读时问三个问题：这条规则涉及哪类工作项、需要记录哪些信息、在什么条件下由谁推进到下一步。答案能直接对应到配置对象。
把提取结果整理成对照清单，建议包含以下列：规则编号、规则描述、规则来源、涉及工作项类型、需要的字段、涉及的状态变化、涉及的角色、是否需要自动化、业务确认人。清单不必一次写全，但每条规则都要有业务确认人，否则后续验收时无法判断配置是否符合预期。
| 规则示例（业务语言） | 对应配置对象 | 需业务确认的内容 |
|---|---|---|
| 需求进入开发前必须完成评审 | 状态流转、流转条件、评审记录字段 | 评审通过由谁判定、评审不通过退回哪个状态 |
| 缺陷按严重程度分级处理 | 缺陷类工作项的字段与选项 | 分级标准、各级别的响应要求 |
| 任务完成后需求才能关闭 | 自动化规则、状态联动 | 是否存在允许例外关闭的场景 |
| 只有项目负责人能调整计划时间 | 角色与权限范围 | 负责人缺席时的代理安排 |
清单完成后做一次范围评审：哪些规则本期配置、哪些留到后续、哪些规则本身还没定义清楚需要先回到业务侧讨论。这一步的产出是确认版的对照清单，作为后续分层配置的输入。
按五层顺序完成平台配置
五层顺序的依据是依赖关系：字段挂在工作项类型上，状态流转依赖字段和角色，权限约束谁能做流转和编辑，自动化规则又依赖前面四层已经就位。顺序颠倒会导致返工，比如先配了自动化规则，后面调整状态名称，规则就要重新检查一遍。
| 层级 | 输入 | 主要动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一层：工作项类型与层级 | 对照清单中的工作项类型列 | 确定需要哪些类型（如需求、任务、缺陷）、类型之间的父子或关联关系 | 工作项类型清单及层级图 | 每类工作项都能找到归属，层级关系与业务实际一致 |
| 第二层：字段与校验 | 每类工作项需要记录的信息 | 建字段、设选项、标必填、加校验规则 | 字段清单（含类型、是否必填、适用类型） | 用一条样例数据能完整填写，必填项缺失时无法提交 |
| 第三层：状态流转 | 规则中的状态变化与推进条件 | 定义状态集合、流转路径、流转条件 | 状态流转图 | 每条路径都能走通，无孤立状态和断头路径 |
| 第四层：角色与权限 | 规则中“谁可以做什么” | 建角色、分配权限范围（查看、编辑、流转、删除） | 角色—权限对照表 | 用不同角色账号验证，权限边界符合预期 |
| 第五层：通知、自动化与视图 | 前四层配置结果、通知需求 | 配置通知触发点、自动化规则、看板与列表视图 | 自动化规则清单、视图清单 | 触发一次样例动作，通知送达、规则生效、视图显示正确 |
第一层的关键判断是类型数量。类型太少，不同业务对象挤在一起，字段被迫做成大量可选，数据质量下降；类型太多，维护成本和跨类型联动复杂度上升。一个实用做法是先按“管理颗粒度不同”划分，比如需求与任务是两级管理对象，缺陷有独立的分级和流转要求，就分成不同类型；仅字段略有差异的场景优先用同一类型加字段区分。
第二层配置字段时，必填和校验规则要克制。必填项过多会让一线人员用填占位符的方式绕过，反而破坏数据可信度。建议只把“缺失就无法推进流程”的字段设为必填，其余通过视图提醒或自动化规则补全。校验规则优先覆盖格式和取值范围，比如日期不得早于创建时间、工时必须为正数。
第三层状态流转要同时画出正常路径和异常路径。正常路径是业务主流程，异常路径包括退回、挂起、取消。每条流转都写明触发条件和操作角色，条件可以是字段值满足某要求，也可以是前一状态已完成。画完后逐条检查是否存在只能进不能出的状态，以及是否存在绕过关键评审的捷径路径。
第四层权限按“角色—动作—范围”三个维度配置。角色对应岗位或职责，动作对应查看、编辑、流转、删除等操作，范围对应项目、团队或工作项类型。配置时优先用角色授权，避免给个人单独开权限，个人权限多了以后交接和审计都会变困难。配置完成后用不同角色的测试账号各走一遍关键操作。
第五层把前面四层串起来。通知要选准触发点，状态变更、字段变更、临近截止时间都是常见触发条件，但通知过多会被忽略，建议只对“需要对方采取行动”的事件发通知。自动化规则从简单场景起步，比如状态联动、自动指派，验证稳定后再增加条件分支。看板视图按角色和使用场景分别配置，管理层看进度分布，执行层看个人待办。
在自动化这一层，ONES Project 提供自动化规则能力，管理者可以自定义规则，并在统一的管理平台中查看规则运行情况；规则提供运行日志，便于排查未按预期触发的问题，也预置了自动分配负责人、需求与任务状态联动、父子工作项状态联动等常用模板，可以作为配置起点再按团队规则调整。Project 管理员在「配置中心」的「自动化规则」页面管理这些规则。
角色分工与交付物：谁定义、谁配置、谁验收
配置过程涉及三类角色，职责不清最常见的后果是配置完成后业务方说“这不是我们要的”，而平台管理员说“当时没人提”。把定义、配置、验收分开，并明确每类角色的交付物，可以把这个风险前置化解。
| 角色 | 主要职责 | 交付物 | 参与节点 |
|---|---|---|---|
| 业务负责人 | 定义业务规则、确认配置对象清单、判定配置是否符合业务预期 | 规则说明、对照清单确认意见、验收结论 | 配置前范围评审、上线前验收 |
| 平台管理员 | 按清单实施五层配置、维护配置清单与变更记录、处理配置问题 | 配置清单、变更记录、配置说明文档 | 全程 |
| 项目/团队代表 | 用真实业务场景提供样例数据、参与端到端验证、反馈使用问题 | 样例数据集、验证记录、问题清单 | 每层配置后的抽样验证、上线前端到端验证 |
业务负责人的核心交付物是“确认意见”，不是一份完整的需求文档。确认意见可以写在对照清单上，逐条标注同意、修改或暂缓，这样平台管理员拿到的是可执行的配置依据。业务负责人还需要在验收记录上签字确认，表示配置结果与业务规则一致。
平台管理员是配置清单和变更记录的唯一维护人。配置清单记录当前生效的配置项及其对应规则编号，变更记录记录每次调整的时间、内容、原因和影响范围。两份记录分开维护，前者回答“现在是什么样”，后者回答“为什么变成这样”。
团队代表的参与重点在验证环节。每层配置完成后，团队代表用本团队的真实数据走一遍，重点发现“配置能跑通但不符合实际习惯”的问题，比如某个必填字段在实际工作中经常拿不到值。这类问题在配置阶段发现成本最低。
三类角色的交付物最终汇总到同一份配置档案中：对照清单、配置清单、变更记录、验证记录、验收记录。档案由平台管理员保管，交接时整体移交，避免配置知识只存在个别人的记忆里。
一个完整示例：需求到上线的配置落地
下面以“需求从提出到上线”这条链路为例，演示五层配置如何串起来。示例中的字段和状态为演示情景，实际配置以团队已确认的规则为准。
第一层确定工作项类型。需求作为独立类型，下面挂任务作为子工作项，缺陷单独成类型并与需求关联。层级关系是需求包含任务，缺陷可关联到需求，这样需求进度可以由任务完成情况汇总，缺陷也能追溯到来源需求。
第二层配置需求类字段。基础字段包括需求标题、描述、优先级、提出人、所属产品、目标版本；流程相关字段包括评审结论、评审人、开发负责人、计划上线时间。必填项设为标题、优先级、提出人、所属产品，评审结论在进入评审通过状态时设为必填，用流转条件控制而不是全局必填。
第三层设计状态流转。状态集合为：待评审、评审中、已确认、开发中、待验收、已上线、已关闭，另有评审不通过退回待评审、需求取消进入已关闭两条异常路径。流转条件示例：进入已确认要求评审结论为通过且评审人已填写；进入待验收要求关联任务全部完成；进入已上线要求填写实际上线时间。
第四层配置权限。产品经理角色可以创建需求、提交评审、确认优先级；开发负责人可以流转开发中到待验收；测试角色可以提交验收结论；项目管理员可以关闭需求和调整计划时间。普通成员可以查看和编辑自己创建的需求描述，不能修改评审结论和上线时间。
第五层配置通知与自动化。通知触发点包括：需求进入评审中时通知评审人，评审不通过时通知提出人，需求进入待验收时通知测试角色。自动化规则包括：全部关联任务完成后自动将需求流转到待验收；需求状态变更时同步更新关联缺陷的来源需求状态字段；需求所属迭代变更时，其下任务同步移动到同一迭代。ONES Project 的预置模板覆盖了任务与需求状态联动、父子工作项状态联动、需求与任务所属迭代同步等场景，可以在模板基础上按本示例的条件调整。
验证过程用三条样例数据：一条正常走完全流程的需求，一条评审不通过后重新提交的需求，一条关联任务未完成就尝试进入待验收的需求。预期结果是第一条顺利到达已上线，第二条在待评审与评审中之间正确往返，第三条被流转条件拦截并提示未完成任务。三条都符合预期，这条链路的配置才算完成。
上线前检查与后续维护
上线前检查分三类：配置完整性、权限越权、流转断点。配置完整性检查对照清单逐条核对，确认每条规则都有对应的配置项，没有遗漏也没有多余配置；权限越权检查用低权限账号尝试高权限操作，确认被正确拦截；流转断点检查遍历所有状态，确认每个状态都有出口，每条路径都能到达终态。
端到端验证要用真实样例数据，覆盖正常路径和至少两条异常路径。验证记录写明使用的数据、执行的操作、实际结果和预期结果是否一致。发现的问题分为阻断上线和上线后优化两类，阻断问题修复后重新验证，优化项进入后续变更计划。
配置变更要有申请和评审。申请人说明变更内容、原因和影响范围，平台管理员评估影响后实施，涉及业务规则变化的变更需要业务负责人确认。每次变更都记入变更记录，包括变更前后的配置差异，便于出问题时回滚和追溯。
配置文档随变更同步更新，至少包含：工作项类型与层级说明、字段清单、状态流转图、角色权限表、自动化规则清单、视图说明。文档由平台管理员维护，人员交接时连同配置档案一并移交，接手人依据文档能在平台上找到对应配置，不需要重新摸索。
上线后前两周保持较高频的检查，关注自动化规则的运行日志和用户反馈，及时修正触发条件或通知范围。运行稳定后转为定期检查，比如每季度核对一次配置清单与实际配置是否一致，把配置治理纳入平台日常维护节奏。
常见问题
业务规则本身还没定清楚，可以先在平台上配起来吗？
不建议。平台配置是把已定义的规则映射成工作项类型、字段、状态和权限，规则本身没定清楚时配置出来的结构往往要反复改，返工成本比先讨论规则更高。遇到这类规则，先在对照清单中标注“待业务确认”，由业务负责人补充定义后再进入配置；本期可以先配置不受影响的部分，把未定规则留到后续批次。
五层配置顺序可以调整吗？比如先配权限再配状态流转？
顺序的依据是依赖关系，一般不建议大范围调整。字段挂在工作项类型上，状态流转依赖字段和角色，权限约束谁能做流转和编辑，自动化规则又依赖前四层已经就位。如果先配自动化规则再改状态名称，规则需要重新检查。团队规模很小、配置范围有限时，可以把相邻两层合并操作，但每层配置完成后仍要单独验证，确认这一层可用再进入下一层。
配置完成后业务方说“这不是我们要的”，怎么避免？
把确认动作前置到两个节点：配置前的范围评审，由业务负责人逐条确认对照清单；每层配置完成后的抽样验证，由团队代表用真实数据走一遍。业务负责人的确认意见写在清单上，逐条标注同意、修改或暂缓，平台管理员据此实施。上线前再由业务负责人在验收记录上签字，表示配置结果与业务规则一致。这样问题在配置阶段暴露，修改成本最低。
自动化规则配了不少，但经常没按预期触发，从哪里排查？
先看规则的运行日志，确认规则是否被触发、触发时条件判断的结果是什么，再对照规则配置检查触发条件和前置状态是否与当前数据一致。常见原因是流转条件或字段值不满足、规则依赖的状态名称在后续调整中发生了变化。ONES Project 的自动化规则提供运行日志，便于定位未按预期触发的问题；规则在统一的管理平台中查看运行情况，Project 管理员可以在「配置中心」的「自动化规则」页面管理这些规则。
配置文档和变更记录由谁维护，人员交接时怎么处理？
由平台管理员作为唯一维护人。配置清单记录当前生效的配置项及对应规则编号，变更记录记录每次调整的时间、内容、原因和影响范围，两份记录分开维护。配置文档随变更同步更新，至少包含工作项类型与层级说明、字段清单、状态流转图、角色权限表、自动化规则清单和视图说明。人员交接时连同对照清单、验证记录、验收记录一并移交，接手人依据文档能在平台上找到对应配置。
