任务属性分类教程：项目负责人协同管理，避坑指南

去年我接手一个 180 人的研发交付项目，三个月里项目周会从 1 小时拖到 2.5 小时，其中 40 分钟反复讨论同一个问题：这条任务到底算谁的、卡在哪一环、要不要升级。加人没用，改流程也没用。真正解决问题的动作，是把任务属性重新分了一次类，两周之后周会回到 55 分钟，跨组任务的平均等待时长从 3.4 天降到 1.6 天，项目负责人每天花在"确认信息"上的时间少了大约 1.5 小时。

这篇文章是那次改造的完整复盘。我会讲清楚任务属性分类到底在分什么、为什么大多数团队一上来就分错、项目负责人该怎么用它做协同管理，以及我们在中大型组织里踩过的 9 个坑。如果你正在做项目管理工具迁移、或者正被"字段填了一堆但没人看"折磨，这篇可以直接照着抄作业。

一、核心结论：任务属性分类的本质，是给协同决策定字段规则

先把结论摆在前面，后面的内容都是围绕这五条展开的。我见过太多团队把这件事当成"整理表格"，结果花了两个月设计出 28 个字段，填了三周就彻底荒废。区别只在于：他们设计的是描述字段，而协同真正需要的是决策字段。

1. 结论一：字段要服务于"下一步动作"，不是服务于"事后描述"

判断一个字段该不该存在，我只有一个标准：看到这个字段的值，当事人能不能立刻决定下一步做什么。"负责人是谁"能决定找谁，"是否阻塞"能决定要不要升级，"属于哪个交付物"能决定影响范围，"预估工量"能决定要不要拆分。

反过来，"任务详细说明""背景补充""备注"这类字段，无论设多少，都不会改变任何人的动作，只会变成文档坟场。我们做过统计，一个 300 人组织里，"备注"字段的填写率不到 12%，而"负责人"字段的填写率是 100%，因为不填就走不下去。

2. 结论二：属性应该分四层，越往下越自动，越往上越人工

我把任务属性拆成归属层、状态层、风险层、成本层四层。归属层解决"这是谁的活"，状态层解决"现在走到哪一步"，风险层解决"会不会出问题"，成本层解决"要花多少代价"。

关键规律是：归属层和状态层必须强制人工填写（或由流程强制），风险层应该由规则自动计算为主，成本层允许模糊估算。层次越靠下，人工填写成本越高、越容易造假；越靠上，越应该交给系统自动生成。

3. 结论三：必填字段的上限是 5 个，超过这个数就会出现数据造假

这不是拍脑袋的数字。我们在三个团队做过对照：必填字段 3～5 个时，字段准确率维持在 90% 以上；增加到 8 个后，三分之一的人开始填默认值；增加到 12 个以上，"其他""待定""不适用"这类无意义值的占比超过了 40%。

数据一旦为了通过校验而被填，它就已经失去协同价值。宁可用 5 个可靠字段，也不要用 12 个不可靠字段。剩下的信息放进自动计算或二级详情页，别放在创建任务的必经路径上。

4. 结论四：这套东西 80% 的收益落在项目负责人身上，20% 落在执行人身上

执行人关心的是"我今天做什么"，他只需要看到状态和优先级。真正被属性分类改变工作方式的，是同时盯 3～8 个并行工作的项目负责人。

他的核心痛点是：信息在不同人脑子里，需要不断打电话、发消息、翻聊天记录来对齐。属性分类的价值就是把"人脑里的对齐"变成"系统里的读取"。

5. 结论五：工具切换的成本，70% 花在历史数据映射，不在工具本身

我参与过三次项目管理工具切换，每次大家都会把时间花在"新工具好不好用"上，但真正拖垮项目的是历史数据。几千条在途任务的字段含义、状态对应关系、旧字段里混着的自由文本，才是真正的成本黑洞。

