任务类型管理方法大全：实施团队任务属性落地方案落地清单

上个月我在一家做智慧园区交付的公司做流程复盘，项目经理翻开后台给我看了一屏截图：任务类型一共 47 个，其中 19 个在最近 90 天里创建任务数为 0，还有 6 个类型只被同一个人用过。更有意思的是，他们的周报里同时出现「需求」「需求变更」「客户需求」三个类型，三个类型下面的任务加起来才 130 条。我问负责统计的小组长，这三个怎么区分，他想了十秒说：「看创建的人是谁。」

这不是个例。过去几年我参与过十几家实施交付型团队的研发与项目管理系统治理，从 30 人的小团队到 800 人的多事业部组织都见过，任务类型管理失败的原因几乎从不是「类型不够用」，而是「类型没有被当作契约来设计」。它被当成了标签，于是所有人都能加，没人负责删，最后变成一套只有历史包袱、没有管理价值的名词表。

这篇文章我想把任务类型这件事讲透：从判断逻辑、落地清单、权限矩阵到迁移取舍，给出一套可以直接拿去用的方案。全文基于我自己经手的项目数据、踩过的坑和复盘结论，涉及工具的部分会以 PingCode 为例说明中大型团队怎么落地。

一、先给结论：任务类型不是分类标签，而是工作流契约

我先把最核心的判断放在前面，后面的所有内容都是围绕这几条展开的。如果你只读这一段，也足够做出一次正确的决策。

1. 三个可以直接拿去用的结论

第一，任务类型的本质是「字段集 + 状态机 + 权限 + 度量口径」的四位一体契约，而不是一个分类字段。判断一个类型该不该存在，只要看它是否带来了这四者中至少一项的差异。如果四项全都一样，它就不该是一个类型，而应该是一个属性值。

第二，实施交付团队的任务类型数量应该收敛在 6 到 10 个之间。这是我在多个 100 至 500 人规模团队里反复验证过的区间。低于 6 个，跨部门交付物会被挤压进同一个类型，导致字段被迫冗余；高于 10 个，新人选错类型会成为常态，报表口径开始互相打架。

第三，类型治理不是一次性项目，而是季度动作。类型的腐烂速度比大多数人想象得快，一般在系统上线后第 4 到第 7 个月进入失控期。没有季度瘦身机制，两年后的类型表一定是一团乱麻。

2. 任务类型管理的四层结构

我习惯把这件事拆成四层来看，从下往上依次是：数据层、流程层、权限层、度量层。很多团队只做了最上面半层，所以系统看起来配好了，实际用起来全是补丁。

• 数据层：类型自带哪些字段、字段是必填还是选填、字段的取值来源是枚举还是级联。
• 流程层：这个类型的状态迁移路径是什么、是否需要评审节点、是否有终态回退。
• 权限层：谁能创建、谁能流转状态、谁能修改关键字段、谁能删除。
• 度量层：这个类型的任务进入哪张报表、按什么口径统计工时和交付周期。

四层里最容易漏的是度量层。我见过太多团队把类型配得很漂亮，结果到了月底做交付分析，发现「实施工单」和「现场支持」被混在一个类型里统计，交付周期被拉长了一倍还找不出原因。

3. 为什么我把「类型爆炸」列为第一号风险

类型爆炸的代价不是多几个下拉选项那么简单。它会产生一条隐蔽的成本线：每个成员在创建任务时都要花时间做「这个任务该选哪个类型」的判断，判断错了还要有人回捞数据。这条成本线会随着人数和任务量线性放大，最终变成一笔没人算过、但确实存在的组织税。

我做过一次粗测：在一个 180 人的实施团队里，把任务类型从 47 个压缩到 9 个之后，单条任务从「打开创建页」到「保存成功」的平均耗时从 6.8 分钟下降到 2.2 分钟。按每人每天创建 1.5 条任务、每年 240 个工作日计算，一年省下来的是接近 6000 小时的净时间。

二、真实场景：实施团队的任务属性为什么总在第三个月失控

要讲清楚方法，先得讲清楚失控是怎么发生的。任务类型失控从来不是某一天突然崩溃，而是一条可以清晰划分的时间曲线。

1. 我经历的三个典型阶段

第 1 到第 2 个月是蜜月期。系统刚上线，大家还在新鲜劲儿上，类型表通常只有 4 到 6 个，配置简单，谁都能上手。这时候的问题是反的：类型不够细，交付经理抱怨「现场支持」和「远程排查」混在一起，没法统计成本。

