任务属性分类教程：项目经理数据分析，避坑指南

去年我帮一个约80人规模的研发组织做迭代复盘，遇到一件很荒唐的事：他们平台上"迭代准时率"的报表连续三个季度都在92%以上，但业务方每个月都在投诉交付延期。查了两周之后，问题既不在执行力，也不在排期能力，而是在最底层的一件小事上，他们的"任务类型"字段里躺着17个枚举值，其中"优化"和"技术债"在不同团队里的定义几乎是相反的。同一个字段，A团队填的是"计划外的临时改动"，B团队填的是"有明确需求的架构改进"，于是所有按时完成率、需求吞吐量、人均产能，全部建立在一个语义漂移的沙地上。

这就是我想写这篇任务属性分类教程的原因。项目经理做数据分析，真正的门槛从来不是会不会写透视表、会不会拉仪表盘，而是你手上的任务，属性字段到底能不能被稳定地、跨人跨周期地填成同一个值。这篇文章我会把属性分类这件事拆到你能直接落地的程度：先给核心结论，再拆六个高频误区，然后给一套我自己在多个团队反复用过的判断逻辑，最后用中大型组织的真实场景和数据观察说明怎么取舍。

如果你正准备重构任务字段、或者正被一堆互相矛盾的报表折磨，这篇值得从头看到尾。

一、核心结论：任务属性分类，本质是一份数据口径契约

先把结论放在最前面，因为它决定了后面所有细节的判断标准。任务属性分类不是"打标签"，而是团队对"一件事该如何被记录"达成的口径契约。契约的特征是：任何人、任何时间、任何项目下填出来的值，含义是一致的、可比较的、可累加的。

我在实践中总结出一条很粗暴但非常好用的准入判据：如果一个属性，两个不同的填表人在互不沟通的情况下，对同一个任务有80%以上的概率填出相同的值，它才是可分析属性；否则它只是一个备注。这条判据听起来简单，但它能一次性筛掉大量看上去很专业的字段设计。

1. 先定义"可分析的任务"，再定义字段

绝大多数团队的顺序是反的：先打开工具，看到有"类型""优先级""模块"这些现成字段，于是照着填。正确的顺序应该是先回答一个问题，我未来要用这批数据回答哪三类问题：产出问题（做了多少）、效率问题（做得多快）、质量问题（做得多好）。

这三类问题对应三种完全不同的属性结构。产出类问题需要"可计数"的属性，比如任务类型、模块、交付物形态；效率类问题需要"可比较"的属性，比如故事点、预估工时、流转节点时间；质量问题需要"可归因"的属性，比如缺陷来源、严重程度、逃逸阶段。如果你把这三类混在一套自由填写的字段里，报表迟早会互相打架。

2. 属性分类错误会同时污染三类指标

我见过最典型的连锁反应是这样的：任务类型定义模糊 → 技术债被大量归类成"需求" → 需求吞吐量虚高 → 人均产能被高估 → 管理者据此提高排期强度 → 实际交付延期进一步恶化。起点只是一个字段的枚举值没人管，终点是整个组织的排期节奏失控。

所以判断一个团队的属性分类是否健康，我通常只看一个指标：同一个季度内，"其他"或"未分类"这类兜底值的占比。如果它长期高于5%，说明分类体系没有覆盖真实工作；如果它低于1%但字段有17个枚举值，说明分类过细，填表人正在被迫做无效选择。

3. 一条经验法则：属性数量与团队规模非线性相关

很多人以为团队越大、字段越多。我的观察恰恰相反：20人以下的团队适合5~7个受控属性，100人以上的组织反而应该把核心必需属性压缩到6~8个，其余全部下沉为模块级可选字段。原因是规模越大，填表人的上下文差异越大，字段越多、共识越薄、脏数据越多。

后面的章节我会反复回到这个判断：属性分类的难点不是设计得全，而是设计得"窄"且"硬"。

二、背景和真实场景：任务属性从"给人看"到"给系统算"

要理解为什么现在属性分类这么容易出问题，得先看清这十年任务管理工具的使用方式发生了什么变化。我把这段变化总结成三个阶段，我自己经历的团队基本都走过一遍。

1. 三个阶段：看板时代、流程时代、分析时代

第一阶段是看板时代。任务属性主要是"卡片的装饰"，用来让人一眼认出这是谁的活、做到哪了。字段少，靠人脑兼容，不会出大问题。

