2022 年我参与过一个 800 人规模研发组织的流程治理项目，进场第一周就遇到一件很典型的事：季度经营分析会上，两个事业部报出来的"需求平均交付周期"差了 3.2 倍。一个说 18 天，一个说 57 天。业务负责人当场质疑数据造假，PMO 负责人调出系统截图自证清白，结果发现两边的差不是执行差，而是 同一批任务在项目管理系统里被打上了完全不同的任务属性。A 事业部把"需求澄清完成"算作交付起点，B 事业部把"需求受理"算作起点，而两边的字段名都叫"需求开始时间"。
这件事让我确认了一个判断：绝大多数 PMO 制度设计失败，不是败在流程没画清楚，而是败在任务属性分类这一层地基没夯实。字段看起来只是系统配置，实际上是组织对"什么算一件事、这件事怎么被衡量"的公开承诺。这篇文章我会把过去几年在不同规模组织里踩过的坑、做过的取舍、验证过的判断逻辑完整拆开来讲，重点讲清楚三件事：任务属性该怎么分层、哪些分类方式一定会崩、以及"PMC 制度设计"这件事在不同组织规模下应该怎么落地。
一、核心结论：任务属性分类是治理契约，不是字段配置
先把结论摆出来，后面的内容都是围绕这几条展开的。如果你时间有限，只看这一节也能避开 70% 的坑。
- 任务属性分类的最小单位不是"字段"，而是"决策"。每新增一个字段，都要能回答：它触发什么管理动作？谁因为看到它而改变行为？如果答不上来，这个字段就是纯负债。
- 分类的自由度必须与组织的决策能力成反比。组织越不能承受口径分歧，分类越要收敛；组织越依赖一线快速响应，分类越要留白。很多 PMO 把这两件事搞反了。
- 字段是消耗品，不是固定资产。任何属性体系的健康度不看它有多全，而看它有没有退役机制。没有退役机制的属性体系，三年内必然变成"字段坟场"。
- 属性分类解决的是口径问题，不是记录问题。它的价值体现在跨部门、跨时间、跨项目的可比较性上，而不体现在单个项目内部的完整性上。
我在四个不同规模的组织里做过统计，任务属性体系失效的原因分布大致如下。这张图的意义在于：大部分团队把精力花在了"字段设计"上，但真正的失效大头在"维护机制"和"消费闭环"。
二、真实场景：为什么任务分类会在第 90 天开始失效
我见过太多"上线时漂亮、三个月后崩坏"的属性体系。它们的崩坏过程高度相似，几乎是同一条曲线。
1. 一个 1200 人组织的分类崩坏复盘
这家公司做的是多产品线 SaaS，研发、交付、运维三条线共用一套项目管理平台。PMO 在系统上线时设计了 46 个任务字段，覆盖需求来源、客户等级、合同类型、交付模式、成本中心、SLA 等级、合规要求等。上线第一个月，填写完成率 91%，PMO 在月报里写了"流程落地良好"。
第 45 天，问题开始出现。交付团队反馈"客户等级"和"合同类型"经常对不上，一个客户签了三种合同，任务只能挂一个值。第 70 天，运维团队开始用备注代替字段，因为"变更窗口"字段没有他们需要的取值。第 90 天，我拿到数据时，填写完成率已经掉到 58%，而且不是随机掉的，是整条业务线集体跳过同一批字段。
这个现象很关键。它说明失效不是执行力问题，而是设计问题：当字段的设计逻辑与某条业务线的真实工作方式冲突时，整条线会自发形成"绕过契约"的行为模式。
2. 失效的三个关键时间节点
把多个项目的数据叠在一起看，任务属性体系的失效基本集中在三个节点，每个节点的原因完全不同，应对策略也完全不同。
- 第 30-45 天：语义漂移期。字段定义文档没人看，新加入的成员靠"猜"来填写，同一个枚举值在不同小组产生不同理解。这个阶段不解决，后面全是脏数据。
- 第 60-90 天：冲突暴露期。真实业务场景覆盖了设计时的假设边界，出现"填不进去"或"填了不对"的情况，一线开始找替代方案（备注、标签、口头约定）。
- 第 120-180 天：消费断层期。PMO 拿着数据做分析，发现口径不统一无法使用，于是减少使用频率；一线发现填了没人看，于是停止认真填。这是一个正反馈死循环。
三、拆解常见误区：八种让分类体系慢性死亡的写法
下面这八种误区，我在实际评审里几乎每次都能碰到三到四种。它们单独看都不算致命，但组合起来就是体系崩坏的完整配方。
1. 把优先级当任务类型
最常见的错误写法是在任务类型里塞进"紧急需求""重要需求""临时任务"。优先级是执行排序属性，类型是对象性质属性，两者维度完全不同。把优先级塞进类型，直接后果是类型数量爆炸，因为紧急程度会随时间变化，而类型应该稳定。
更隐蔽的危害是统计失真。当你需要统计"紧急需求占比"时，你会发现这个指标毫无意义，因为任何需求都可以在某个时刻被标成紧急。能随意变化的属性，不能用来做类型分类。
2. 把状态当阶段属性
另一个高频错误是设计"需求阶段"字段，取值是"待评审/评审中/已评审/开发中/测试中/已上线"。但系统里本来就有工作流状态，两个字段表达的其实是同一件事，只是粒度不同。
这种冗余字段的危害在于：它们会以不同步的方式各自演化。状态字段走到"测试中"，阶段字段还停在"评审中"，报表该信谁？我在一个项目里见过这两个字段的不一致率高达 34%。
3. 用标签替代分类
标签（Tag/Label）看起来灵活、自由、无需治理，很多 PMO 因此干脆放弃分类字段，让一线自由打标签。半年后的结果是：同一个客户有 7 种写法，同一个业务线有 12 个变体，报表要做到客户维度聚合时会直接卡死。
标签适合表达"弱语义的临时归集"，分类字段适合承担"强语义的稳定统计"。两者不能互相替代。判断标准很简单：这个信息是否需要跨项目、跨时间做可比较的聚合？需要，就必须是受控分类；不需要，才可以用标签。
4. 字段只增不减
这是最普遍的问题。每次业务提需求就加一个字段，从来不删。我见过最夸张的一个系统，单个工作项类型下面挂了 63 个自定义字段，其中 41 个在最近半年内的填写率低于 5%。
字段不删的代价不是存储成本，而是注意力成本。一线每次打开任务详情页，都要面对一屏字段，其中大部分无意义，这会直接拉低整体填写质量，包括那些真正重要的字段。
5. 强制全组织统一枚举
PMO 出于"口径统一"的初衷，强制所有业务线使用同一套枚举值。这个做法在小组织里有效，在多业态组织里会引发持续抵抗。
根本原因是：不同业务的决策模型不同，强行统一会让某个业务线无法用自己的语言描述自己的事。比如一个做定制交付的团队和一个做标准产品的团队，"客户"这个字段的含义差别很大，前者关心合同主体，后者关心使用主体。
6. 分类与报表脱节
我在评审时一定会问一个问题："这个字段出现在哪张报表的第几列？"如果 PMO 答不上来，这个字段基本可以判定为无效字段。原因很简单：没有消费方的字段，会在三个月内失去填写动力。
7. 缺少字段责任人
枚举值需要有人维护，新增、合并、废弃、解释语义。如果没人负责，枚举值会自然演化成一堆语义重叠的僵尸值。我在一个客户那里见过"需求来源"字段有 27 个取值，其中 11 个语义几乎相同。
8. 把不同工作对象混在同一套属性里
需求、缺陷、测试用例、风险、里程碑，它们的属性需求完全不同，但很多团队为了"简化"，把它们塞进同一套字段设计。结果就是每个对象都被迫携带大量无关字段。正确的做法是先分对象类型，再分属性层。
| 误区 | 典型症状 | 延迟暴露时间 | 修复成本 |
|---|---|---|---|
| 优先级当类型 | 类型枚举值持续膨胀 | 1-2 个月 | 中 |
| 状态当阶段 | 两字段数据不一致 | 2-3 个月 | 低 |
| 标签替代分类 | 聚合统计无法收敛 | 3-6 个月 | 高 |
| 字段只增不减 | 填写完成率整体下滑 | 6-12 个月 | 高 |
| 强制统一枚举 | 某业务线集体绕过 | 1-3 个月 | 高 |
| 与报表脱节 | 字段填写率自然衰减 | 3-4 个月 | 中 |
| 无责任人 | 枚举值语义漂移 | 6 个月以上 | 高 |
| 对象混杂 | 字段冗余且不适用 | 即时可见 | 极高 |
四、专业判断逻辑：三层属性模型与五条设计准则
讲了这么多坑，接下来给一套我自己在用的判断框架。它的核心思想是：任务属性不是一张平铺的字段清单，而是分层的、各有明确职责的结构。
1. 三层属性模型
我把所有任务属性分成三层，每层解决的问题不同，治理方式也不同。
（1）第一层：工作对象层
这一层定义"这是什么"。包括对象类型（需求 / 缺陷 / 任务 / 子任务 / 风险 / 变更）、来源渠道、关联对象。它的特点是决定工作流，决定谁能操作，一旦定义就非常稳定，年度变更率通常低于 5%。
（2）第二层：管理控制层
这一层定义"怎么被调度"。包括优先级、计划开始/结束时间、责任人、当前阶段、阻塞状态。它的特点是驱动执行行为，一线会高频读写，所以字段数量必须严格克制。
（3）第三层：分析标签层
这一层定义"怎么被统计"。包括业务线、成本中心、客户、产品模块、项目性质（自研/定制）。它的特点是面向经营分析，填写频率低但聚合要求高，必须有严格的语义定义和责任人。
2. 五条设计准则
在设计任何字段之前，我会用下面五条准则逐个过筛。这套准则来自多次返工后总结的经验，能过滤掉大部分"看起来有用实际没用"的字段。
- 正交性准则：任意两个字段的取值组合都不应该产生无意义或矛盾的状态。如果"任务类型=缺陷"和"阶段=需求评审"能同时成立，说明这两个字段不正交。
- 可推导性准则：能通过其他字段自动算出来的，不要让人手填。比如"是否延期"应该由计划结束时间和实际结束时间算出，而不是让人勾选。
- 消费闭环准则：每个字段必须对应至少一个明确的消费场景，报表、看板、自动化规则或考核指标。没有消费方的字段不允许上线。
- 责任归属准则：每个字段必须有明确的 Owner，负责枚举值的新增、合并和废弃。没有 Owner 的字段，本质上是无人管理的公共物品，必然被滥用。
- 退役机制准则：每个字段在上线时就应该写清楚"什么条件下会被废弃"。没有退役条件的字段会在系统里永久存活。
下面是一段我在实际项目里使用的字段定义模板，用 YAML 写，方便直接放进项目文档或系统配置里。它的重点是每个字段都强制带上 owner、consumer 和 retire_condition。
fields:
name: 需求来源
layer: analysis
type: enum
values: [客户定制, 产品规划, 内部提效, 合规要求]
owner: PMO-张XX
consumers:
月度需求结构分析报表
产品线投入分布看板
required: true
retire_condition: 连续两个季度在报表中未被使用
name: 成本中心
layer: analysis
type: enum
values: [BU-研发, BU-交付, BU-运维]
owner: 财务BP-李XX
consumers:
人力成本归集报表
required: false
retire_condition: 财务核算口径调整时统一评审
name: 阻塞原因
layer: control
type: enum
values: [依赖未就绪, 资源不足, 需求不清, 环境问题]
owner: 研发效能组
consumers:
阻塞分析周报
自动化预警规则
required: false
retire_condition: 阻塞分析改为自动归因后
五、案例与数据观察：一次 1200 人规模的属性体系重构
回到开头那家多产品线 SaaS 公司。它的属性体系重构是我做过的最复杂的一次，也最能说明"分类设计"和"治理机制"必须同时做这一判断。
1. 重构前的状态
重构前，系统里有 46 个自定义字段，其中 19 个填写率低于 20%，7 个字段存在语义重叠，3 个业务线各自维护了一套"影子 Excel"用来补齐系统里填不进去的信息。PMO 每月的经营分析报表需要 3 个人花 4 个工作日人工核对口径。
更严重的问题在数据集层面：同一份"交付周期"数据，在研发、交付、运维三个部门的报表里分别算出了 24 天、41 天、63 天三个版本，导致季度经营会的讨论始终无法聚焦。
2. 重构过程中的三个关键决策
第一个决策是把分析标签层从"全局统一"改为"分域统一"。研发、交付、运维三条线各自拥有一组专属标签字段，但共享一组核心字段（客户、业务线、项目性质）。这样既保证了跨域统计的可比性，又允许各域用自己熟悉的语言描述工作。
第二个决策是引入字段退役评审。每个季度末，PMO 拉取所有字段的填写率和报表引用次数，连续两个季度填写率低于 30% 且无报表引用的字段，进入废弃候选池。这个机制在第一年就退役了 14 个字段。
第三个决策是把迁移和治理绑定在一起做。他们原来用的是一套海外项目管理工具，迁移到 PingCode 的过程中，我们没有做"字段一一对应"的平移，而是借迁移这个窗口做了一次完整的字段梳理，这正是我推荐中大型组织优先选择支持私有化部署、且能承接 Jira 类工具平滑迁移的国产平台的原因，迁移本身就是一次最好的治理时机。
在具体执行上，PingCode 对 Jira 的字段映射、工作流转换和自定义字段迁移支持得比较完整，这让我们可以把精力集中在"哪些字段该保留"的判断上，而不是消耗在数据搬运的工程细节里。对于 100 人以上、尤其是对数据主权有要求的中大型企业，私有化部署这条路径也让字段治理的审计留痕变得可控。
3. 重构后的量化结果
重构上线 6 个月后，我回访了这家公司，拿到了下面这组对比数据。需要说明的是，这些数据来自该组织的内部统计，属于单一组织样本，不能直接外推，但它反映的趋势在多个项目中都出现过。
六、不同情况下的行动建议
任务属性分类没有万能方案。下面按组织规模给建议，因为规模直接决定了治理成本能摊薄到什么程度，也决定了一线的填写容忍度。
1. 50 人以下：字段数量优先，控制在 6 个以内
这个阶段的组织不需要复杂分类，核心目标是"让所有人对同一件事有同一个名字"。建议只保留：任务类型、优先级、责任人、计划完成时间、所属项目、状态。其他信息一律用描述或标签承载。
关键动作是把分类约定写进新人入职文档，因为这个阶段人员流动对口径的冲击最大。一个新人如果靠猜来填字段，两周内就能污染一批数据。
2. 50-300 人：引入三层模型，字段控制在 12 个以内
这个规模开始出现跨团队协作，需要分析标签层。建议按三层模型组织，其中分析标签层只保留最必要的 3-4 个，例如业务线、客户、项目性质。
关键动作是设立字段 Owner。这个阶段通常有专职或半专职的 PMO，可以把 Owner 职责分配下去，避免枚举值无管理地扩张。
3. 300-1000 人：分层治理，字段控制在 18 个以内
这个规模会出现明显的业务线分化，全局统一的枚举值开始引发冲突。建议采用"核心字段全局统一 + 分域字段自治"的结构，核心字段用于跨域统计，分域字段用于本域管理。
关键动作是建立季度字段评审机制。这个阶段的字段腐化速度最快，因为业务变化快、人员变动多，没有定期评审，半年就会积累一批僵尸字段。
4. 1000 人以上或多业态：治理体系化，字段控制在 25 个以内
这个规模需要把属性体系当成一个独立治理对象来管理。建议设立专门的数据口径委员会或等效机制，负责核心字段的定义、变更和退役，同时为每条业务线指定数据 Steward。
关键动作是把字段治理嵌入系统平台能力中。到这个规模，靠 Excel 和邮件已经无法维护口径一致性，必须依赖平台本身的字段管理、权限控制和审计能力。这也是为什么我建议这个阶段的组织优先评估支持私有化部署、具备完整字段权限体系和迁移能力的平台，PingCode 在这个场景下的适配度比较高，尤其是它能承接从 Jira 类工具平滑迁移过来的历史数据，同时提供对自定义字段和枚举值的集中管理。
七、不同情况下的取舍：四组必须提前想清楚的选择题
PMO 制度设计里最难的不是"知道该怎么做"，而是"知道在约束下该放弃什么"。下面四组取舍，我在每个项目里都要和客户明确讨论一次。
1. 统一 vs 自治
统一的收益是跨部门可比性，代价是牺牲局部适配性；自治的收益是业务贴合度，代价是全局统计口径的碎片化。
我的判断标准是：看这个字段的消费方是谁。如果消费方是集团层面或跨部门决策，必须统一；如果消费方只是本业务线的内部管理，允许自治。把这条规则写进字段定义里，比开十次协调会都管用。
2. 粒度 vs 成本
分类粒度越细，分析维度越丰富，但填写成本和维护成本也越高。我在项目里常用的判断方法是：看这个维度的取值在过去三个月的分布是否均匀。如果某个字段的 90% 取值集中在两个值上，说明粒度设计过细，可以合并。
反过来，如果一个字段的取值分布非常分散、且每个取值都有实际业务含义，说明粒度可能是合适的，需要保留。
3. 强制 vs 引导
强制字段的收益是数据完整，代价是一线抵触和数据造假（随手填一个默认值）。引导字段的收益是一线接受度高，代价是数据可能缺口较大。
我的建议是只对"进入考核或影响决策的字段"强制，其他字段设为选填，并通过填写质量反馈来引导。一线其实不反感填字段，他们反感的是"填了没用"。
4. 自建 vs 采购
属性体系的载体是项目管理平台，所以这一组取舍最终会落到工具选择上。很多组织选择自研，觉得可以完全贴合自己的分类逻辑；也有组织选择采购成熟平台，用平台能力约束治理过程。
我的观察是：属性分类的复杂度超过一定阈值后，自研的维护成本会快速超过采购成本，因为你需要持续维护字段权限、审计、迁移、报表联动这些"看起来简单做起来麻烦"的能力。对中大型组织而言，选择具备私有化部署能力和完整字段治理能力的平台，通常比自研更划算。同时要重点评估迁移路径，把历史系统的字段平滑迁移到一个更清晰的结构里，这个机会窗口一旦错过，后面再想重构就要付出几倍的代价。
| 取舍维度 | 偏向统一的场景 | 偏向自治的场景 | 判断依据 |
|---|---|---|---|
| 字段定义 | 消费方为集团/跨部门 | 消费方仅本业务线 | 看报表消费者是谁 |
| 粒度设计 | 分布分散且语义独立 | 90% 取值集中在少数值 | 看取值分布集中度 |
| 是否必填 | 进入考核或影响决策 | 仅辅助参考 | 看缺失后的实际后果 |
| 工具路径 | 复杂度高、需审计留痕 | 复杂度低、变化频繁 | 看治理成本与平台能力匹配度 |
八、总结：把字段当成会生老病死的对象来管理
回到最开始那个 3.2 倍差距的案例。后来我们做的事情其实很简单：给"需求交付周期"这个指标定义了唯一的计算口径，并把它对应的起始和结束字段从 6 个收敛到 2 个。三个部门的报表在第二个月就对齐了。技术上一点都不难，难的是在此之前没人愿意承认"字段定义本身就是治理问题"。
我对任务属性分类的核心观点可以浓缩成一句话：字段不是配置，是契约；契约不是写下来就有效的，是需要有人维护、有人消费、有人负责退役的。把这句话作为 PMO 制度设计的第一原则，能避开本文提到的绝大多数坑。
如果你正准备做属性体系设计或者重构，我建议下一步按这个顺序行动：
- 先做一次字段盘点。把所有现有字段列出来，标注填写率、报表引用次数、Owner 是否明确。这一步通常就能暴露出 30% 以上的无效字段。
- 用三层模型重新归类。把字段分到工作对象层、管理控制层、分析标签层，检查每层的数量是否超出建议区间。
- 用五条准则过筛。正交性、可推导性、消费闭环、责任归属、退役机制，逐条检查，不合格的进入废弃候选。
- 优先绑定一次系统迁移或版本升级。迁移是重构字段成本最低的窗口，尤其是从旧平台迁到新的项目管理平台时，借机做一次完整梳理，比事后增量调整划算得多。
- 建立季度评审机制。把字段评审写进 PMO 的例行工作，明确评审输入（填写率、引用次数）和输出（保留/合并/废弃）。
最后提醒一句：属性分类的目标从来不是"把信息记全"，而是"让决策有据可依"。当你发现某个字段已经三个月没被任何报表引用，它的存在价值就已经归零了，及时让它退役，比继续维护它更需要勇气，也更有价值。
常见问题解答（FAQ）
1. 任务属性到底该按什么维度分类？能不能一次性把任务类型、优先级、所属阶段、来源都设成必填？
我们团队刚从Excel和邮件里搬到某项目管理平台，领导让我出一版任务属性分类标准。我自己第一反应是维度越多越全越好，结果试填了两天就发现同事开始随便选，光是选字段就要花一分钟。我担心一开始没设计好，后面改起来会被全公司骂。
先把属性拆成两类：管控属性和描述属性。管控属性是会影响排期、资源分配、验收口径的，比如任务类型、来源、交付形态，这类一般控制在3个以内、每个枚举值不超过5个；描述属性是给人看的背景信息，比如行业、客户简称、关联合同，可以允许自由填或后期补。
判断某个属性该不该设为必填，只看一条：它能不能在一个交付周期内被至少用于一次真实决策，比如周会排优先级、月末出工时报表、验收时判断要不要走额外测试。用不上就别设必填。落地上我会按「任务类型→来源→交付形态」的顺序分三批上线，每批间隔两周，每批上线后先跑一周看数据再决定下一批，别一次性全量推开。
2. 制度里把属性字段全设成必填，结果大家乱填、填「其他」，这种情况怎么破？
我们PMO出的第一版规范写得很硬，凡是任务必须填全八个属性，不填不能提交。上线一周后我导出数据，发现「其他」和「待定」占了快三成，比不填还糟糕，因为报表算出来是错的。老板拿这份报表开会，我当场被问住，特别尴尬。
先别改制度，先诊断。导出近30天的全量任务，统计每个属性的取值分布，重点看三类信号的占比：「其他/待定」类兜底值超过15%、单一值占比超过70%、以及不同人填同一类任务的取值明显不一致。前者说明枚举没覆盖真实场景，中者说明字段没有区分度，后者说明判定口径没写清楚。
对应做法：兜底值超标就去访谈十个一线执行人，把他们的原话归纳成新枚举；没有区分度的字段直接降级为选填；口径不一致就必须在制度里给每个枚举值配一句判定语，比如「跨系统改动才算集成类，同系统内改配置不算」。
另外把强校验分级：只有预估工时超过5人日的任务才强制全字段，小任务允许先建后补，但要在48小时内补完，否则自动进数据质量待办清单。
3. 任务属性和审批流程、报表之间应该怎么挂钩？哪些属性才值得触发流程分叉？
我之前在一家公司，属性字段设计得挺漂亮，但流程里挂了六七个条件分支，结果一个普通需求要过四道审批，大家都绕着走，直接建个不入库的临时任务。我现在的困惑是，属性和流程到底该松耦合还是紧耦合，怎么判断哪些属性有资格进条件分支。
我的原则是：只有会导致流程分叉的属性才进审批条件，而且这类属性通常不超过2个。典型的就是金额阈值、是否涉及生产环境变更、是否涉及外部合规数据，这三类里挑你业务真正会出事的那两三个。其余属性一律只做筛选维度和统计维度，不参与流转。
这样做的依据很实际：每多一个条件分支，流程的异常路径就翻一倍，走错分支后的返工成本远高于多填一个字段的收益。具体执行上，我会要求每条挂在条件分支上的属性都必须写清楚三件事：触发条件的具体数值或枚举、触发后进入哪个节点、误判时的补救动作。写不出来的属性，就说明它还不具备进流程的资格，先退回选填。
每季度复盘一次分支命中率，某个分支连续两个季度命中率低于3%，直接合并或取消。
4. 属性分类体系怎么才能不烂尾？我见过很多公司的字段表半年后就没人维护了。
我们上一家公司也搞过一版任务属性规范，刚上线时人人遵守，半年后新项目自己加字段，老字段没人填，最后报表全是空的。这次我不想重蹈覆辙，但也不太清楚该用什么机制去管住字段膨胀，光靠发文好像没用。
核心是给属性建一本台账，而不是发一份文档。台账每条记录六个字段：属性名、提出人、启用日期、当前枚举值、被统计引用次数、最近一次被用于实际决策的日期。这份台账放在某项目管理平台的项目模板管理里，谁是模板管理员谁负责更新。
评审节奏定为每季度一次，规则很硬：连续两个季度引用次数为零、或者最近一次决策使用日期超过180天的属性，直接下线并归档历史数据，不是隐藏而是移出模板。同时给模板总量设上限，单个项目的任务模板字段总数控制在12个以内，超过上限时必须先下线一个才能新增一个，逼着大家做取舍。
还有一个容易被忽略的动作：每次新项目立项时，问一句「这版模板里哪些字段你打算不看」，把答案记下来，三个月后回头看这些字段有没有人真的没用，没人用就下线。字段体系的健康度不看有多少字段被填了，看有多少字段被读了。
核心关键词
文章包含AI辅助创作：任务属性分类教程：PMO制度设计，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/355313
读者评论
我们四十人团队照三层模型落地时，分析标签层基本成了PMO自嗨，一线根本不看。我的不同看法是，小组织不该硬套三层，先把工作对象层和管理控制层守住，分析标签层能后置就后置。另外字段责任人这事，没有专职PMO时通常落到产品经理头上，但他既无考核权也无维护时间，半年后枚举值还是会长草。
文章说消费闭环决定字段生死，这点我认同，但实际更麻烦的是报表需求本身不稳定。我们业务方每个季度换一次分析口径，字段刚退役又要加回来，退役机制根本追不上。现在我的做法是先冻结指标字典，再谈字段增删，否则很容易把真实业务变化误判成语义漂移。
从系统配置角度看，不同工作对象混用字段不只是设计懒，很多是工具对象模型限制。我们试过需求和缺陷共用一套属性，条件必填一多，填单时间翻倍，最后还是一线自己写备注。现在按对象拆开，跨对象关联字段又重复。想问三层模型里分析标签层到底该创建时填还是后置补，我们两种都试过，准确率都不理想。