第 3 到第 6 个月是扩张期。业务侧开始提需求：「能不能加一个类型，专门放客户培训？」「变更单能不能单独拆出来？」每一次都合理，每一次都只有一个人提，加到第 12 个类型的时候，没人记得为什么要分这么细。

第 7 个月之后是失控期。典型信号是新人入职第二周还在问「这个任务我该建哪个类型」，而老员工的回答是「你随便建一个，反正报表那边会手动归口」。一旦出现这句话，系统里的数据就已经不可信了。

2. 失控的四个具体信号

1. 空类型率超过 25%：90 天内零创建的类型占比过高，说明类型表里存在大量历史遗迹。
2. 单人类型：某个类型的所有任务都由同一个人创建，本质上是个人快捷方式，不是组织语言。
3. 字段完整率低于 70%：关键字段大面积留空，说明必填策略或者字段本身设计有问题。
4. 报表需要人工修正：月度交付报表发布前需要有人手动调口径，这是最严重的信号。

3. 一条被忽略的成本线：状态推断成本

我在做流程诊断时，习惯先测一个指标：状态推断耗时。定义很简单，当一个人看到一条任务时，需要多久才能判断出「它现在处于什么阶段、下一步该谁动」。

这个指标之所以关键，是因为它直接决定了站会和周会的效率。在类型混乱的团队里，一场 30 人的交付例会，可能有四分之一时间花在「这条任务到底算不算完成」的争论上。按 30 人 × 1 小时 × 每周 1 次计算，一年就是 1440 人时的纯消耗，而这些时间没有产出任何交付价值。

三、常见误区：八个看起来合理、实际拖垮交付的动作

下面这八条，我在不同的团队里几乎都见过至少三条同时存在。它们的共同点是：单看每一条都很有道理，合在一起就是灾难。

1. 误区一：把优先级、模块、迭代当成任务类型

这是最常见的一种混淆。优先级是单值枚举，模块是归属维度，迭代是时间盒，三者都不承载独立的状态机和字段集。把它们做成类型，会让类型数量以乘法方式膨胀：4 个优先级 × 6 个模块，理论上就有 24 个类型组合，没人能维护。

判断标准很朴素：如果两个对象的字段集完全一致、状态迁移路径完全一致，那它们就应该是同一个类型下的不同属性，而不是两个类型。

2. 误区二：类型越多越精确

精确是报表的需求，不是创建者的需求。很多团队把「分类精确」和「管理精确」画了等号，结果是一线在承担全部的采集成本，而管理侧拿到的是完整率只有 61% 的脏数据。

真实情况往往是反的：类型数量减少之后，数据质量反而提升，因为每一类任务都有人真正在意它的字段填得对不对。

3. 误区三：类型只做分类，不做字段差异

如果「需求」和「缺陷」用的是同一套字段，那它们在数据层没有任何区别，唯一的价值就是筛选器里的一个下拉框。这时候应该问的是：为什么不合并成一个类型，用「类别」属性区分？

真正需要独立成类型的对象，一定带着只属于它的字段。比如「实施工单」需要客户环境版本、上门时间窗、客户联系人；「缺陷」需要复现步骤、影响版本、严重程度。这些字段在对方类型里是噪音。

4. 误区四：所有字段都设必填

必填项是表单税。每增加一个必填字段，就等于在所有人的创建动线上设了一道关卡。我的经验值是：单个类型的必填字段不要超过 6 个，选填字段总数控制在 12 个以内。

更关键的是要区分「必须当场填」和「可以后补」。像「根因分析」「验收结论」这类字段，本就不该出现在创建表单里，它们属于状态流转时的关卡字段。

5. 误区五：状态机一套走天下

所有类型共用一套状态机，看起来简洁，代价是流程失真。缺陷需要「已验证 / 已关闭 / 不予修复」，实施工单需要「已排期 / 已出发 / 已完成 / 客户确认」，用同一套状态硬套，结果是所有人都在用备注代替状态。

我的建议是把状态机数量控制在 3 到 5 套：需求类、缺陷类、交付执行类、变更与风险类，剩下的小众类型挂靠到最接近的一套。

6. 误区六：用子任务代替类型