第二阶段是流程时代。工具开始承载工作流，状态机、流转规则、审批节点被固化进系统。这时候属性开始参与"控制"，状态决定能不能流转，类型决定走哪条审批链。属性错了，流程就走歪。

第三阶段是分析时代，也就是现在。管理层不再只看"这个迭代做完没有"，而是要回答"我们的人效在同行业中处于什么位置""技术债占比是否在恶化""需求交付周期为什么拉长了"。这时候属性从"控制变量"变成了"统计变量"，它对准确性的要求陡然上升了一个量级。

2. 一个真实的双周迭代现场

我拿一个我深度参与过的团队举例。这是一个约120人的研发组织，分5个特性团队，双周迭代。他们最早的任务属性是：类型、优先级、负责人、迭代、状态、模块、预估工时。看起来挺标准。

他们想做一次"交付效率诊断"，结果发现三个数据互相矛盾：迭代准时率92%，但需求平均交付周期从18天涨到31天；人均完成故事点环比上升12%，但线上缺陷数环比上升40%。

排查过程其实就是一次属性分类审计。我们发现：

• "需求"这个类型下，有大约23%的任务其实是运维工单，因为它们也需要改代码，团队就顺手建成了需求。
• "预估工时"字段在5个团队里有3种填法：有的填人天、有的填小时、有的填"我大概要花几天"。单位不统一，加起来没有任何意义。
• 线上缺陷的"严重程度"由发现人自评，测试同学和研发同学对"严重"的标准差了整整一级。

这三条加起来，足以让任何效率报表失去意义。注意，这不是执行力问题，是属性定义问题。团队里没有一个人是偷懒的，他们只是不知道别人怎么填。

3. 属性从"给人看"到"给系统算"，中间缺了一层字典

我后来形成了一个很明确的判断：团队真正缺的不是字段，而是一份"属性字典"。字典要写清楚每个属性的名称、适用范围、取值集合、每个取值的判定标准、谁有权修改、变更后如何回填历史数据。

绝大多数团队的属性管理停留在"工具里有个下拉框"这个层面，缺少字典这一层，就等于把口径共识寄托在每个人的默契上。人一多，默契必然崩。

三、拆解六个高频误区

接下来这部分是我最想让你认真看的部分。下面六个误区我在不同团队反复见过，而且它们的破坏性往往是延迟显现的，刚上线时一切正常，两三个季度后才开始污染报表。

1. 误区一：把"任务类型"当成"工作流状态"

这是最普遍、也最致命的一个。任务是"需求"还是"缺陷"，这是类型属性，描述的是这件事的本质；任务是"待开发""开发中""待验收"，这是状态属性，描述的是它在流程里的位置。两者必须彻底分开。

为什么危险？因为一旦混用，你就无法回答"缺陷从创建到关闭平均需要多少天"这类问题。状态会被类型覆盖，类型又会被状态污染。我见过有团队的类型列表里同时存在"需求""开发中""待测试""已上线"，这直接导致任何按类型做的统计都是错的。

（1）判断方法

问自己一个问题：这个属性会不会随着时间自然变化？会变化的（待开发→开发中→已关闭）是状态；不变化的（这是需求还是缺陷，一旦确定就不该改）是类型。如果某属性既会变又描述本质，说明你把它拆成两个字段才能用。

（2）一个可执行的清理规则

把类型字段的所有枚举值列出来，凡是能在工作流状态里找到对应词的，一律删除或改名为中性类型。这个过程会有点痛，但一次清理能救回后面两年的数据可信度。

2. 误区二：优先级和严重程度混用

优先级回答"我什么时候做"，严重程度回答"这件事有多坏"。这两个维度在理想情况下应该交叉使用，形成决策矩阵。现实里很多团队只保留一个字段，于是"紧急"既表示业务重要，也表示线上挂了。

后果是：你无法分析"高严重程度但低优先级的缺陷"这类关键问题，而这类问题恰恰是技术债积累的主要来源。我的建议是两个字段都必须存在，且各自只回答自己的问题。严重程度通常由发现方给初始值，优先级由排期方确认，两者权限分开。

3. 误区三：用自由标签替代受控枚举

标签很灵活，但灵活是它的优点，也是它的毒。我做过一次统计：某团队在一年内累积了约340个标签，其中被使用超过20次的只有28个，剩下312个标签平均使用不到1.5次，而且存在大量同义变体，比如"性能优化""性能提升""perf优化""性能问题"。