所以任何一次属性分类改造，都要先问一个问题：历史数据是迁移、归档还是只读封存？这个决策的影响，比字段设计本身大得多。

二、背景和真实场景：项目负责人到底被什么拖住

要理解为什么属性分类重要，得先看清项目负责人的一天是怎么被消耗掉的。我做过一个简单记录：在改造前的一周里，某位负责 6 个并行工作的项目经理，每天发出 47 条即时消息，其中 31 条属于"确认某件事的归属或状态"。

1. 一个真实的周会现场

那场 2.5 小时的周会，前 40 分钟在讨论一条已经卡了 5 天的任务。测试负责人说这条任务的验收标准写的是上一版需求，研发负责人说这条任务在他的看板上属于"待联调"，运营负责人说这条任务在他那边是"已交付"。

三个人看到的是三条任务，因为系统里的状态没有统一口径，风险等级也没人填过，责任人字段写着"待定"。真正的问题不是人不配合，而是任务属性没有承担起"唯一事实来源"的职责。

2. 三种典型的属性失控现场

（1）标签爆炸：三年积累出 400 多个标签

我见过一个团队，标签从"紧急"发展到"紧急-客户A-版本2-加急-二次确认"这种复合标签。每个人按自己的习惯创建，最后没有任何人能用标签筛选出有效信息。标签的失控速度和团队人数几乎成正比。

（2）状态机分叉：同一件事在三个系统里是三种状态

需求系统里是"开发中"，项目管理工具里是"待测试"，即时通讯工具里是"已提测"。状态不是属性，状态是流程节点，一旦流程不唯一，属性就失去了参考价值。

（3）责任人稀释：字段写着"前端组"，但组里没人认领

把责任人填成团队名而不是具体人，是协同中最隐蔽的坑。它看起来填了，实际上把决策责任转移给了整个组织，等于没填。我们做过统计，责任人为团队名的任务，平均解决时长是责任到人任务的 2.7 倍。

3. 中大型组织为什么更难：100 人是分水岭

100 人以下的团队，靠人和人的直接记忆还能撑住。一旦超过 100 人，跨部门、跨地域、外部供应商合作开始出现，口头共识的传递损耗急剧上升。我的观察是：100 人以上组织里，任务属性分类不是"优化项"，而是"基础设施"。

这类组织通常还有几个额外约束：需要私有化部署以满足数据合规，需要和已有研发流程打通，往往还背负着从国外工具迁移的历史包袱。这也是我在后面用 PingCode 举例的原因，它主要服务中大型企业及 100 人以上组织，支持私有化部署和从 Jira 平滑迁移，在这个场景下比较贴合。

4. 我们采集到的一组基线数据

在改造前的两周，我们记录了 5 个团队的日常运作数据：项目负责人每天平均花 2.4 小时在"确认信息"上，占工作时间的 30%；跨组任务平均等待 3.4 天才能进入下一环节；周会上被反复讨论的任务占议程的 45%。

改造后，这三个数字分别降到 0.9 小时、1.6 天和 18%。这不是效率工具的功劳，而是属性分类把信息从"人脑"搬到了"系统字段"里。

三、常见误区拆解：9 个坑，我踩过 7 个

接下来这部分是我最想写的。下面这 9 个误区，我在不同项目里至少踩过 7 个，每一个都付出过真实代价。我先用表格快速过一遍，再挑影响最大的几个展开讲。

1. 误区一：字段越多越规范，这是最贵的一个误解

字段的边际收益是递减的，但边际成本是递增的。第 1 个字段（负责人）的收益可能是 40%，第 12 个字段的收益接近零，而它带来的填写疲劳会拖垮前面 11 个字段的数据质量。

字段设计的目标不是"信息完备"，而是"关键决策点不掉链子"。我在一个项目里删掉了 9 个字段，字段总数从 17 降到 8，结果关键字段的准确率反而从 72% 升到 94%。

2. 误区二：把状态机当成属性容器