子任务适合拆解「同一件事的多个步骤」，不适合承载「不同性质的工作」。我见过把「客户验收」做成「开发任务」的子任务，结果验收环节的耗时、责任人、客户签字字段全部丢失，交付周期分析里永远是缺失的一段。

7. 误区七：字段加了就没人删

字段只会增加不会减少，这是系统的固有趋势。原因是加字段的人有 KPI，删字段的人没有。我在一家公司见过一个叫「备注 2」的字段，连续 14 个月零填写，但没人敢删，因为「万一有人用呢」。

解法是把删字段变成一个固定动作：每个季度调一次字段引用率，连续两个季度引用率为 0 的字段，默认进入下线流程，而不是继续保留。

8. 误区八：没有类型 Owner

没有明确 Owner 的配置项，一定会腐烂。任务类型表需要有一个人对它负责，通常是交付运营或 PMO 的角色，权限上他应该能审批新增类型、合并类型、下线字段。

四、专业判断逻辑：三问法决定建类型还是加属性

方法要能落地，必须有一套能在 5 分钟内做完的判断。我常用的是一套「三问法」，任何人在提新建类型需求时，都要先回答这三个问题。

1. 第一问：它有没有独立的状态迁移路径

举一个具体例子。有一个团队想新增「客户培训」类型，我问他：培训任务的状态和标准交付工单有什么不一样？他想了半天说：好像一样，都是从待排期到已完成。

那答案就出来了：状态迁移路径完全一致的对象，不需要独立类型。它应该成为「交付工单」类型下的一个「工作类别」属性值。

反过来，「变更单」就有明显差别：它需要「提交 → 评估 → 报价 → 客户确认 → 实施 → 归档」，中间有两个审批关卡，而且可以在客户拒绝时进入「已拒绝」终态。这就是独立状态机。

2. 第二问：它有没有独立字段集

这一问的判断标准是：这个对象需要的字段里，是否至少有 3 个字段在其他类型里会造成噪音或长期留空。

「现场实施工单」需要客户环境 IP、上门时间窗、客户现场联系人、是否需要携带备件；这四个字段放在「需求」类型里毫无意义。这就是典型的独立字段集。

3. 第三问：它有没有独立度量口径

这一问最容易被忽略，但价值最高。如果一个对象需要单独计算「平均交付周期」「一次性通过率」「返工率」，那它必须独立成类型，否则报表口径无法隔离。

我见过一个反例：某团队把「返工任务」和「新增开发任务」放在同一个类型里，结果算出来的交付周期永远比实际短 30%，因为返工任务的周期天然更短，把平均值拉下来了。管理层拿着这个数字做产能规划，直接导致下个季度人力排布失误。

4. 三问之后的补充判断：跨项目复用率

还有一条我习惯放在最后确认：这个类型在多个项目或产品线之间是否具有通用性。如果它只在某一个客户项目里成立，那它更适合做成标签，而不是全局类型。

全局类型表是一个公共资源，任何一次新增都在增加所有人的认知负担。如果只是局部需求，用标签或自定义字段就能解决，不必上升到类型层。

5. 类型与属性的决策树

把四问串起来，就是一棵可以直接贴在墙上的决策树：

1. 是否有独立状态迁移路径？是 → 进入第 2 问；否 → 降级为属性。
2. 是否有 3 个以上专属字段？是 → 进入第 3 问；否 → 降级为属性或标签。
3. 是否需要独立度量口径？是 → 进入第 4 问；否 → 降级为属性。
4. 是否跨项目通用？是 → 可以建类型；否 → 用项目级标签。

四个问题全部为「是」，才建新类型。这个标准看起来严格，但它能把类型数量控制在可控范围内。我经手的团队里，用这套决策树通常能把新增类型需求砍掉六成以上。

五、落地清单：从类型清单到权限矩阵的七步实施法

前面讲的是判断逻辑，这一节给可以直接执行的清单。我按顺序拆成七步，每一步都给出可交付物，做到哪一步算完成是明确的。

1. 第一步：盘点交付物，而不是盘点工作

这是最容易被跳过、但最影响结果的一步。很多团队盘点的对象是「大家在做什么」，得到的是动作清单：写代码、开评审会、上门调试、写文档。这些是动作，不是交付物。

正确的盘点对象是「团队要对外交付的东西」：一个可上线功能、一份缺陷修复、一次环境部署、一次客户培训、一份变更方案、一次上线保障、一份验收报告。