这种结构下，任何按标签做的聚合都会失真。我的处理原则是：标签只用于临时性、探索性的横切关注点；一旦某个标签在一个季度内被使用超过10次，就必须升级为受控枚举字段。这条规则很好用，因为它让分类体系随实际使用自然生长，而不是靠前期拍脑袋设计。

4. 误区四：多值属性造成重复计数

一个任务关联多个模块、多个业务线，这很正常。但如果模块字段可以多选，你做"各模块工作量分布"时就会出现总量超过100%的情况，而且没人一开始会注意到。

处理方式有两种：要么在统计时明确采用"主模块"单一字段做分布分析，多值字段只做筛选；要么在每个任务上强制标注一个主责模块。我倾向于后者，因为分析师不应该在每次做报表时都要重新解释分母。

5. 误区五：属性只在创建时填，没有变更审计

任务属性的值不是一成不变的：优先级会调整，模块归属会因为重构而改变，故事点会在澄清后修正。如果这些变更不留下记录，你就无法回答"为什么这个迭代的计划突然变了"。

我把这个能力称为属性变更审计。它不需要很复杂，至少要能查到某个字段在某天被谁从什么改成了什么。在成熟度较高的项目管理系统里，这通常是内置能力；如果工具不支持，就要在流程上做补偿，比如要求重大属性变更必须在任务评论里说明理由。

6. 误区六：故事点和工时混用同一套分析口径

故事点是相对规模单位，用于团队内部估算；工时是绝对时间单位，用于排期和成本核算。两者都可以用，但不能混着用在同一张图里。

我经常看到"人均产能"这类指标同时被两个口径计算，然后管理层拿两个数字互相印证，结果发现对不上，就开始怀疑数据。实际上问题在于：跨团队的故事点本质上是不可比的，你把A团队的8点当成B团队的8点，等于假设两个团队的估算标尺完全相同，这个假设在现实中几乎不成立。跨团队比较要么用交付周期这类客观时间指标，要么用统一拆解后的任务数量，不要用故事点。

四、专业判断逻辑：四层属性模型与三条准入判据

讲完误区，我把自己的方法论完整讲一遍。这套逻辑我在不同规模、不同行业的团队里都用过，核心是"先分类属性角色，再决定属性能不能进系统"。

1. 三条准入判据

任何属性要进入系统的必填字段集合，必须同时满足三条。

1. 可枚举且互斥：取值集合有限，且任意两个取值不会同时成立。如果一个任务既能被归为"A"又能被归为"B"，说明分类维度设计错了，需要拆成两个维度或增加判定优先级。
2. 可稳定归属：不同人独立判定，结论一致率在80%以上。达不到，就要在字典里补判定示例，或者干脆放弃这个属性。
3. 可跨周期比较：今天填的值和半年前填的值含义相同。这要求属性字典有版本管理，变更时明确回填策略。

第三条最容易被忽略。我见过团队把"模块"从按技术分层改成按业务域分层，但历史数据没有映射，导致趋势图出现断崖。这不是数据错误，是口径断裂。

2. 四层属性模型

我把任务属性按功能分成四层，每层解决的问题完全不同。这套分层是我判断"某个字段该不该存在"的主要工具。

这个表格最有用的地方在于：识别层和流程层的字段必须严格控制数量，归因层的字段可以相对灵活。因为前两层是所有分析的基础维度，一旦不稳定，全部数据都不可信；归因层主要用于事后分析，允许有更多上下文表达空间。

3. 用问题反推字段，而不是用字段凑问题

这是我最常用的一个操作技巧。做法很简单：把管理层未来两个季度可能要问的10个问题写下来，然后逐个反推需要哪些字段支撑。写不出字段的问题，就不是当前阶段的数据需求。

比如"为什么这个迭代的质量下降了"这个问题，反推需要：缺陷严重程度分布、缺陷来源（本迭代引入 vs 历史遗留）、逃逸阶段（测试发现 vs 线上发现）、关联模块。如果这四类字段缺失，这个问题就没法用数据回答，只能靠回忆。

反推的好处是它会自动帮你做减法。你很快会发现，很多原本想加的字段根本没人问对应的问题。

4. 属性字典要版本化，而不是改完就忘

我的建议是把属性字典当成一份有版本号的文档来管。每次变更记录三件事：变更内容、生效时间、历史数据的处理方式（回填、冻结、还是双写）。