状态是任务在流程中的位置，它是唯一的、排他的。而"加急""返工""客户投诉"这些是标签或风险属性，可以和状态并存。把两者混在一起，会导致流程统计彻底失真，你想知道"平均测试周期"，系统里却找不到干净的状态序列。

我的判断标准很简单：如果一个值让任务同时处于两个流程位置，它就不该是状态。

3. 误区三：用备注代替字段，等于把信息埋进坟场

我见过太多"责任人在描述里写了一句""验收标准在附件里提了一下"的任务。这类信息无法筛选、无法聚合、无法预警，只能在出问题时被人肉翻出来。

经验法则是：如果某个信息会被用来做筛选、排序、提醒或统计，它就必须是字段，而不是文本。这条规则能解决 80% 的属性设计纠结。

4. 误区四：迁移时字段一对一照搬，把旧病带到新家

工具切换时最省事的做法是字段一对一映射，但这也是最危险的做法。旧系统里那 22 个字段，有大半是历史上临时加的，早就不用了。直接搬过去，等于让新系统继承所有历史包袱。

我的做法是：迁移前先做一轮字段使用率盘点，过去 6 个月填写率低于 20% 的字段，一律不迁移，只把数据归档。这一步通常能砍掉一半字段。

5. 误区五：忽略外部协作者，让跨组织协同断在权限上

中大型组织普遍有外包、供应商、跨法人协作方。如果属性字段只对内部成员可见，外部成员就会退回到邮件和聊天工具里确认信息，系统的唯一事实来源地位就崩了。

可行的做法是设置字段级可见性：归属层和状态层对协作方可见，成本层和内部风险评级对内可见。这样既保住了协同效率，也不泄露内部敏感信息。

6. 误区六：分类一次定死，两年不回头看

业务变了，字段含义也会漂移。我们做过一次复盘，发现某个"项目阶段"字段在两年内被赋予了四种不同理解，横跨三个部门。原因很简单：没人负责维护语义。

建议设立季度字段评审，只看三个数：填写率、无意义值占比、被用于筛选/统计的次数。任何一项持续走低的字段，就该被清理或者重定义。

四、专业判断逻辑：四层分类模型怎么搭

讲完坑，说我实际用的方法。四层模型不是理论框架，是我在三个项目里反复调整后沉淀下来的结构。它的核心目标是：让每个人只填最少的信息，却能让系统回答项目负责人最关心的四类问题。

1. 第一层：归属层，解决"这是谁的活"

归属层包含三类字段：责任人（必须到具体人）、所属交付物或模块、协作方。责任人不允许填团队名、不允许为空的规则，是整层的地基。

我强烈建议把"所属交付物"作为归属层的第二个字段。它能回答"这条任务影响哪个可交付结果"，是项目负责人做影响面分析的核心依据。没有它，你只能看到任务列表，看不到交付结构。

2. 第二层：状态层，解决"现在走到哪一步"

状态层的关键是收敛，而不是丰富。一个组织内的主流程状态不要超过 7 个：待评估、待排期、进行中、待评审、待验收、已完成、已关闭。

如果不同业务线需要更多细节，用子状态或检查项扩展，但主状态必须统一。主状态不统一，跨项目统计就永远是错的。我见过最多的一家公司有 34 个状态，导致任何跨项目报表都无人相信。

3. 第三层：风险层，解决"会不会出问题"

风险层我建议尽量自动计算，而不是人工填写。可自动化的字段包括：是否阻塞（有阻塞标记即自动置位）、阻塞天数（从阻塞标记时间起算）、依赖任务数、临期预警等级（按截止日期和状态自动推导）。

只有真正需要人工判断的才手动填，比如"外部依赖方确认状态"和"是否需要升级"。这样风险层的填写字段通常不超过 2 个，但可用信息量很大。

4. 第四层：成本层，解决"要花多少代价"

成本层包括工作量估算、优先级、目标完成时间。这一层最忌讳追求精确，精确到小时的估算在知识型工作里基本是伪精确。