具体做法是：拉取过去 6 个月的全部任务标题，做一轮词频聚类，通常能自然聚出 8 到 15 个交付物族群。这一步建议至少两个人独立做一遍再合并，避免被个人视角带偏。

2. 第二步：定义类型清单

把上一步的族群按三问法筛选，就得到最终类型清单。我给实施交付团队的推荐清单如下，实际使用中可以根据业务裁剪：

九个类型，对应四套状态机。如果你所在团队只能记住一个数字，就记住「类型数不超过 10，状态机不超过 4」。

3. 第三步：设计属性集，按三级分级

字段设计我习惯分成三级，级别决定了它的必填策略和生命周期：

• L1 关键字段：直接进入报表、直接影响决策，必填，不允许下线。每个类型控制在 3 到 6 个。
• L2 业务字段：支撑业务判断但不进入核心报表，选填，可由项目经理按项目启用。
• L3 辅助字段：用于补充说明，选填，允许在季度审查中被批量下线。

我用一个具体的字段配置举例，说明 L1 和 L2 的差别。下面这段是实施工单类型在配置导入时的结构示例，可以直接对照自己系统的字段配置页面看：

任务类型: 实施工单
L1 关键字段:

客户名称 (必填, 关联客户库, 进入交付报表)

工单类别 (必填, 枚举: 部署/调试/巡检/培训/应急)

计划上门时间 (必填, 日期时间, 进入排期看板)

实际完成时间 (流转时必填, 进入交付周期口径)

L2 业务字段:

环境版本 (选填, 单行文本)

是否需带备件 (选填, 布尔)

客户现场联系人 (选填, 人员引用)

L3 辅助字段:

备注 (选填, 多行文本)

关联工单号 (选填, 单行文本, 历史遗留)

4. 第四步：设计状态机

状态机的设计原则是「状态数量 = 真正需要被区分的阶段数」，不多不少。每个状态必须能回答一个问题：谁在等谁。

如果某个状态无法回答这个问题，它就是个假状态。比如「处理中」这种状态，既不知道谁在动，也不知道要等到什么时候，本质上等价于「未完成」。

5. 第五步：设计权限矩阵

权限是类型落地里最容易被糊弄的一环。我建议把权限拆成四个动作来配置：创建、流转、改字段、删除。

这张表的价值在于：它把「谁改了什么」变成可追溯的动作，而不是所有人都能改所有东西。我见过太多团队因为权限全开，导致关键字段被改得无法回溯，最后做不了任何归因分析。

6. 第六步：数据迁移与字段映射

如果是新建系统，这一步可以跳过；如果是迁移或者从其他项目管理平台搬迁，这一步决定成败。迁移的核心不是把数据搬过去，而是把旧结构映射到新结构。

我的做法是先出一张映射表，明确三件事：旧类型映射到哪个新类型、旧字段映射到哪个新字段、无法映射的历史数据落到哪个归档类型。无法映射的数据不要硬塞，单独建一个只读的「历史归档」类型，保证可追溯但不参与统计。

7. 第七步：治理机制与季度瘦身

最后一步是让它能自我维持。我建议固化三个动作：

1. 季度字段引用率审查：连续两个季度引用率为 0 的 L3 字段，进入下线流程。
2. 半年类型审查：空类型率超过 25% 时，启动类型合并。
3. 变更留痕：任何新增类型都必须记录提出人、业务场景、预期使用频次，便于半年后回溯。

六、案例与数据观察：一次 180 人实施团队的属性改造

前面讲的是方法和清单，这一节讲一个完整的落地过程。这家公司做智慧园区与安防系统交付，180 人，3 个交付中心，年交付项目约 240 个，项目平均周期 3 到 5 个月。

1. 改造前的基线数据

我第一次进场时记录的数据是这样的：任务类型 47 个、共用状态机 12 套、单个类型平均字段数 43 个、字段平均完整率 61%、月度交付报表需要人工修正 11 次、项目经理平均每周花 4.5 小时在数据核对上。

更麻烦的是，他们的排期看板已经没人看了，因为「实施工单」下面有 60% 的任务根本没有计划时间字段，看板排出来的结果和现实完全对不上。

2. 改造动作与时间线

整个改造分三期，总共花了 6 周：