这三件事里，历史数据处理方式是最容易被跳过、后果也最严重的。因为趋势分析依赖跨期可比，一旦口径变更没有对齐，你会看到一条假的"下降曲线"，然后基于它做出错误的资源决策。

5. 一个可以直接抄的字段定义结构

如果团队刚开始做属性治理，可以直接用下面这个结构来描述每个属性。它足够简单，又能覆盖判定争议时需要的全部信息。

属性名称: 任务类型
所属层级: 识别层

是否必填: 是

取值范围:

需求 # 有明确业务方，需交付可见功能价值

缺陷 # 已发布内容的错误行为或体验问题

技术改进 # 不直接产生业务价值，但改善可维护性/性能/稳定性

调研 # 产出为结论或方案，不产出可上线代码

判定规则:

若任务由外部业务方提出且包含验收标准 -> 需求
若任务描述的是已上线功能的错误行为 -> 缺陷
若任务目标是改善内部工程质量且无业务验收方 -> 技术改进
其余情况需在评审会上明确归类，禁止使用兜底值
禁止取值: 开发中 / 待测试 / 已上线（这些属于流程层状态）

变更权限: 项目经理与产品负责人共同确认

变更记录: 每次修改需登记日期、原因、历史数据回填方式

注意最后那行"禁止取值"。把禁止项写进字典，比只写允许项更能防止误用，因为大多数人出错的路径不是不知道正确答案，而是顺手选了那个看起来也对的值。

五、具体案例与数据观察：中大型组织怎么落地

下面这部分是我在服务中大型研发组织时积累的观察，主要围绕工具侧的落地。这里我以 PingCode 为例说明，因为它主要服务中大型企业及100人以上组织，在属性治理这个场景上有比较完整的支撑能力，而且支持私有化部署，对数据合规要求高的组织更合适。

1. 场景背景：一次约200人组织的属性标准化

这个组织有7个研发团队、2条产品线，之前用的是自研的一套轻量任务系统，属性字段由各团队自行添加，累积了约60个自定义字段，其中约40个字段只有一个团队在用。

他们最大的痛点是跨团队汇总。每个月做研发效能报告时，数据同学要花大约3个人天做字段对齐，而且每次结果都不一样。

改造分了三步。第一步，把60个字段按四层模型归位，识别层只保留4个必填字段（任务类型、所属模块、来源、主责产品线）。第二步，把度量层字段拆成"团队内可见"和"跨团队可比"两组，跨团队报告只使用后者。第三步，为每个保留字段写判定规则和反例示例。

整个过程大约用了6周，其中前2周是争议最大的阶段，每个团队都觉得自己的字段不能被砍。这一步的推进技巧是：不做价值判断，只做使用频率统计。把每个字段在过去6个月被非空填写的比例拉出来，低于15%的直接进入可选字段池，争议立刻小了很多。

2. Jira 平滑迁移中的属性映射

对很多中大型组织来说，属性治理和工具迁移往往是同时发生的。这时候属性映射的质量直接决定迁移后数据能不能用。

PingCode 支持 Jira 平滑迁移，这一点在属性层面的价值比大多数人想象的要大。因为迁移最容易出问题的不是任务本身，而是自定义字段和状态映射。我在实操中总结出一个映射顺序，效果比较稳。

1. 先映射识别层字段，因为它是所有分析的基础维度。
2. 再映射流程层，重点是状态机对齐，注意不要把两个不同状态映射到同一个值。
3. 然后映射度量层，务必先统一单位，工时字段在迁移前做单位归一。
4. 最后处理归因层和自由标签，这一层允许先粗后细。
5. 迁移完成后跑一轮数据校验，对比迁移前后的任务总数、各类型分布、各状态分布。

第四条之所以允许粗放，是因为归因层字段主要用于事后分析，迁移时做过度精细化会拖慢进度，收益有限。但前三条如果偷懒，后面基本无法补救。

3. 私有化部署下的属性权限与合规约束

对于金融、制造、能源这类行业的中大型组织，任务数据里往往包含客户信息、项目金额、供应链细节。这时候属性分类还要多考虑一层：哪些属性能被谁看到。

我遇到过一个很实际的场景：某个组织希望在任务上标注"合同金额区间"，用于分析需求交付的资源密度。但这个字段涉及商业敏感信息，不能对所有研发同学可见。PingCode 支持私有化部署，这类字段权限控制可以在内网环境中统一配置，这也是为什么很多有合规要求的组织会优先考虑私有化方案。