我推荐用区间估算（比如 0.5 天以内、0.5～2 天、2～5 天、5 天以上四档）替代小时数。四档估算的填写速度快 3 倍，而用于排期决策的信息量几乎没有损失。

5. 字段的三种权限：必填、选填、自动

四层模型确定后，每个字段都要被归入三种权限之一。必填字段控制在 5 个以内，且必须是"不填就无法推进流程"的字段；自动字段由系统规则生成，用户不可编辑；剩余全部归为选填，不参与流程校验。

6. 一份可直接复用的字段配置

下面这份配置是我在一个 300 人研发组织实际使用的版本，可以直接改。它一共 12 个字段，其中必填 5 个、自动计算 4 个、选填 3 个。

task_attributes:
── 归属层 ──

key: assignee

name: 责任人

type: user

required: true # 必填，不允许填团队名

key: deliverable

name: 所属交付物

type: select

required: true # 必填，决定影响面分析

key: collaborator

name: 协作方

type: multi_user

required: false

── 状态层 ──

key: status

name: 主状态

type: workflow_status

required: true

options: [待评估, 待排期, 进行中, 待评审, 待验收, 已完成, 已关闭]

key: sub_stage

name: 子阶段

type: select

required: false # 用子状态承接业务线差异，不污染主状态

── 风险层 ──

key: is_blocked

name: 是否阻塞

type: boolean

required: false

compute: auto # 由阻塞标记自动置位

key: blocked_days

name: 阻塞天数

type: number

required: false

compute: auto # 从阻塞开始时间自动累计

key: dependency_count

name: 依赖任务数

type: number

required: false

compute: auto

key: escalate

name: 是否升级

type: boolean

required: true # 必填，项目负责人每天扫这一列

── 成本层 ──

key: effort_range

name: 工作量区间

type: select

required: true

options: ["0.5 天以内", "0.5~2 天", "2~5 天", "5 天以上"]

key: priority

name: 优先级

type: select

required: false

options: [P0, P1, P2, P3]

key: due_date

name: 目标完成时间

type: date

required: false

7. 判断一个字段该不该留，只问三个问题

1. 过去 6 个月，有没有人用它做过筛选、排序、预警或者汇报？没有就删。
2. 如果它是空的，会不会导致流程走不下去？不会就改成选填。
3. 它能不能由其他字段推导出来？能就改成自动计算。

这三个问题问完，字段数量通常能压缩 40% 以上。属性分类的质量不取决于你加了多少，而取决于你删掉了多少。

五、真实案例与数据观察：300 人研发组织从 Jira 迁到 PingCode

这一节是我最想具体讲的，因为它包含了完整的迁移过程和 12 周的数据观察。案例主体是一家 300 人规模的研发组织，5 条产品线，2 个外包团队，同时有数据合规要求，必须支持私有化部署。

1. 项目背景与约束条件

他们原来的工具用了 6 年，积累了大量历史任务，字段数量 22 个，状态 34 个，标签 400 多个。约束有三条：数据不能出内网、迁移期间业务不能停、外包团队也要能参与协同但不能看到成本数据。

选型时我们的判断依据很直接：能不能支持私有化部署、能不能平滑承接 Jira 的历史数据、能不能做字段级权限。最终选的是 PingCode，它主要服务中大型企业及 100 人以上组织，在这三条上比较贴合需求。

2. 属性映射：22 个字段如何落到 12 个

这一步是整个迁移最花时间的环节。我们没有做字段一对一映射，而是先做了一轮使用率盘点，把 22 个字段分成三类：必须迁移、数据归档、直接废弃。

3. 迁移过程的四个阶段与转化情况

整个迁移持续了 5 周。第一周做字段盘点和映射方案，第二、三周做数据迁移和校验，第四周做权限配置和小范围试点，第五周全量切换。用 PingCode 承接 Jira 的历史数据时，最大的工作量集中在状态收敛和自由文本字段的清洗上。