• 第 1 至 2 周：交付物盘点与类型合并，47 个类型收敛到 9 个，被合并的类型统一映射关系，写入迁移映射表。
• 第 3 至 4 周：字段分级与瘦身，单类型字段从平均 43 个压到 18 个，其中 L1 必填字段平均 5 个。
• 第 5 至 6 周：状态机归并与权限矩阵配置，12 套状态机合并为 4 套，完成权限校验与灰度上线。

3. 改造后的三组数据

改造完成 8 周后，我们做了一次对照测量，取的是稳定运行后的数据，排除了上线初期的波动。

这里面我最在意的是关键字段完整率的变化。它不是靠加强考核实现的，而是因为必填字段从平均 22 个降到 5 个之后，人真的愿意填了。数据质量的提升，本质上来自采集成本的下降，而不是来自纪律的加强。

4. 为什么我在这类团队里推荐 PingCode

这个案例里团队最终选用的就是 PingCode。我推荐它有几个具体理由，不是泛泛的「功能全」。

第一，它面向的正是 100 人以上的中大型组织和多项目并行的交付团队，任务类型、字段配置、状态机、权限矩阵这几层是分开配置的，不会像轻量工具那样逼着你在「类型」和「标签」之间二选一。上面那张权限矩阵表，在这类平台上是可以按角色和动作逐项配出来的。

第二，支持私有化部署。实施交付团队经常要处理客户现场信息、客户联系人、环境版本这类敏感字段，能不能把数据放在自己的机房里，往往直接决定方案能不能通过安全评审。这一点对金融、政务、能源行业的交付团队尤其关键。

第三，支持从 Jira 平滑迁移，是国产替代里比较省心的选择。这个案例的团队原本就在用 Jira，18 万条历史任务的类型和字段需要映射过来。他们的迁移过程没有推倒重来，而是先做结构映射、再灰度切流，历史数据在归档类型下保持可查但不参与统计，这一点对报表连续性非常重要。

我要说明的是，工具本身不是决定因素。换工具解决不了类型设计问题，它只能让你设计好的结构落地得更顺。如果类型表本身是乱的，迁到任何平台上都会继续乱。

5. 迁移过程中的两个坑

第一个坑是状态名称不同但语义相近，被强行合并。他们原来的「已解决」和「待验证」在新结构里被合并成了「待验证」，结果质量团队和交付团队对这个状态的理解不一致，交付侧以为已经完事，质量侧还在等验证。后来拆回两个状态才解决。教训是：合并状态之前，一定要让双方各自描述一遍「在这个状态下我会做什么」。

第二个坑是历史数据回填。迁移完成后，有大约 7% 的历史任务因为缺少新结构的必填字段而显示异常。我们的处理方式不是补数据，而是把这批数据标记为「历史归档」，走单独的只读视图。硬补数据的代价远高于它的价值，而且会污染新结构的统计口径。

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

方法不能一刀切。同一套清单放到 20 人团队和 500 人组织里，执行方式完全不同。下面按规模分四种情况给建议。

1. 20 人以下团队

这个阶段的团队不要做复杂的类型设计。建议只保留 4 到 5 个类型：需求、缺陷、任务、工单，全部共用一套状态机，字段总数控制在每个类型 6 个以内。

这个阶段真正要建立的是「类型语义共识」，也就是让所有人对「什么算需求、什么算工单」有一致的理解。别急着配权限矩阵，也别急着做字段分级，那都是规模化之后才需要的工具。

2. 20 到 100 人团队

这个阶段开始出现跨项目复用的问题，可以引入 6 到 8 个类型和 2 到 3 套状态机。重点动作是建立字段分级，把 L1 关键字段固定下来，因为它决定了你能不能让报表自动化。

同时建议指定一个兼职的类型 Owner，通常是 PMO 或交付运营。不需要专职，但必须有明确的人对配置变更负责。

3. 100 到 500 人的多项目交付团队

这是任务类型管理收益最明显的区间。建议按本文第五节的七步法完整做一遍，类型数收敛到 8 到 10 个，状态机 4 套，权限矩阵按角色和动作配置。

这个阶段一定要建度量口径的隔离。把返工、变更、现场支持这三类任务单独统计，否则交付周期数据一定失真，而失真数据会直接影响产能规划。这个规模的团队通常也到了需要私有化部署和国产替代评估的阶段，选型时要把字段配置能力、状态机独立性和迁移工具链作为硬指标来看。