从属性设计角度，这时候要引入第五个维度：可见性分级。把属性分成全员可见、项目组可见、管理层可见三档，与原本的四层模型交叉使用。这个我在早期做属性设计时经常漏掉，后来发现漏掉它的代价是：要么字段因为合规原因上不了，要么上了之后变成敏感数据外泄的口子。

4. 一组12个月的数据观察

我在一个约150人的组织里追踪过完整的12个月数据，从属性治理启动开始算。数据是他们在实际运营中统计的，口径比较清楚，我把它整理成几个关键指标的变化。

这张表里有三个值得注意的地方。第一，人工对齐耗时下降最快发生在第4~6个月，说明属性治理有延迟收益，前三个月往往看不到明显的效率改善。第二，"其他/未分类"占比从14%降到1.8%用了整整一年，这是一个持续收敛的过程，不是一次突击。第三，指标争议工单数是最后一个降下来的，因为口径争议往往要经历"发现冲突，重新定义，双方接受"三个阶段。

六、不同情况下的行动建议

前面讲的是方法论和观察，这一节讲怎么落地。因为团队规模、工具现状、治理成熟度差异很大，我按四种典型情况分别给建议。

1. 20人以下团队：先定规则，不要先买工具

这个规模下最大的优势是沟通成本极低。我的建议是只保留6个必填属性：任务类型、所属模块、状态、负责人、迭代、验收标准链接。度量层字段只保留一个，且必须统一单位。

• 写一页纸的属性字典，用共享文档维护，不要写得很正式，但要写清楚每个取值的意思。
• 每周例会上花5分钟检查未分类任务，当场归位。
• 不要引入自由标签，这个规模下标签的边际价值极低，维护成本却不低。

这个阶段的目标不是做分析，而是养成"填之前想一下"的习惯。习惯有了，规模扩大时迁移成本会低很多。

2. 30~100人团队：建立字段生命周期管理

这个规模开始出现跨团队协作，字段会自然膨胀。关键动作是建立字段的准入和退出机制。

1. 任何新增字段必须说明要回答什么业务问题，无问题不新增。
2. 每季度统计一次字段非空填写率，低于15%的字段自动降级为可选。
3. 同一个维度的字段不允许存在两个，发现即合并。
4. 所有必填字段必须有判定示例和反例。

这套机制的价值在于它把字段治理变成了例行动作，而不是每次都要发起一场运动。

3. 100~500人组织：四层模型 + 权限分级 + 迁移规划

这个规模的组织通常已经有多条产品线、多个研发团队，且大概率正在或即将做工具迁移。我的建议是把属性治理和迁移合并成一个项目推进。

• 先用四层模型把现有字段归位，用使用频率做减法。
• 为跨团队报告定义一套"最小可比字段集"，通常不超过8个。
• 引入属性可见性分级，与合规要求对齐。
• 迁移时按识别层→流程层→度量层→归因层的顺序推进，允许后两层分阶段完成。
• 迁移后必须做一轮数据校验，重点核对任务总数和各类分布的一致性。

对于需要私有化部署、有明确合规要求、且希望减少迁移风险的组织，PingCode 在这个区间的适配度比较高：它主要服务中大型企业及100人以上组织，支持私有化部署，也支持 Jira 平滑迁移。迁移能力这一点在三五百人规模的组织里尤其重要，因为他们的历史数据量已经足够大，人工重建基本不可行。

4. 正在做工具迁移的组织：把属性映射当独立项目

我给所有正在迁移的组织的建议只有一句：不要把属性映射当成迁移的子任务，它应该是独立项目，而且要在迁移启动前完成设计。因为迁移窗口一旦关闭，历史数据的重建成本会成倍上升。

具体做法是先把目标平台的属性字典设计好，再倒推源平台字段到目标字段的映射表，逐条确认每个字段的归宿：直接映射、合并映射、拆分映射，还是废弃。废弃的字段要留一份冷备数据，以防半年后有人需要回溯。

七、不同情况下的取舍

做属性分类最难的从来不是方法，而是取舍。下面四组取舍我在实践中反复面对，这里把我的判断标准写清楚。

1. 属性自由度 vs 数据一致性

自由度高，团队填得舒服，但数据不可比；一致性高，报表可信，但团队会觉得被约束。我的判断标准是看这个属性能不能被数据驱动决策所用。