关于平滑迁移这件事，我的实际感受是：工具层面确实能降低迁移成本，但真正的难点永远是"旧数据的语义决策"，而不是技术搬运。同一批数据在不同团队眼里含义不同，这才是迁移返工的主要来源。

4. 迁移后的 12 周数据观察

切换完成后的 12 周里，我们持续记录了四项指标。前 6 周是适应期，第 7 周开始进入稳定期，数据变化比预期更明显。

跨组任务平均等待时长从 3.4 天降到 1.6 天，逾期任务占比从 19% 降到 8%，阻塞任务的平均解除时长从 5.2 天降到 2.3 天，字段整体填写率从 46% 升到 91%。值得注意的是，字段总数从 22 降到了 12，必填从 11 个降到了 5 个。

5. 私有化部署带来的额外约束

私有化部署保证了数据不出内网，这是硬性合规要求。它同时带来两个现实约束：一是版本升级需要走内部流程，节奏比云端慢；二是外部协作方需要通过受控方式接入，权限模型要提前设计。

我的建议是，在私有化环境里落地属性分类时，把字段权限设计提前到字段设计阶段，而不是上线后再补。我们就是先补了权限，结果返工了一轮字段可见性配置。

6. 我在这个项目里做错的两件事

第一件是过早开放了子阶段的自定义权限，导致三条业务线各自加了一套子阶段，两周内又出现了 14 个新状态值。后来我们收回了自定义权限，改成统一维护。

第二件是试运行时只用了一个团队做样本，没有覆盖外包协作场景。全量切换第一周，外包成员看不到协作方字段，跨组织任务又退回到了即时通讯工具里确认。

这两件事的教训是一样的：属性分类的验证必须在最复杂的协同场景里做，而不是在最听话的团队里做。

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

四层模型和字段配置是通用骨架，但落地方式必须随团队规模调整。下面按五个区间给出具体建议，你可以直接对号入座。

1. 10 人以下团队：不要做属性分类，做两份清单

这个规模下，沟通成本极低，做复杂的字段体系纯属浪费。你只需要一份"责任人清单"和一份"待办清单"，用最简单的方式记录谁在做什么、什么时候完成。

唯一值得提前做的，是把责任人的粒度坚持到个人。小团队最大的优势是信息透明，千万别用"团队名当责任人"这种习惯把它消耗掉。

2. 10～50 人团队：只做归属层和状态层

这个阶段最重要的是统一状态口径。建议主状态控制在 5～6 个，责任人和所属模块设为必填，其余全部选填。风险层可以用"是否阻塞"一个布尔字段解决，成本层暂时不要引入估算字段。

3. 50～100 人团队：四层齐备，但必填不超过 5 个

这是开始出现跨部门协同的区间，也是属性分类开始产生明显收益的区间。建议完整落地四层模型，但必填严格控制在 5 个以内，工作量估算用区间档位而非小时数。

4. 100～500 人团队：需要权限模型和迁移规划

这个规模的组织通常已经有多个业务线，且大概率在做工具国产化替代。你需要额外考虑三件事：字段级权限（外部协作方能看到什么）、历史数据处置策略（迁移还是归档）、状态收敛的推动方式（自上而下统一还是先做试点）。

如果涉及从国外工具迁移，建议优先选择支持平滑迁移和私有化部署的方案。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署和 Jira 平滑迁移，是国产替代场景里比较常见的选择，适合这一类组织的合规与迁移双重需求。

5. 500 人以上或多项目组合：需要属性治理机制而不是一次设计

这个规模下，字段设计不可能一次做对，重点转向治理机制。我建议成立一个虚拟的属性管理小组，由项目管理办公室牵头，每季度做一次字段使用率评审，每半年做一次状态和交付物的语义对齐。

在这个体量上，治理机制的缺失比设计失误更致命。因为没有机制，再好的初始设计也会在 18 个月内退化回混乱状态。

