工作项字段字典把字段名称、标识、类型、取值范围、必填规则、适用工作项类型、责任人和变更记录固定下来，让不同项目在平台上按同一口径填写和统计。设计时从工作项类型和业务问题出发，再定义字段清单与取值口径，完成平台配置和小范围试填，最后通过评审与变更记录维持一致。下文给出可直接套用的属性表、角色分工、需求类示例和完成检查清单。
要点总览（TL;DR）
- 工作项字段字典把字段名称、标识、类型、取值范围、必填规则、适用工作项类型、责任人和变更记录固定下来，是业务规则在平台上的配置说明。
- 设计顺序为：梳理工作项类型与业务问题、定义字段清单与口径、平台配置、试填校验、评审与变更，每步都要有输入、动作、输出和完成标志。
- 字段类型按业务判断方式选择，需要统计的字段用单选、多选、日期或数值；必填只留给缺失后会影响流程判断或统计的字段。
- 业务负责人确认口径，平台配置管理员负责配置与文档同步，研发团队参与试填，评审人把关命名与取值一致性。
- 发布前逐项核对字段完整性、命名与取值一致性、类型适配、工作项类型对应关系、必填合理性、责任与变更记录、试填问题闭环。
先定字段字典要解决哪些配置问题
字段字典承载的是业务规则的平台表达：它规定某个工作项在什么阶段需要记录哪些信息、每个信息允许填什么、由谁维护。优先级如何判定、验收标准写到什么程度，属于业务规则本身的定义，字段字典只负责把这些规则转成可配置、可核对的字段约束。把边界划清，可以避免字典越写越厚，也能防止字段配置反过来替代业务讨论。
整体推进顺序为五步：梳理工作项类型与业务问题、定义字段清单与口径、平台配置、试填校验、评审与变更。每一步都应有明确输入、动作、输出和完成标志，否则容易出现字段建了一堆却没人使用，或者配置改过之后文档没有同步的情况。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 梳理工作项类型与业务问题 | 现有工作项类型清单、各角色的填写诉求、报表与统计需求 | 按工作项类型列出需要回答的业务问题，剔除重复和无人使用的诉求 | 工作项类型与业务问题对照清单 | 每个工作项类型都有明确的字段需求来源，无来源的字段不进入下一步 |
| 定义字段清单与口径 | 上一步的对照清单 | 为每个字段确定名称、标识、类型、取值、必填规则和责任人 | 字段属性表 | 字段无重名、无同义重复，取值口径经业务负责人确认 |
| 平台配置 | 字段属性表 | 在平台中创建字段，挂到对应工作项类型和界面布局 | 平台配置结果 | 字段在目标工作项类型中可见、可填，必填规则生效 |
| 试填校验 | 配置结果、少量真实工作项 | 按真实场景填写，记录字段可填性、取值够用程度和必填阻塞情况 | 试填反馈记录 | 发现的问题均有修订结论，字典与配置同步更新 |
| 评审与变更 | 修订后的字典与配置 | 评审命名、取值一致性和责任落实，建立变更记录 | 评审结论、变更记录 | 字典可发布，后续新增和修改有审批路径 |
这五步不必一次覆盖全部工作项类型。治理起步阶段可以先选需求、缺陷这类填写频率高、统计诉求明确的工作项类型做完整闭环，再按同样方法扩展到其他类型。
字段清单与字段属性怎么定义
字段属性表是字段字典的主体，建议固定以下列，每个字段占一行。列固定下来之后，新增字段时按列填写，评审时也按列核对，减少口径遗漏。
| 列名 | 填写要求 | 示例 |
|---|---|---|
| 字段名称 | 面向填写人的中文名称，使用业务通用词，同一含义只保留一个名称 | 需求来源 |
| 字段标识 | 平台内唯一标识，发布后不再复用；字段废弃时保留标识并标注停用 | req_source |
| 字段类型 | 按业务判断方式选择，见下文说明 | 单选 |
| 取值范围 | 枚举值或数值区间，同一字段内取值唯一、含义单一 | 客户反馈、内部规划、运营提出、合规要求 |
| 默认值 | 仅在多数场景有明确默认时填写，避免默认值掩盖真实情况 | 空 |
| 是否必填 | 按缺失后是否影响流程判断或流转来判定 | 是 |
| 适用工作项类型 | 列出使用该字段的工作项类型，避免全类型通用造成填写负担 | 需求 |
| 责任人 | 负责该字段口径解释和变更发起的人 | 产品负责人 |
| 变更记录 | 记录变更时间、变更内容、发起人和审批人 | 2025-03 新增“合规要求”枚举值 |
字段类型的选择依据是业务判断方式，而非界面偏好。需要自由描述背景和细节时用文本；答案落在有限选项内时用单选，允许多个选项并存时用多选；需要记录时间点用日期；需要比较或汇总的量用数值；责任归属用人员字段；需要跨对象追溯来源或关联关系时用关联对象。类型选错会直接影响后续统计，例如把本应单选的来源写成文本，统计时就会出现“客户反馈”“客户提出”“来自客户”等多种写法。
取值范围和枚举值要遵循三条命名规则：同一字段内取值唯一，不出现两个含义相同的选项；每个取值含义单一，不用“其他”“待定”承载多种情况；新增取值走变更记录，不在平台配置中直接添加后不更新字典。枚举值建议按业务实际分类顺序排列，而不是按添加时间排列，方便填写人快速定位。
必填与选填的判定标准可以归纳为一句话：缺失该字段是否会导致流程无法判断、无法流转或无法统计。影响流转判断的字段设为必填，仅用于补充说明的字段设为选填。把所有字段都设为必填，会让填写人为了提交而随意填写，反而降低数据质量。
角色分工与交付物怎么安排
字段字典涉及提出需求、配置平台、实际填写和把关口径四类动作，角色不清时最常见的问题是字段由配置人员单方面决定，业务方不认口径。建议按下表划分职责和交付物，规模较小的团队可以由一人兼任多个角色，但交付物仍需分开留存。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 业务负责人 | 提出字段需求，确认取值口径和必填规则，解释字段的业务含义 | 字段需求说明 | 字段清单定稿前确认口径 |
| 平台配置管理员 | 按字段属性表在平台创建字段、绑定工作项类型和界面布局，同步更新字典文档 | 平台配置结果、字段字典文档 | 配置完成后移交试填 |
| 研发团队 | 在真实工作项中试填，反馈字段是否可填、取值是否够用、必填是否阻塞 | 试填反馈记录 | 试填结束后提交问题清单 |
| 评审人 | 核对命名、类型、取值一致性和责任人落实，审批字段新增与变更 | 评审结论、变更记录 | 发布前评审，变更时复核 |
字段新增与变更建议走同一条路径：提出人说明变更原因和影响范围，业务负责人确认口径，平台配置管理员评估对已有数据和报表的影响，评审人审批后由配置管理员执行并登记变更记录。影响已有统计口径的变更，例如修改枚举值含义或删除字段，应提前通知使用该字段的团队，并保留旧值的处理说明。
一个字段字典示例：需求类工作项
下面以需求类工作项为例，示范字段字典片段的填写方式。示例中的取值和必填规则仅用于说明写法，实际口径由各团队业务负责人确认。
| 字段名称 | 字段标识 | 字段类型 | 取值范围 | 是否必填 | 使用场景 |
|---|---|---|---|---|---|
| 需求来源 | req_source | 单选 | 客户反馈、内部规划、运营提出、合规要求 | 是 | 需求进入需求池时填写，用于按来源统计需求结构 |
| 优先级 | req_priority | 单选 | P0、P1、P2、P3 | 是 | 排期评审前确定，用于排序和资源分配 |
| 目标版本 | req_target_version | 单选或关联对象 | 按版本清单取值 | 是 | 需求进入排期时填写，用于版本范围核对 |
| 验收责任人 | req_acceptor | 人员 | 项目成员 | 是 | 需求评审通过后指定，用于验收交接 |
| 需求背景 | req_background | 文本 | 自由填写 | 否 | 补充说明来源和业务价值，供评审参考 |
这组示例体现了几个一致性规律：字段名称使用业务通用词，标识采用“对象前缀加含义”的英文短名，同一前缀下的字段便于识别归属；单选字段的取值按业务分类排列，不使用“其他”兜底；必填字段集中在影响排期和验收判断的信息上，背景说明类字段设为选填。优先级的具体判定标准属于业务规则，字典只固定取值集合和填写时点。
配置落地与试填校验怎么做
平台配置建议按“先建字段，再挂到工作项类型，最后调整界面布局”的顺序推进。先建字段可以保证标识和类型一次确定，挂到工作项类型时核对适用范围，界面布局决定填写人在哪个环节看到哪些字段。顺序颠倒容易出现字段建好却挂错类型，或者布局中重复出现同义字段。
试填选择少量真实工作项，覆盖不同来源和不同优先级的场景，重点观察三类问题：字段是否可填，包括类型是否匹配、选项是否可选；取值是否够用，包括枚举值是否覆盖实际出现的情况；必填是否造成阻塞，包括在流程早期是否被迫填写尚不确定的信息。试填记录建议按下表格式留存。
| 字段 | 问题描述 | 问题类型 | 修订结论 | 处理状态 |
|---|---|---|---|---|
| 需求来源 | 出现“合作伙伴提出”，现有枚举值未覆盖 | 取值不足 | 新增枚举值并登记变更记录 | 已闭环 |
| 目标版本 | 需求进入时版本尚未确定，必填导致随意填写 | 必填阻塞 | 改为排期节点后必填 | 已闭环 |
| 验收责任人 | 部分需求由多人共同验收 | 类型不适配 | 评估改为多人员字段或增加协验人字段 | 待评审 |
试填发现的问题要回写到字段字典，修订结论确定后同步修改平台配置，并更新字典文档中的变更记录。配置与文档同步更新是维持字典可用的关键动作，建议把“配置变更后更新字典”写入配置管理员的日常职责，而不是依赖事后补记。
在 ONES 中，需求支持自定义状态与多种属性，项目采用组件化设计，可按业务需求定义项目类型与相关组件，字段配置可以随工作项类型一起组织。多层级权限可按组织架构、用户组和项目角色分配，便于区分字段维护人与填写人。工单场景支持自定义处理流程与字段配置，配置中心提供自动化规则的管理入口和运行日志，可用于排查规则执行问题。字段级权限和字段变更历史的支持情况，需以实际环境核验后再纳入治理方案。
完成检查：字段字典是否可用
发布前按下表逐项核对，全部通过即可作为当前版本的字段字典使用；未通过项应回到对应步骤修订，不带着已知问题发布。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 字段完整性 | 每个字段的名称、标识、类型、取值范围、必填规则是否填写齐全 | 属性表无空缺列，标识无重复 |
| 命名与取值一致性 | 是否存在同义字段、同义枚举值或含义模糊的选项 | 同一含义只有一个名称和一个取值 |
| 类型适配 | 字段类型是否与业务判断方式匹配 | 需要统计的字段采用可枚举或可汇总的类型 |
| 工作项类型对应关系 | 每个字段的适用工作项类型是否明确 | 无“全类型通用”的模糊表述，字段与类型一一可查 |
| 必填合理性 | 必填字段是否都影响流程判断或统计 | 无因必填导致试填阻塞且未修订的字段 |
| 责任与变更记录 | 每个字段是否有责任人，变更是否有记录和审批 | 责任人和变更记录可查，审批路径明确 |
| 试填问题闭环 | 试填记录中的问题是否都有修订结论 | 无遗留的待处理问题，或已明确处理计划 |
字典发布后，维护动作集中在两处：新增字段或修改取值时走变更审批并登记记录；定期核对平台配置与字典文档是否一致。团队规模较小、字段数量有限时，可以简化评审人数和核对频率，但字段标识不复用、变更留记录这两条建议保留，它们是后续统计和追溯的基础。
常见问题
字段字典和平台里的字段配置是什么关系？
字段字典是配置的依据，平台字段配置是字典的执行结果。字典记录字段名称、标识、类型、取值范围、必填规则、适用工作项类型、责任人和变更记录；平台配置按字典创建字段、绑定工作项类型和界面布局。两者需要同步更新，配置改过之后字典没有同步，后续统计和交接就会失去依据。
团队规模小、字段不多，字段字典可以简化到什么程度？
可以简化评审人数和核对频率，例如由业务负责人和配置管理员两人确认后发布，不必单独组织评审会。字段属性表的列建议保留，尤其是字段标识、取值范围、必填规则和责任人；字段标识不复用、变更留记录这两条也建议保留，它们是后续统计和追溯的基础。简化的是流程强度，不是字段口径本身。
试填时发现必填字段在流程早期填不出来，应该怎么处理？
先判断该字段是否真的影响流程判断。如果它只在后续环节才有确定答案，可以把必填时点后移到对应节点，而不是直接改为选填；如果字段本身只是补充说明，改为选填即可。修订结论要回写到字段字典，同步修改平台配置，并在变更记录中登记调整原因和影响范围。
同一字段在不同工作项类型中含义不同，能共用一个字段吗？
不建议共用。字段标识一经发布不再复用，同一标识承载两种含义会让统计口径混乱。可以为不同工作项类型分别建字段，名称上体现所属对象，例如需求来源和缺陷来源分开定义；如果两者取值集合完全一致、统计时也按同一口径汇总，再考虑共用并明确适用范围。
字段字典发布后，怎么保证平台配置和文档不脱节？
把“配置变更后更新字典”写入平台配置管理员的日常职责，而不是依赖事后补记。新增字段或修改取值时走变更审批，登记变更时间、内容、发起人和审批人；定期核对平台配置与字典文档是否一致。影响已有统计口径的变更，例如修改枚举值含义或删除字段，提前通知使用该字段的团队，并保留旧值的处理说明。