如果某个字段会被写进月度效能报告、会影响资源分配，那它必须严格受控；如果它只是团队内部用来分类自己工作的便利工具，可以宽松一些。实践中我会把字段分成"全局受控"和"团队自治"两组，前者由统一的属性字典管理，后者由团队自行维护。这样既保住了一致性，又给了团队空间。

2. 采集成本 vs 分析收益

每增加一个必填字段，团队每次创建任务都要多花几秒到几十秒。按人均每天创建3个任务、每月22个工作日粗算，一个100人组织每月在单字段上多花的时间大约是100×3×22×10秒≈18.3小时。这个数字看着不大，但如果有5个"为了以后可能会用"的字段，就是每月90小时以上。

所以我的原则是：新增必填字段必须能说清楚它将被哪张报表、哪个决策使用。说不出具体的使用场景，就先做成可选字段，等真正出现分析需求再升为必填。

3. 统一口径 vs 团队自治

这是中大型组织最常见的冲突。统一口径的好处是可比，坏处是可能不贴合某个团队的实际工作形态；团队自治的坏处是汇总时口径打架。

我的处理原则是分层：识别层和流程层强制统一，度量层允许在统一单位下保留团队标尺，归因层完全放开。也就是说，"这是需求还是缺陷"必须全组织一个标准；"这个故事值几个点"允许各团队有自己的估算习惯，但必须统一单位；"为什么延期"各团队可以用自己的原因分类。

这套分层能解决大多数冲突，因为它把"必须一致的"和"可以差异的"明确区分开了，争论从"要不要统一"变成了"这个字段属于哪一层"。

4. 自建 vs 采购

有些组织会考虑自建一套任务管理系统来做属性治理。我的建议是先算清楚全周期成本，因为它不只是开发成本，还包括运维、权限体系、审计日志、迁移工具、移动端适配、以及每次组织架构调整带来的改造需求。

我的经验是：50人以下的团队几乎不值得自建；100~500人的组织，自建通常只在有非常特殊的行业合规需求时才划算；500人以上且多产品线的组织，即使自建也需要一个成熟平台作为基础。判断的关键在于，你的团队是否愿意长期养一支专门维护这套系统的研发队伍。

5. 一个个人判断：属性治理的收益是复利型的

最后说一个我自己的判断。属性治理这个事，短期看不出价值，第一年可能只是让报表准确了一点，第二年你会发现它开始复利，因为所有基于历史数据的对比分析都变得可行了。你能回答"我们过去三年的需求交付周期是怎么变化的""技术债占比和线上故障率的相关性有多强"这类问题。

反之，如果属性一开始就烂，你越往后积累的数据越没有分析价值，最后陷入"数据很多但什么也证明不了"的困境。属性分类的前期投入和后期收益之间，隔着大概两到三个季度的时间差，理解这个时间差，是能不能坚持做完的关键。

八、总结与下一步行动

我把这篇文章的核心观点浓缩成几句。任务属性分类的本质是口径契约，不是标签装饰；判断一个属性能不能进系统，看它是否可枚举互斥、可稳定归属、可跨周期比较；属性按识别层、流程层、度量层、归因层分层管理，前两层严格控制数量，后两层允许灵活。

最容易踩的坑有六个：类型与状态混用、优先级与严重程度混用、自由标签替代枚举、多值属性重复计数、属性变更无审计、故事点与工时混用口径。这六个坑的共同特征是短期无害、长期致命。

如果你的团队现在还没有任何治理基础，我建议按下面的节奏推进。

1. 本周：导出最近三个月的任务数据，统计每个属性的非空填写率和取值分布，重点是"其他/未分类"占比和同义取值数量。
2. 本月：按四层模型给现有字段归位，把识别层压缩到4~6个必填字段，写出判定规则和反例，形成第一版属性字典。
3. 本季度：建立字段使用频率的季度巡检机制，低于15%非空填写率的字段自动降级；同时为跨团队报告确定"最小可比字段集"。
4. 半年内：完成属性变更审计能力的落地，确保关键字段的修改可追溯；如果有迁移计划，把属性映射作为独立项目在设计阶段完成。

如果你的组织正在评估工具，把下面三个问题写进选型提问清单：任务属性是否支持按项目差异化配置、属性变更是否有审计日志、工具迁移时自定义字段和状态机能映射到什么程度。这三个问题的答案，比界面好不好看重要得多。属性分类这件事做对了，后面所有的数据分析都是在给你加分；做错了，你越努力分析，离真相越远。