6. 已经积累几年脏数据：先做归档，不要试图清洗全部

很多团队卡在"历史数据太多太乱"上。我的建议是分级处理：18 个月以内、状态为进行中的任务做完整迁移；其余全部做只读归档，不参与新体系。

试图清洗所有历史数据是一个无底洞。我们算过一次，全量清洗 14,820 条任务的语义，按人均每天处理 80 条计算，需要约 185 人天，这笔投入的回报几乎为零。

七、不同情况下的取舍

属性分类没有标准答案，只有取舍。下面四组矛盾是每个项目负责人最终都要面对的，我给出自己的判断依据。

1. 取舍一：字段丰富度 vs 填写成本

字段越多，数据越完整，但填写越慢、越容易填假。我的判断是：当单任务创建耗时超过 60 秒时，字段就是过多了。可用性永远优先于完备性，因为不填的字段价值为零。

具体的平衡点是：必填 5 个、自动计算 4 个、选填不超过 5 个。选填字段的价值在于需要时能用，而不是强制所有人每次都面对。

2. 取舍二：强制必填 vs 自由推进

强制必填会拖慢创建速度，但能保证关键信息不缺失；自由推进会加快流转，但会让统计和预警失效。我倾向于对归属层和状态层强制，对风险层和成本层宽松。

原因是：归属和状态缺失会让流程直接走不下去，是硬约束；而风险和成本的缺失只是降低决策质量，不会阻断流程，可以用提醒和统计手段逐步改善。

3. 取舍三：统一模板 vs 项目自治

统一模板利于跨项目统计和人员流动，项目自治利于贴合具体业务。我的经验是：主状态和归属层字段必须全局统一，其余允许按项目类型设置模板。

一个反例是我早期参与过的一个项目，允许每条业务线自定义主状态，结果 5 条线给出 34 个状态。跨项目报表直接报废，最后不得不强制收敛。这一步的成本，比一开始就统一高得多。

4. 取舍四：自研 vs 采购 vs 迁移

自研的好处是贴合度最高，坏处是维护成本被严重低估；采购的好处是功能成熟，坏处是可能需要适配现有流程；迁移的好处是保留历史数据，坏处是要承担语义清洗成本。

我的判断顺序是：先明确合规约束（是否必须私有化部署），再看历史数据规模（是否需要平滑迁移），最后才比较功能细节。把顺序反过来，几乎一定会选错。

八、7 天落地清单：把任务属性分类真正跑起来

讲了这么多逻辑和取舍，最后给一份可以直接执行的清单。这是我实际用过两次的节奏，7 天完成从设计到试运行，第 3 周开始全量。

1. 第 1～2 天：盘点和删减

1. 导出当前所有字段清单，统计近 6 个月填写率。
2. 填写率低于 20% 的字段直接标记为废弃，数据只做归档。
3. 把所有状态值列出来，尝试收敛到 7 个以内主状态。
4. 把责任人字段中填了团队名的任务全部筛出来，评估影响范围。

这一步的产出是一张"字段处置表"，包含保留、改造、归档三类。没有这张表，后面的设计都是空中楼阁。

2. 第 3～4 天：四层设计

1. 按归属、状态、风险、成本四层归类保留字段。
2. 为每个字段确定必填、选填或自动计算。
3. 把必填字段数压缩到 5 个以内。
4. 把能自动推导的字段（阻塞天数、依赖数、临期等级）全部改为自动。

3. 第 5 天：权限与可见性设计

确定哪些字段对外部协作方可见、哪些仅内部可见。这一步特别容易被跳过，但它是跨组织协同能否成立的关键。我的经验是归属层和状态层对外可见，成本层和内部评级仅内部可见。

4. 第 6 天：试运行与埋点

选一个包含外部协作方的真实项目跑一轮，观察三件事：单任务创建耗时、必填字段的填写完整度、有多少人绕过系统在即时通讯工具里确认信息。

