多个研发项目各自维护字段，常见结果是同名不同义、同义不同名，报表汇总时还要人工对口径。治理这类问题，思路是把字段从“各项目自行定义”收拢为“平台统一口径＋项目受控扩展”：先分清冲突类型，再建字段字典，在平台上配置公共字段与受控扩展字段，最后用评审、变更登记和巡检维持一致。下文给出可执行的分步流程、角色分工、单字段示例和验收清单。
要点总览（TL;DR）
- 先按同名异义、同义异名、取值口径不同、粒度不同四类盘点冲突，再决定每个字段是统一、拆分还是保留差异并登记说明。
- 治理按五步推进：导出字段清单、合并同义并标注归属、编写字段字典、在平台配置公共字段与受控扩展字段、完成存量数据映射与切换。
- 字段字典至少包含名称、业务定义、数据类型、取值集、必填性、适用范围、责任人和变更记录，由业务域负责人维护定义、平台管理员执行配置。
- 进入跨项目报表、参与跨项目流转或权限判断、被多个团队用于同一决策的字段应纳入平台统一口径；只在单项目内部使用的字段可保留项目定义并登记差异。
- 验收看四项：字典覆盖率与责任人确认、平台配置与字典一致、存量映射完成率与异常处理、新增字段是否走审批登记并有定期巡检。
先判断不一致属于哪一类，再决定治理力度
字段治理容易一上来就做全量重构，代价高且打断项目运转。更稳妥的做法是先盘点冲突，按类型归类，再决定每个字段是统一、保留差异还是加说明。研发平台里常见的字段不一致可以归为四类，治理动作各不相同。
| 类型 | 典型表现 | 治理动作 |
|---|---|---|
| 同名异义 | 三个项目都有“优先级”，一个表示业务紧急度，一个表示技术风险，一个表示排期先后 | 统一命名或拆分字段，让名称对应唯一含义；无法合并的拆成两个字段并各自定义 |
| 同义异名 | “负责人”“经办人”“处理人”指向同一角色；“模块”“组件”“子系统”指向同一层级 | 合并为统一名称，旧名称作为别名登记，避免继续新增 |
| 取值口径不同 | “严重程度”有的用 P0–P3，有的用高/中/低，有的用 1–5 分 | 统一取值集，明确每个取值的判定标准；项目确有需要时用受控选项集扩展 |
| 粒度不同 | “迭代”在一个项目指两周 Sprint，在另一个项目指月度版本；“工时”有的按人天有的按小时 | 统一粒度和单位，或在字段定义中写明单位与统计口径，报表按统一口径换算 |
判断一个字段是否必须统一，可以看三个条件：是否进入跨项目报表或度量、是否参与跨项目流转或权限判断、是否被多个团队用于同一决策。满足任一条件，字段就应纳入平台统一口径。只在单个项目内部使用、不参与汇总的字段，可以保留项目定义，但要在字段字典中登记适用范围和差异说明，防止后续被误用为公共字段。
治理力度也应与影响面匹配。进入管理层报表的字段优先统一；仅影响单项目操作的字段可以延后处理。这样可以把有限精力放在口径冲突最明显、返工成本最高的字段上。
治理步骤：从字段盘点走到平台统一配置
治理按五步推进，每步都有明确输入、动作、输出和完成标志，便于平台管理员和业务域负责人分工执行。
第一步：导出各项目字段清单，形成盘点底表
输入是各项目当前的工作项类型、字段名称、字段类型、取值集、是否必填、使用该字段的工作流节点。动作是从平台导出或在配置界面逐项目记录，汇总成一张盘点底表，字段按“项目—工作项类型—字段”三级排列。输出是完整的字段清单底表。完成标志是每个在用项目都有清单，且字段数量与平台配置一致，没有遗漏隐藏字段。
第二步：合并同义字段，识别冲突并标注业务归属
输入是盘点底表。动作是按字段名称和实际取值做比对，把指向同一业务含义的字段归为一组，标注同名异义、同义异名、取值口径不同、粒度不同四类问题；同时为每组字段标注业务归属，例如需求类、缺陷类、任务类、发布类。输出是字段冲突清单和归并建议。完成标志是每个冲突字段都有归属结论：合并、拆分、保留并说明。
第三步：编写字段字典，确定名称、定义、类型、取值、必填性、责任人
输入是冲突清单和归并建议。动作是逐字段编写字典条目，把定义写到可判定的程度，例如“优先级”要说明它衡量的是业务紧急度还是交付顺序，取值集中每个值给出判定标准。输出是可发布的字段字典。完成标志是字典条目通过业务域负责人确认，且每个字段都有明确责任人。
字段字典建议至少包含以下内容，可直接作为模板使用：
| 字典项 | 填写要求 |
|---|---|
| 字段名称 | 平台内唯一，避免使用项目内部简称 |
| 业务定义 | 一句话说明衡量对象和判定边界，能据此判断取值 |
| 数据类型 | 文本、单选、多选、数值、日期、人员等 |
| 取值集 | 枚举值及每个值的判定标准；数值字段写明单位和精度 |
| 必填性 | 必填、选填，以及必填的触发条件 |
| 适用范围 | 平台公共字段或指定项目扩展字段 |
| 责任人 | 对该字段定义和变更负责的角色 |
| 变更记录 | 版本、变更内容、审批人、生效时间 |
第四步：在平台配置公共字段与受控扩展字段
输入是已确认的字段字典。动作是在平台配置中心建立公共字段，统一名称、类型和取值集；项目确有差异需求时，通过受控的扩展字段或选项集表达，并在字典中登记差异原因和适用范围。输出是平台字段配置与字典一致的配置记录。完成标志是抽查任一项目的工作项界面，字段名称、取值和必填性与字典一致。
在ONES中，工作项字段配置和项目模板可以承载这类统一动作：公共字段在平台侧统一维护，项目按模板继承，项目级差异通过受控扩展表达。ONES Project的自动化规则在「配置中心」的「自动化规则」页面集中管理，管理员可以统一查看规则运行状态和日志，这与字段口径统一后的流程校验可以配合使用，帮助发现字段取值被绕过或规则未按预期触发的情况。具体字段类型和选项集的管理方式，以平台当前配置界面为准。
第五步：存量数据映射与切换安排
输入是字段字典和冲突清单。动作是为每个被合并或改名的字段建立映射表，写明旧项目、旧字段、旧取值、新字段、新取值、转换规则；对无法自动映射的记录单独列出，安排人工确认。切换安排要写明生效时间、冻结窗口和回退方式。输出是映射表和切换计划。完成标志是映射表覆盖全部存量字段，异常记录有处理人和处理结论，切换后抽查数据与字典口径一致。
角色分工与交付物：谁定义、谁配置、谁维护
字段治理失败的常见原因是定义有人提、维护无人管。把职责落到角色和交付物上，字段才有持续一致的依据。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 平台管理员 | 维护平台字段配置，执行公共字段和扩展字段的配置变更，核对配置与字典一致 | 平台配置记录、配置变更日志 |
| 业务域负责人 | 确认字段业务定义、取值标准和适用范围，裁决跨项目口径冲突 | 字段定义确认意见、冲突裁决结论 |
| 项目负责人 | 提出项目差异需求，确认本项目存量数据映射结果 | 扩展字段申请、映射确认记录 |
| 数据使用方 | 反馈报表口径问题，验证统一后字段是否满足分析需求 | 口径问题清单、验收反馈 |
字段字典的维护责任建议落在业务域负责人，平台管理员负责按字典执行配置，两者分离可以避免“谁配置谁定义”带来的口径漂移。字段新增、修改、废弃走统一申请：申请人说明业务场景和影响范围，业务域负责人审批定义，平台管理员登记并配置，变更记录写回字典。废弃字段不直接删除，先标记停用并保留历史数据可读，待确认无报表和流程依赖后再清理。
示例：一个“优先级”字段如何统一
以下为演示情景，用于说明治理过程，不代表真实项目数据。
治理前，三个项目对“优先级”的定义各不相同：项目A用“高/中/低”，表示业务紧急度；项目B用“P0–P3”，表示技术风险等级；项目C用“1–5”，表示排期先后。三者在跨项目报表中被直接汇总，导致同一数值含义不同。
治理时先归类：这属于同名异义，同时取值口径不同。业务域负责人确认，管理层真正需要跨项目比较的是业务紧急度，因此保留“优先级”名称，统一定义为业务紧急度，取值集为“紧急/高/中/低”，每个值给出判定标准，例如“紧急”指影响线上可用性或阻塞关键交付。项目B的技术风险另设“风险等级”字段，项目C的排期先后由迭代排期和计划开始时间表达，不再占用“优先级”。
平台配置上，“优先级”作为公共字段统一名称、类型和取值集，设为必填；项目B的“风险等级”作为受控扩展字段，在字典中登记适用范围为项目B，取值集为 P0–P3。存量数据按映射表转换：项目A的“高/中/低”直接对应“高/中/低”；项目B的 P0–P3 迁入“风险等级”，原“优先级”按业务紧急度重新判定；项目C的 1–5 按排期先后映射为“紧急/高/中/低”，无法判断的记录列入异常清单由项目负责人确认。切换后抽查三个项目的工作项，字段名称、取值和必填性均与字典一致。
完成检查：治理是否真正落地
治理是否完成，不看文档是否写完，而看平台配置、存量数据和变更机制是否同时到位。可按以下清单逐项核对。
- 字段字典覆盖率：在用项目的工作项字段是否全部登记，公共字段和扩展字段是否都有定义、责任人和适用范围。
- 责任人确认：每个字段是否有业务域负责人确认记录，冲突字段是否有裁决结论。
- 配置一致性：抽查各项目工作项界面，字段名称、类型、取值集、必填性是否与字典一致，差异是否有登记。
- 存量映射：映射表是否覆盖全部被合并或改名的字段，映射完成率和异常记录处理结论是否可查。
- 变更机制：治理后新增或修改的字段是否走申请、审批和登记，字典变更记录是否连续。
- 巡检机制：是否约定固定周期核对平台配置与字典，是否指定巡检人和问题闭环方式。
巡检可以按季度或按平台配置变更触发，重点核对新增字段是否登记、项目是否私自修改公共字段取值、报表口径是否与字典一致。发现偏差时回到字典和配置两个环节修正，并把处理结果写回变更记录，使字段口径在项目演进中保持可追溯。
常见问题
字段统一后，项目确实有特殊需求怎么办？
先判断这个需求是否影响跨项目汇总或流转。如果只影响本项目内部操作，可以在字段字典中登记为项目扩展字段，写明差异原因、适用范围和责任人，由平台管理员按受控方式配置，避免它被误当作公共字段使用。如果该需求会进入跨项目报表，则应回到业务域负责人处重新确认公共定义，通过调整取值集或拆分字段解决，而不是在项目内另起一套口径。
存量数据映射时遇到无法判断的旧取值，应该怎么处理？
把这类记录单独列入异常清单，标注旧项目、旧字段、旧取值和无法映射的原因，指定项目负责人逐条确认，不要用默认值批量填充。异常记录的处理结论要写回映射表，作为验收依据。如果异常量较大，说明字段字典的取值判定标准还不够清晰，应先补充判定标准再继续映射，避免把模糊口径带进新配置。
公共字段的取值集后续需要调整，走什么流程？
按字段变更申请处理：申请人说明调整原因和影响范围，业务域负责人审批定义变更，平台管理员在平台上调整配置并更新字典，变更记录写明版本、内容、审批人和生效时间。涉及存量数据的取值调整，同步更新映射关系并安排复核。已废弃的取值先标记停用、保留历史数据可读，确认没有报表和流程依赖后再清理。
治理完成后，怎么防止项目私自修改公共字段？
从权限和巡检两方面入手。平台侧把公共字段的配置权限收拢到平台管理员，项目负责人只保留扩展字段的申请权；巡检按固定周期核对平台配置与字段字典，重点检查新增字段是否登记、公共字段取值是否被改动、报表口径是否与字典一致。发现偏差时回到字典和配置两个环节修正，并把处理结果写入变更记录。ONES Project 的自动化规则在「配置中心」的「自动化规则」页面集中管理，管理员可以查看规则运行状态和日志，可用于配合检查字段取值是否被绕过或规则未按预期触发。
字段很多时，是否要一次性全部治理？
不必。按影响面排序，优先处理进入管理层报表、参与跨项目流转或权限判断的字段，这些字段口径冲突带来的返工成本最高。只在单项目内部使用、不参与汇总的字段可以延后，先在字典中登记现状和适用范围，避免继续新增同义字段。分批推进时，每批都完成配置、映射和抽查再进入下一批，防止半途切换造成数据口径混乱。