4. 500 人以上或多事业部组织

这个规模下，全局类型表要极度克制，我建议全局类型控制在 8 个以内，事业部差异通过项目级字段模板实现。多事业部的交付物差异往往很大，硬做统一类型表的结果是所有人都妥协，最后没人满意。

可行的做法是「全局类型 + 事业部字段模板 + 项目级标签」三层结构。全局类型保证跨事业部报表可比，事业部字段模板保证各自的业务需求被满足，项目级标签保证临时需求不需要动全局配置。

5. 正在做国产替代迁移的团队

迁移场景有它的特殊性：你面对的不是一张白纸，而是一堆已经沉淀了几年的配置和历史数据。我的建议是把迁移当成一次治理窗口，而不是一次平移。

具体做法是：先做结构映射方案，而不是直接导数据；能合并的类型坚决合并，能下线的字段坚决下线；历史数据单独建归档类型，只读、可查、不进统计。迁完之后你会发现，系统的使用体验比改造前好一大截，因为你在迁移过程中顺手把债务清掉了。

八、不同情况下的取舍

任何方案都有代价，把取舍讲清楚比给一个「最佳实践」更有用。下面五组取舍是我在实际项目里反复面对的。

1. 字段粒度 vs 采集成本

字段越细，报表越有解释力，但采集成本越高。我的经验分界线是：如果一个字段在三个季度内从未被用于任何决策，就应该下线。不要用「以后可能会用」来保留它，那个以后几乎不会来。

2. 类型数量 vs 学习成本

类型越少，上手越快，但跨部门交付物容易被挤压；类型越多，分类越精确，但新人学习成本上升。我建议按「新人第一次选对类型的准确率」来判断：如果低于 80%，说明类型表已经超出团队认知负荷了。

3. 流程刚性 vs 一线灵活性

强流程能保证数据质量，但会拖慢一线响应速度。我的处理方式是分层：L1 关键字段走强约束，L2、L3 字段允许先建后补。这样既保住了核心数据，又不会让一线在紧急场景下被表单卡住。

具体来说，紧急工单可以先只用「客户名称 + 工单类别」两个字段建档，剩余字段在 24 小时内补齐。这个规则要写进流程，而不是靠人自觉。

4. 全局统一 vs 项目自治

全局统一有利于横向对比，项目自治有利于贴合实际。我的建议是：状态机全局统一，字段可以项目级扩展，但扩展字段必须挂在 L2 或 L3 层，不能新增 L1 字段。这样既保留了可比性，也给了项目空间。

5. 自动化规则 vs 人工判断

自动化能减少重复劳动，但过度自动化会让异常无处安放。比如「任务超期 3 天自动升级优先级」这类规则，在多项目并行时经常造成优先级通胀，所有任务最后都是最高优先级。

我的建议是只对两类动作做自动化：状态自动流转（比如子任务全部完成时父任务自动流转）和通知提醒。涉及优先级、资源分配、进度承诺的判断，保持人工。

九、结语：先把类型表砍到 10 个以内，再谈别的

回到开头那家公司。他们把类型从 47 个砍到 9 个之后，我问项目经理最大的感受是什么。他说了一句话我印象很深：「以前我们是在用系统记录工作，现在是在用系统管理工作。」

这就是任务类型管理的分水岭。记录型系统的标志是「什么都能建」，管理型系统的标志是「建之前要先想清楚」。类型表的长度，本质上反映的是团队对自身交付物的理解深度。

我的独特观点可以概括成一句：任务类型不是给人看的分类，而是给系统用的契约。判断一个类型该不该存在，永远不要问「它是不是一种不同的工作」，而要问「它有没有不同的状态机、字段集和度量口径」。

如果你准备动手，下一步我建议按这个顺序做三件事：

1. 今天就拉出过去 6 个月的任务标题，做一轮交付物盘点，把结果和现在的类型表做对照。
2. 本周内对每一个现存类型问一遍三问法，把四问全部为「否」的类型标记出来，作为第一批合并对象。
3. 本月内定下类型 Owner，并把季度字段引用率审查写进例会议程，这是让方案活下去的唯一保障。

不要一次做完所有事。先砍类型数量，再修字段分级，最后补权限和度量，这个顺序错了的话，你会在中途被一线的抱怨拖垮。按顺序来，六周时间足够一个 200 人的交付团队完成一次彻底的类型治理。