第三个指标最容易被忽略，但它是最灵敏的信号。如果一周内出现明显回升，说明必填字段还是太多。

5. 第 7 天：评审与调整

根据试运行数据做最后一轮调整，重点是减法。我们上一次在这一步删掉了 3 个字段，把必填从 7 个降到 5 个，创建耗时从 62 秒降到 38 秒。

6. 第 2～4 周：全量推行与效果验证

全量推行后，每周记录一次四项指标：跨组任务等待时长、阻塞任务解除时长、逾期任务占比、字段填写率。四周后做第一次复盘，通常能看到前三项明显改善。

九、常见问题

1. 任务属性分类和标签有什么区别，能不能只用标签？

标签是自由的、多值的、可无限增长的，属性是受控的、有明确取值范围的。协同决策需要的是稳定可比的字段，而标签适合做辅助检索。

我的建议是：凡是需要用来筛选、统计、预警、排序的信息，一律用字段；只有辅助性的、临时的、跨维度的标记才用标签。而且标签值必须由管理员预置，禁止成员自由创建，否则三年后你会有 400 多个标签。

2. 必填字段到底设几个合适？

我的经验值是 5 个，上限不超过 8 个。低于 3 个会丢失必要信息，高于 8 个会显著降低数据质量。这个结论来自三组对照观察：必填 3～5 个时字段准确率超过 90%，必填 8 个时降到 74%，必填 11 个时只剩 55%。

3. 存量任务太多，必须全部迁移吗？

不必。我建议按状态和时间分级：18 个月以内且仍在进行中的任务做完整迁移，其余做只读归档。全量清洗的成本极高，我们测算过约 185 人天的投入，而回报几乎为零。

4. 私有化部署会不会让属性分类更难落地？

会有额外约束，但不是障碍。主要影响是版本升级节奏和外部协作方的接入方式。我的建议是把字段权限设计提前到字段设计阶段一起做，避免上线后再返工。

支持私有化部署的平台在中大型组织里需求很明确，尤其是涉及数据合规的场景。选型时把这一条放在功能比较之前，能省掉很多后期麻烦。

5. 迁移时字段要不要一对一照搬？

绝对不要。照搬会把旧系统的字段膨胀问题一并继承过去。正确做法是先做使用率盘点，填写率低于 20% 的字段全部归档不迁移，通常能砍掉一半字段。这也是我在实际迁移中最省时间、收益最大的一个决策。

6. 怎么判断属性分类是不是真的起作用了？

看三个信号：跨组任务的等待时长是否下降、项目负责人每天用于"确认信息"的时间是否减少、即时通讯工具里关于任务状态的讨论是否减少。第三个信号最灵敏，也最难造假。

十、写在最后

回到最开始那个 180 人的项目。我们真正做的不是设计了一套完美的字段体系，而是承认了一件事：项目负责人的时间不该花在确认信息上，而应该花在判断和取舍上。任务属性分类的全部意义，就是把人脑里的对齐动作，变成系统里的读取动作。

这篇文章里我最想让你记住的，是三个反常识的判断：字段不是越多越好，必填超过 8 个就会开始造假；状态不是越细越好，主状态超过 7 个跨项目统计就会失效；迁移不是越完整越好，全量清洗历史数据的投入产出比通常低得惊人。

下一步怎么做，我给一个最小行动：今天花 30 分钟，把你当前项目里所有字段的填写率拉出来看一遍。填写率低于 20% 的，先标记为待归档；责任人填了团队名的，列一个清单；主状态超过 7 个的，画一张收敛映射表。这三件事做完，你已经完成了整套改造 60% 的工作量。

剩下的 40%，是在真实项目里试运行、删字段、调权限。这个过程不需要一次做对，但需要有人负责把它做下去。如果组织里没人负责字段语义的维护，那再好的初始设计，18 个月后也会退化回原点。