2023 年秋天，我受一家 137 人的 SaaS 公司邀请做研发流程体检。打开他们的项目管理平台，需求工作项上挂着 27 个自定义字段，但看板上 2400 多张卡片里，"所属模块"的填充率只有 31%，"需求来源"有 14 种取值其中 6 种是错别字变体，"优先级"字段里 89% 的卡片都是 P2 及以上。团队负责人跟我说："我们管得很细啊。"我说："你不是管得细，你是把分类的责任推给了填表的人。"
这次体检最终演变成一场持续 11 周的任务属性重构。字段从 27 个砍到 9 个，需求平均交付周期从 23 天降到 16 天，跨团队澄清会议从每周 5 场降到 2 场。这篇文章就是那次重构的完整方法论，加上我在之后 6 个中大型团队（80 人到 600 人）落地时踩出来的坑。样本有限，但足够具体，你可以直接拿去对照自己的看板。
一、核心结论：任务属性分类不是"建字段"，而是"建契约"
先把结论放在最前面：任务属性分类的成败，不取决于你建了多少字段，而取决于每个字段是否被明确规定了"谁在什么时机填、填错会怎样、谁来清理"。没有这三条，字段越多，组织的决策质量越低。
我在复盘 6 个项目时发现一个稳定的规律：字段数量和需求交付周期的关系不是线性的，而是先平后扬。字段从 5 个增加到 12 个时，交付周期几乎没变化；一旦超过 15 个，每增加 3 个字段，平均交付周期会增加 1.5 到 2 天。拐点通常出现在 15 到 18 个字段之间，这和团队规模关系不大，和组织是否对字段做治理关系很大。
原因是：每个字段都是一份隐性契约。它要求创建者在几秒钟内做出一次判断，要求执行者在流转时确认一次，要求统计者在复盘时解释一次。字段一旦没人维护契约，它就退化成噪音。
1. 四层属性模型：让每个字段归位
我习惯把所有任务属性拆成四层。这个模型的价值在于：不同层的字段，治理责任人和变更频率完全不同。混在一起管，一定会乱。
| 层级 | 回答的问题 | 典型字段 | 变更频率 | 治理责任人 |
|---|---|---|---|---|
| 身份层 | 这是什么、归谁 | 工作项类型、所属产品、所属迭代、负责人 | 极低 | 研发效能/PMO |
| 流转层 | 现在在哪、下一步去哪 | 状态、状态类别、阻塞标记、流转原因 | 低 | 研发效能 |
| 度量层 | 多大、多急、多贵 | 优先级、故事点、预估工时、截止日期 | 中 | 产品负责人 |
| 治理层 | 谁改、改了算谁的 | 需求类型、来源、业务线、客户、合规标记 | 中到高 | 业务方+PMO 共管 |
关键判断在于：身份层和流转层必须全局统一，不允许任何团队自定义；度量层允许项目级差异；治理层允许业务线级差异，但取值必须来自受控字典。我见过最常见的翻车方式，就是让团队自由定义状态，结果 12 个团队有 9 套"完成"的定义。
2. 一条硬判断：属性必须能回答"改了会触发什么"
给字段做减法时，我只用一句提问：这个字段变化时，系统里会有什么东西随之变化？如果答案是"什么都不会变，只是记录一下"，那这个字段要么进备注，要么砍掉。
能触发变化的字段才有资格进主数据。比如"阻塞标记"置为真时，看板自动高亮、日报自动汇总、迭代风险自动升级，这是有效属性。"客户行业"填了之后没有任何自动动作，那它更适合放在需求描述里。
二、背景：为什么这个问题在这两年突然变致命
任务属性分类并不是新话题。十年前大家在电子表格里管需求，字段写错最多是统计麻烦。今天不一样了，属性和三件事绑死了。
1. 属性从"描述"变成了"路由"
在自动化程度高的平台上，属性直接决定工作项去哪里。比如"需求类型=技术债"会自动进入架构组的看板，"业务线=海外"会自动附加合规检查清单，"来源=客户反馈"会自动关联客户档案。
这意味着一个填错的属性，不再只是统计失真，而是把工作项路由到了错误的团队。我在一个 300 人团队里统计过：因为"业务线"字段填错导致的错误流转，平均每月 47 次，每次平均消耗 1.8 人时的澄清与转派成本，一年接近 1000 人时。
2. 属性成了 AI 和自动化的输入
现在的项目管理平台普遍在推 AI 辅助排期、自动摘要、智能分派。这些能力的输入就是任务属性。属性本身脏，AI 输出必然不可信。我见过一个团队抱怨"AI 排期不准"，排查后发现他们的"截止日期"字段里有 22% 是空白，另有 14% 早于创建日期。
3. 中大型组织为什么格外难
100 人以上的组织有三个特性，让属性分类的难度陡增。第一，决策链变长，一个字段的语义要经过 3 到 4 层传递才到执行者；第二，历史包袱重，组织调整一次就残留一批失效字段；第三，度量诉求分散，财务、交付、质量、合规四个方向都要从同一套字段里取数。
这也是为什么 PingCode 这类面向中大型企业、服务 100 人以上组织的平台，在自定义字段和工作项类型配置上做得比较深，不是因为它想让你建更多字段，而是因为大规模组织需要"可约束的灵活性"。它支持私有化部署，对数据敏感、需要把属性字典和内部主数据打通的团队来说，这一点比字段本身更重要。
三、拆解常见误区：五个我反复看到的坑
1. 误区一：把标签当分类用，把分类当状态用
这是最普遍也最致命的一个。标签是多值、无序、可叠加的描述；分类是单值、互斥、受控的归类。把两者混用，报表口径立刻崩掉。
我的实际案例：一个团队用"标签"来记录需求所属模块，一张卡片上打了"支付""结算""对账"三个标签。当管理层问"支付模块这个季度交付了多少需求"时，答案是 3 个标签加起来 187 条，但实际去重后只有 96 条需求。标签是多值字段，做模块归属统计必然重复计数。
正确做法是：模块用单值枚举字段，跨领域特性用标签。凡是需要进入"分母"的维度，一律用单值受控字段。
2. 误区二：优先级通胀
几乎所有团队都会经历优先级通胀。我统计过 6 个团队的优先级分布，治理前的平均值是：P0 占 7%、P1 占 34%、P2 占 48%、P3 占 11%。四个等级里 P1 和 P2 挤了 82% 的工作项，这个字段实际上已经不具备区分能力。
根因不是"大家爱标紧急"，而是优先级没有和资源约束挂钩。如果一个团队同时有 30 个 P1，而团队一周只能交付 6 个，那这 30 个里必然有 24 个是假的。我的做法是给优先级加约束：每个迭代内 P0+P1 的总故事点不得超过团队容量的 30%。约束一上线，优先级分布在一个迭代内就回归正常。
3. 误区三：为一个部门加一个字段
这是中大型组织最典型的病。"售后团队想看客户等级""财务想看合同编号""测试想看环境"，于是三个字段加上了。三个月后这三个字段的填充率分别是 41%、26%、19%。
我的判断标准很直接：如果一个字段只服务于一个部门的一次性统计需求，它应该进数据仓库或报表层，而不是进任务主数据。任务主数据只承载跨角色、跨流程、需要实时可见的信息。
4. 误区四：用自由文本承载分类信息
自由文本字段看起来最灵活，其实是数据质量的坟场。我在一个团队里发现"需求来源"这个字段是文本框，结果出现了"客户A""客户 A""客户a""A客户"四种写法，同一个来源被拆成 4 组数据。
原则很简单：凡是会进入统计、筛选、自动化的字段，必须是受控枚举或字典引用；只有"备注""补充说明"这类字段才允许自由文本。
5. 误区五：字段只建不管，没有退出机制
大多数团队有字段的"出生流程"，没有"死亡流程"。我建议在治理规则里写死一条：任何字段连续 90 天填充率低于 20%，自动进入待退役清单，由字段负责人确认是保留、合并还是删除。
这条规则我在 3 个团队推行过，第一轮就清理掉了 5 到 8 个僵尸字段，而且没有任何业务方反对，因为确实没人用。
四、专业判断逻辑：三问法、四象限与治理规则
1. 三问法：任何新字段上线前必须回答
我在做字段评审时只用三个问题，任何一个答不上来就不批。
- 它参与流程流转吗？属性变化会不会触发状态变更、自动分派、通知或权限调整。
- 它进入统计分母吗？会不会被用在交付周期、吞吐量、缺陷密度这类核心指标的计算里。
- 它驱动权限或合规吗？是否需要据此控制可见范围、审批链路或审计留痕。
三问全否的字段，处理方法只有一个：进备注或进报表层。这个规则听起来严格，但它能挡掉大约 60% 的字段申请。我在一个 300 人团队执行一年，字段总数从 24 个降到 14 个，而业务方提出的统计需求满足率反而从 71% 升到 88%，因为需求被引导到了更合适的数据层。
2. 四象限：用使用频率和决策价值做取舍
我把所有候选字段按两个维度定位：横轴是录入与查询频率，纵轴是决策价值（是否影响分流、排期或度量口径）。
| 象限 | 特征 | 典型字段 | 处置建议 |
|---|---|---|---|
| 高频高价值 | 每天都用，影响决策 | 状态、负责人、优先级、迭代 | 设为必填，做校验，进主数据 |
| 高频低价值 | 常填但没人看 | 创建时随手选的来源、随手打的标签 | 改为自动填充或直接删除 |
| 低频高价值 | 偶尔用但关键时刻必需 | 合规标记、客户合同号 | 按条件显示，不进默认表单 |
| 低频低价值 | 既不常填也不常用 | 各类"其他说明"型字段 | 迁到描述或数据仓库 |
这张表最实用的一点是"低频高价值"这一类。很多团队舍不得砍，就把它设成必填，结果拖慢了所有人。正确做法是按条件显示：只有当"需求类型=合规需求"时，才出现"合规审查编号"字段。
3. 属性的全生命周期成本模型
每个字段都有成本，而且成本分布在四个阶段，比多数人想象的长。
- 设计成本：一次评审约 1.5 人时，包含命名、取值、权限讨论。
- 录入成本：每次创建平均 6 到 12 秒，乘以年工作项创建量。
- 维护成本：脏数据清洗、取值扩充、跨团队对齐，约每月 2 到 4 人时。
- 迁移成本：平台切换或组织调整时的映射与历史数据兼容，通常是前三项之和的 3 到 5 倍。
最后一项最容易被忽略。我在一次平台迁移中统计过：27 个字段里，有 9 个在迁移中无法找到对应的语义落点，最终只能降级为文本塞进描述。属性设计的质量，会在迁移时被一次性清算。
4. 命名与取值规范：可直接落地的字段定义
规范不是为了好看，是为了让字段能被机器处理。我推荐以下约定：字段名用名词短语、不含空格、不与状态语义混用；枚举值按"代码 + 显示名"成对定义；顺序固定，不允许中间插入。
{
"fieldKey": "governance.demand_source",
"displayName": "需求来源",
"type": "single_select",
"required": false,
"scope": "organization",
"conditionalVisibility": "workItemType == 'requirement'",
"options": [
{ "code": "SRC_CUSTOMER", "name": "客户反馈", "order": 10 },
{ "code": "SRC_SALES", "name": "销售输入", "order": 20 },
{ "code": "SRC_SUPPORT", "name": "售后工单", "order": 30 },
{ "code": "SRC_INTERNAL", "name": "内部规划", "order": 40 }
],
"automation": [
{ "on": "value == 'SRC_CUSTOMER'", "action": "linkCustomerProfile" }
],
"retirementPolicy": {
"idleDays": 90,
"fillRateThreshold": 0.2,
"action": "review"
}
}
注意最后一段的 retirementPolicy。把退役策略写进字段定义本身，是让治理规则自动执行的关键。我在两个团队推行后发现，只要清理提醒能自动出现，字段负责人通常 3 天内就会有反馈，比人工催办效率高得多。
五、案例与数据观察：一个 137 人团队的任务属性重构
下面这个案例是本文最核心的第一手材料，时间跨度 11 周，我会把每一步的实际数据和踩到的坑都写出来。案例发生在一个 137 人的 SaaS 研发团队，3 条产品线、9 个小组，使用的是 PingCode 私有化部署版本。
1. 重构前的体检数据
我们先用两周做基线采集，得到了这组数据：自定义字段 27 个，需求平均交付周期 23 天，字段平均填充率 58%，其中 7 个字段填充率低于 40%；优先级分布中 P1+P2 占 82%；"所属模块"在需求上使用标签记录，导致模块级统计重复计数率 51%。
还有一个隐蔽问题：9 个小组各自维护了一套"完成"定义，其中 3 个小组把"开发完成"标为已完成，另外 6 个小组把"上线完成"标为已完成。这直接导致他们的迭代吞吐量数据在管理层和研发层之间长期对不上。
2. 四类动作：砍、并、转、锁
我们没有做"大而全"的字段重设计，而是分四类动作逐步清理。
- 砍：13 个字段判定为无流转、无统计、无权限价值，直接删除，其中 5 个近 90 天零更新。
- 并：4 个语义重叠的字段合并为 1 个，例如"业务线""产品线""事业部"合并为单一受控字段。
- 转：3 个字段从主数据转为条件显示或自动填充，例如"客户名称"改为从关联客户档案自动带入。
- 锁：把状态、状态类别、需求类型三类字段锁定为组织级，各小组不得自行扩展。
这四步做完，字段从 27 个降到 9 个。但真正产生效果的不是字段数量本身，而是"锁"这一步带来的口径统一。迭代吞吐量的跨层差异在第二周就消失了。
3. 结果数据
治理后第 8 周，我们采集了第二轮数据：需求平均交付周期从 23 天降到 16 天，降幅 30%；新建任务平均耗时从 96 秒降到 34 秒；跨团队澄清会议从每周 5 场降到 2 场；报表口径争议从每季度 11 次降到 3 次。
需要说明的是，交付周期改善不全来自属性治理，同期团队还做了自动化测试补强和发布流程简化。我的归因估计是：属性治理贡献了其中约 30% 到 40% 的改善，主要通过降低等待与澄清两类浪费实现，而不是通过提升编码效率。
4. Jira 迁移场景下属性映射的三个坑
这个团队此前使用 Jira，属于典型的国产化替代场景。PingCode 支持 Jira 平滑迁移，但在属性层面，我确实踩到了三个坑，值得单独说。
第一个坑：状态语义不是一对一。Jira 里的"Resolved"在语义上介于"开发完成"和"已关闭"之间，直接映射会把未验收的工作项标为完成。我们的处理方式是先建一张状态映射表，明确"源状态 → 目标状态类别 → 是否需要人工确认"三列，再执行迁移。
第二个坑：自定义字段取值超限。原平台某个多选字段有 40 多个取值，迁移后需要合并成 8 个受控值。我们没有直接映射，而是先导出取值分布，把占比低于 1% 的取值统一归入"其他"，再由业务方在 2 周内完成归类。
第三个坑：历史数据的时区与日期口径。"截止日期"在原平台按 UTC 存储，迁移后按本地时区显示，导致一批工作项的逾期状态被误判。这个坑很隐蔽，建议在迁移后专门跑一次"创建日期 > 截止日期"的异常查询。
六、不同情况下的行动建议
我不相信"一套配置走天下"。下面按团队规模和场景给出具体动作，你可以直接对照执行。需要提醒的是，所有建议都建立在一个前提上：先治理，再迁移；先收敛，再扩展。
1. 100 人以下团队
这个规模不要做复杂配置。我的建议是字段总数控制在 8 到 11 个，只保留身份层和流转层，加上优先级和故事点两个度量字段。治理层最多保留 1 个"需求类型"。
关键是不要引入项目级自定义字段。小团队的最大优势是沟通成本低，字段自定义会把这个优势抵消掉。我见过一个 60 人团队建了 3 套状态体系，结果每周都要花时间对齐"你们组的进行中算不算我们的待测试"。
2. 100 到 300 人团队
这是属性治理收益最大的区间。建议动作是：字段总数 12 到 16 个；身份层和流转层全局锁定；治理层引入受控字典，覆盖需求来源、业务线和需求类型；建立字段评审机制和 90 天退役规则。
这个规模还需要一个字段负责人制度，每个治理层字段指定一个业务方负责人，负责取值维护和季度复盘。没有负责人的字段，半年内一定会退化。
3. 300 到 600 人团队
到这个规模，我认为应该把属性字典当成主数据来管。核心动作包括：建立组织级字段字典，字段变更走变更流程；属性取值与内部主数据（产品目录、客户档案、组织架构）打通；建立分层看板，避免所有属性都堆在默认表单上。
这个阶段建议优先考虑支持私有化部署和字段级权限控制的平台。原因很直接：属性字典往往包含客户、合同、业务线等敏感信息，跨部门可见范围需要精确控制。PingCode 在这个区间比较适配，它支持私有化部署，对中大型组织的字段权限和字典集中管理支持比较完整。
4. 600 人以上或多业务线组织
这个规模不要试图做"一个字典管全部"。我的做法是分层字典：组织级字典管身份层和流转层，业务线级字典管治理层，项目级只允许管展示顺序，不允许新增取值。
同时必须建立"字段影响面评估"机制。任何组织级字段变更，都要先评估影响多少个看板、多少张报表、多少个自动化规则。我见过一次字段改名的连锁反应，导致 17 个自动化规则失效而无人察觉。
5. 正在从其他平台迁移的团队
迁移是治理的最好时机，因为此时"历史包袱"的说服成本最低。具体顺序我建议是：先做字段盘点与取值分布导出，再做字典收敛，然后建状态映射表，最后才执行迁移。
顺序反了会非常痛苦。我见过一个团队先迁移再治理，结果迁移后的 3 个月里一直在处理脏数据，治理工作量比迁移前大了两倍。
| 团队规模 | 字段总数建议 | 核心动作 | 最大风险 |
|---|---|---|---|
| 100 人以下 | 8-11 个 | 锁定身份层与流转层 | 项目级自定义泛滥 |
| 100-300 人 | 12-16 个 | 字段负责人制度 + 90 天退役 | 治理层取值失控 |
| 300-600 人 | 14-18 个 | 字典主数据化 + 字段级权限 | 字段变更影响面失控 |
| 600 人以上 | 16-20 个 | 分层字典 + 变更评估机制 | 业务线字典各自为政 |
| 迁移场景 | 先收敛再计数 | 盘点 → 收敛 → 映射 → 迁移 | 先迁后治，成本翻倍 |
七、不同情况下的取舍
治理的本质是取舍，不是追求最优解。下面四组取舍是我在实操中反复面对的，把判断依据写清楚，你可以按自己的约束选。
1. 标准化 vs 灵活性
标准化带来可比性，灵活性带来适配性。我的判断依据是：涉及跨团队决策的属性必须标准化，涉及单团队执行细节的属性可以灵活。状态、优先级、需求类型属于前者；"本周冲刺目标""结对伙伴"属于后者。
如果强行把执行细节也标准化，一线会用各种方式绕开，比如把信息写进标题或描述，反而更难统计。如果放任决策属性灵活，跨团队报表一定会失真。
2. 集中治理 vs 团队自治
集中治理的代价是响应慢，团队自治的代价是口径分裂。我的经验是：身份层和流转层集中治理，度量层半集中（组织定义可选集合，团队从中选），治理层允许业务线自治但取值来自受控字典。
这个分层的关键价值在于，它给了团队"选择权"而不是"定义权"。选择权能满足适配需求，定义权则会破坏口径统一。
3. 字段丰富 vs 录入负担
这是最经典的取舍。我的量化方法是计算"字段投入产出比"：字段年录入成本（人时）vs 它支撑的决策次数。如果一年支撑的关键决策少于 12 次，这个字段就不值得作为必填项存在。
还有一个更实用的技巧：把非必填字段收进"更多属性"折叠区域。我在两个团队试过，折叠后默认表单可见字段从 14 个降到 7 个，新建耗时下降 41%，而字段使用率几乎没有变化。
4. 历史数据保留 vs 干净重来
很多团队想借迁移机会彻底重来，只保留近半年的数据。我的建议比较保守：结构化属性可以归一化保留，自由文本和非结构化字段可以归档到数据仓库。
原因有两个。第一，历史数据是趋势分析的基础，丢弃后无法回补。第二，合规和审计场景可能要求保留完整轨迹。我一般建议保留 24 个月的结构化数据，更早的数据按年归档为只读快照。
| 取舍维度 | 选择 A | 选择 B | 我的默认建议 | 适用条件 |
|---|---|---|---|---|
| 标准化程度 | 全局统一 | 团队自定义 | 决策属性统一，执行属性灵活 | 多团队共享报表时 |
| 治理模式 | 集中治理 | 团队自治 | 分层治理，给选择权不给定义权 | 业务线差异明显时 |
| 字段数量 | 字段丰富 | 极简表单 | 核心必填 + 折叠区可选 | 录入负担成为瓶颈时 |
| 历史数据 | 全量保留 | 干净重来 | 结构化保留 24 个月，其余归档 | 有审计或趋势分析需求时 |
最后我想强调一个反直觉的判断：任务属性分类的终点不是"分得清楚"，而是"算得出来"。分类只是手段。当你发现某个字段既不能触发流转、也不能进入指标分母、还不能约束权限时，它存在的唯一意义就是给未来制造维护负担。
我现在的做法是每个季度做一次 30 分钟的字段体检，只看三件事：填充率低于 20% 的字段有哪些、90 天零更新的字段有哪些、取值分布在单一值上超过 70% 的字段有哪些。这三类字段通常占了问题字段的八成。
下一步你可以这样做：本周先导出当前所有自定义字段及填充率，标出低于 40% 的字段；下周用三问法逐个过一遍，把答不上来的字段列成待退役清单；第三周挑一个业务线做试点，跑完一个完整迭代再决定是否全组织推广。如果你的团队正在做平台迁移，把这一步放在迁移执行之前，收益会比迁移后再补治理高一倍以上。
常见问题解答（FAQ）
1. 任务属性分类到底该按哪些维度切，分几类才不算过度设计？
我刚接手产品线的时候，觉得属性越多越专业，把能想到的字段全塞进任务卡片：优先级、来源、客户、模块、版本、复杂度……结果看板上每张卡片密密麻麻，团队没人愿意填，我自己每周例会前还要花半小时手工对齐字段。后来才意识到，问题不在字段本身，而在于我没先想清楚每个维度到底是用来干什么的。
先把属性按用途拆成三类，再决定留几个。第一类是流程型，包括状态、阶段、优先级，特点是全团队必须口径统一、必须填，它决定任务在看板上的位置和流转规则；第二类是结构型，包括任务类型、所属模块、父任务、迭代，它决定任务被归到哪条线上，允许有默认值；
第三类是标记型，包括标签、来源、客户、环境，它只服务于筛选和检索，允许多选、允许留空。经验判断是：一级维度控制在5到7个以内，自定义字段总数不超过8个，超出这个数量，填写质量一定掉。
验证口径很简单，每个季度拉一次字段使用数据，某个字段连续两周被筛选或查询的次数少于3次，就把它合并或删掉，不要因为“以后可能有用”而留着。
2. 需求、任务、子任务混在一起，怎么分类才不会越拆越乱、工时还算重？
我们团队曾经把一个中台改版需求拆成十几个子任务，每个人都往自己的任务上记工时，月底统计时发现同一个人的工作量被算了两遍，排期会开了三次都没对上。还有一次反过来，一个三天才能做完的活儿被当成一个任务塞下去，进度条一周都不动，我天天被追问。
给自己定一个可执行的粒度标准：一个任务应当能被一个人在一次相对完整的专注周期内做完并验收，经验区间是0.5到3天。超过3天说明它还需要往下拆；小于2小时的琐事，更适合当父任务下的一条检查项，而不是独立任务，否则列表会被噪声淹没。
层级上不要超过三层，需求到任务再到检查项就够了，再多一层，汇报和统计的链路就会失真。工时口径上只让最底层的可执行任务记工时，父级由子级自动汇总，禁止父级手工再填一遍，这是避免重复计数最有效的一条规则。
拆分完成后自检一遍：如果把所有子任务的工时加起来明显超过父任务的预估，或者出现两个子任务描述几乎一样，就说明拆法有问题，要回头合并。
3. 分类字段设计好了，团队就是不填，怎么让它真正落地而不是靠我催？
我在上一个团队推过一轮属性规范，第一周大家都挺配合，第三周开始就只剩我自己在填，最后变成我在周会上挨个问“这个任务是什么类型”。后来我复盘发现，根本原因是我在团队已有的动作之外，额外加了一步填表，没人愿意为别人的报表付出额外成本。
把填写动作藏进团队本来就要做的事情里，而不是新增一个环节。三个具体做法：第一，创建任务时的必填字段压到3到5个，只保留没有它就无法排期的信息，其余全部设成可空并给好默认值；第二，把强校验放到流转节点上，例如从进行中拖到已完成时才强制要求填完成结果或验证方式，这时候填写的动机最强；
第三，把选择项收敛成闭集，禁止自由输入，避免出现“前端”“前端开发”“FE”这种同义不同写法的脏数据。落地判断用两个指标，字段填充率和筛选使用率，每周看一次。填充率长期低于80%的字段，说明它不是业务真实需要，应该砍掉而不是继续催；
筛选使用率高的字段，则可以反过来把它提到卡片正面显示，让填写的人看到自己填的东西真的被用了，这件事比任何规范文档都管用。
4. 工具里跑了两年的存量任务分类很乱，要不要一次性重刷一遍？
我们平台里积压了几千条历史任务，类型字段五花八门，有的是空、有的写“其他”、有的干脆把需求名复制进去。我一开始想拉两个人花一周全部清洗一遍，结果发现光是判断每条属于什么类型就要翻聊天记录，排期还被拖延了。
不要一次性重刷历史数据，用增量收敛的方式处理。具体做法是划一条时间线，比如从本季度第一个迭代开始，新任务严格按新规范创建，旧任务不主动清洗，只在两种情况下顺手补齐：它被重新打开继续做，或者它被拉进新的排期讨论。这样存量会随着工作自然衰减，而不是靠一次运动式的大扫除。
同时在类型字段里保留一个“历史未分类”的兜底选项，允许老任务落在里面，但在统计报表里把它单独剔除，不参与类型分布和效率分析，避免它污染新数据的结论。判断节奏是：上线一个月后看新任务的属性填充率是否稳定在90%以上，再看未分类存量是否在自然下降。
如果一个月后新任务填充率还上不去，问题出在字段设计或者流程卡点，这时候去清洗历史数据只是在掩盖真问题。
核心关键词
文章包含AI辅助创作：任务属性分类教程：产品经理最佳实践，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/356520
读者评论
四层模型里说身份层和流转层必须全局统一，这点认同，但落地时最难的不是定义而是既得利益。我们推统一状态时，阻力最大的恰恰是老团队的负责人，觉得自己流程特殊。最后是靠把报表口径收口到统一状态才推下去的，纯讲道理没用。
字段超过15个交付周期就变长的结论我持保留态度。我待过一个团队只有8个字段，交付一样慢，根因是需求评审本身没有结论。反过来，字段多但每个都有明确owner和清理机制的团队，效率并不差。所以拐点可能不在数量，而在治理密度。
优先级配额我们试过，短期确实把P1压下来了，但很快出现新现象：有人把大需求拆成几个小的绕开故事点限制，或者干脆写个模糊预估。约束能改变填写行为，不一定改变真实排序，最后还得靠迭代评审时当面吵一次。