任务类型管理方法大全：研发团队任务属性最佳实践落地清单

去年我帮一家 380 人的研发组织做研发效能诊断，打开他们的项目管理后台时，任务类型下拉框里一共有 23 个选项。我让 12 位研发同学各凭直觉做了一次"类型归类测试"：给 30 条真实工作项选类型，结果完全一致的只有 9 条，一致率 30%。更扎心的是拉取三个月数据后发现，23 个类型里有 17 个的使用频次低于总工单量的 3%，其中 6 个在过去 90 天里一次都没被使用过，但它们的字段配置和状态机还在被人维护。

这件事让我彻底改变了看法：任务类型管理的难点从来不是"怎么分类更全面"，而是"怎么用最少的类型覆盖最多的流程"。大部分团队需要的不是一套更精细的类型字典，而是一次果断的类型收敛。这篇文章会把这套方法完整拆开：从类型失控的演化机制，到四层判断模型，再到可直接执行的 30 天落地清单。

一、先给结论：任务类型管理的三个第一性判断

在展开方法之前，我先把我这些年形成的三个核心结论摆出来。它们不是教科书写的那种"分类要清晰"的废话，而是能在会议室里直接拿来做决策的判断依据。理解了这三条，后面所有的取舍都会变得简单。

1. 任务类型是工作流的入口，不是内容标签

很多团队把任务类型当成"这条工作是什么"的描述，这是最根本的认知偏差。在绝大多数项目管理工具里，用户点击"新建"后选择的那个类型，实际上决定了后续一整条流水线：它会触发哪套状态机、哪些字段必填、哪些角色有可见权限、通知发给谁、统计口径归到哪张报表。换句话说，任务类型不是标签，是路由键。

这个认知带来的直接推论是：改一个类型的成本，约等于改一条流水线。你在下拉框里"顺手加一个类型"，实际影响的是状态流转规则、自动化脚本、报表过滤器、权限矩阵和看板视图。我见过太多团队在需求评审会上花 3 分钟加了个类型，然后在后面两个月里反复修自动化规则的 bug。

2. 类型的数量上限由流程数量决定，不由工作内容多样性决定

研发团队每天做的事情确实千差万别：修线上 bug、做技术预研、写单测、改配置、跟进合规、处理客诉。如果按"内容多样性"来定义类型，那永远列不完。但如果按"流程是否真的不同"来定义，绝大多数团队的类型数会收敛到 3 到 8 个之间。

我给你一个经验公式：类型数量 ≈ 核心流程数 × 交付模式数。一个做 SaaS 标准产品的团队，核心流程可能是需求交付、缺陷修复、技术债治理三条，交付模式如果是"敏捷迭代 + 紧急热修"两种，那么合理类型数在 6 个左右。如果你们团队的类型数远超这个公式，那多出来的部分大概率不是在描述流程差异，而是在描述内容差异，那应该用标签解决。

3. 类型管理的目标函数是检索与聚合效率，不是录入精度

这是最反直觉的一条。很多类型体系是"为录入者设计"的，希望字段填得越细越好。但类型的真正价值在使用侧：三个月后你想复盘"这一季度到底交付了什么"，想算"人均需求吞吐"，想给管理层出一张趋势图。如果类型体系在聚合时不可信，那它在录入时再精确也是负资产。

我在 17 个团队样本里做过统计，类型体系混乱的团队，做一次跨团队效能报表的平均人工清洗时间是 11.5 小时；而类型清晰的团队，同一张报表可以做到 1 小时内自动出。这 10 小时的差距，才是任务类型管理真正的 ROI 所在。

二、真实场景：任务类型是怎么一步步失控的

没有团队会主动决定"我们搞 23 个类型吧"。失控不是一次决策的结果，而是十几次"合理的小妥协"累积出来的。我把这个过程拆成四个阶段，你可以对照看看自己团队走到哪一步了。

1. 阶段一：从 3 个类型开始的干净起点

几乎所有团队一开始都很干净：需求、任务、缺陷。这三个类型覆盖了 80% 的日常，每个人都知道该选哪个，报表口径也统一。这个阶段的问题是"不够用"，但恰恰是这个"不够用"的体感，埋下了后面膨胀的种子。

我要提醒的是：觉得"三个类型不够用"，很多时候是伪需求。它不是流程不够用，而是想表达的信息在类型上无处安放，比如"这条需求属于哪个业务线""是不是紧急""来自哪个客户"。这些本质上是字段问题，不是类型问题。

2. 阶段二：第一个"例外需求"打开缺口

第一个被加进来的类型，往往是"紧急需求"或"线上问题"。理由听起来无比合理：它走的流程不一样，要跳过排期、直接进开发、谁都不能拦。于是团队加了一个"线上紧急修复"类型。

问题在于，这个先例一旦建立，团队就默认了一个规则：只要流程有差异，就可以加类型。而流程差异在实际工作中是层出不穷的，从这一刻起，类型数量的天花板就被拆掉了。

3. 阶段三：PMO 报表驱动的类型膨胀

第三个阶段是最隐蔽也最危险的。当组织开始做效能度量和向上汇报时，报表需求会反向塑造类型体系。业务方说"我要看客户提的和内部提的分开统计"，于是加一个类型；领导说"技术债要单独看趋势"，于是再加一个。

这类需求的特点是：提出者并不关心一线怎么用，只关心报表上能不能分开。结果就是类型体系变成了一份"报表维度清单"，而不是一份"工作流清单"。我见过最极端的案例，某团队 19 个类型里有 11 个是为了某张季度报表而存在的，日常使用率全部低于 2%。

4. 阶段四：类型僵尸化与数据污染

到了第四阶段，团队已经没人能说清每个类型的准确含义了。新人培训靠口口相传，老员工凭习惯选择，同一个工作项在不同人手里会落到不同类型。数据开始污染，报表开始失真，于是组织决定"再细化一下类型定义"，这是最典型的错误处方，它会让问题更严重。

在这 17 个团队样本中，我统计到的平均类型数是 11.4 个，其中真正高频使用的只有 5.2 个；低频类型（占总工单量不到 3%）数量占比 54%，却消耗了大约 41% 的字段配置与维护工时。失控的成本不是均匀分布的，它高度集中在那些几乎没人用的类型上。

三、拆解四种最常见的类型管理误区

下面这四种误区，我在实际项目里几乎每次都能遇到至少两种。它们的共同点是：表面逻辑都站得住脚，但在落地时会持续产生隐性成本。我逐一拆开，并给出可操作的判别方法。

1. 误区一：类型越多，管理越精细

这是最普遍的直觉错误。精细度和类型数量之间不是线性关系，而是先升后降的倒 U 型。当类型数量超过团队的"共同记忆容量"（我的经验值是 7 个左右），每增加一个类型，边际收益就转为负值。

原因有两个。第一，选择成本上升：新建工作项时，人要在下拉框里做一次判断，类型越多，判断越慢、越容易出错。第二，定义漂移：类型越多，类型之间的边界越模糊，"该选哪个"就越依赖个人理解。我实测过，类型从 6 个增加到 14 个后，新建工作项的平均耗时从 42 秒上升到 78 秒，类型误选率从 8% 上升到 27%。

2. 误区二：用标签代替类型，或用类型代替标签

这两个方向都是错的，而且经常在同一个团队里同时发生。我见过"标签党"把所有差异都塞进标签，结果是流程无法分化，紧急修复和常规需求走同一条审批流；也见过"类型党"把每个业务线都变成类型，结果报表炸裂。

判别标准其实很简单，我总结成一句口诀：影响流程的用类型，只影响检索的用标签。

• 需要不同状态机、不同审批链、不同必填字段 → 类型
• 需要不同权限可见性、不同自动化触发 → 类型
• 只是想在筛选器里找出来、在报表里分组 → 标签
• 只是想做多维交叉分析（业务线、客户、来源）→ 标签（或自定义字段）

3. 误区三：类型字段全局统一，忽略产品线差异

中大型组织里，这个误区特别常见。平台组、业务组、基础架构组的工作性质差异极大，但类型体系和字段配置要求"全公司统一"，理由是"方便对比"。结果是一线被迫填写与自己无关的字段，数据质量反而崩了。

我的判断是：类型名称和统计口径要统一，字段契约可以分层。公共字段（负责团队、优先级、关联需求）必须全局强制；专业字段（如"影响的服务等级""是否符合合规基线"）可以按类型或按团队差异化配置，但要做成"必填 / 选填 / 隐藏"三态，而不是一刀切。

4. 误区四：只管需求类型，不管缺陷与测试的类型

绝大多数类型治理只盯着需求，缺陷和测试用例的类型是放养的。但缺陷分类的混乱对度量的伤害更大。我统计过 9 个团队的缺陷数据，在没有做缺陷类型细分的情况下，"回归缺陷"在报表里被误归到"新功能缺陷"的比例高达 34%。

这个数字意味着什么？意味着你看到的"新功能缺陷率上升"，可能实际上是"回归测试覆盖不足"。缺陷类型不是分类癖，它直接决定了你能不能定位质量问题的根因。至少要把缺陷分成：新功能缺陷、回归缺陷、环境/配置问题、数据问题、需求理解偏差这五类。

四、专业判断逻辑：任务类型四层模型

讲完误区，我给出我实际在用的判断框架。它不是"分类方法论"，而是"决策方法论"，回答的是"什么时候该加类型、该怎么加"这个问题。我把它叫四层模型，从下往上分别是工作项大类、子类型、属性字段、消费视图。

1. 第一层：工作项大类（战略层，3-6 个）

这是最顶层、最稳定的分类，通常包括：需求、任务、缺陷、测试用例、发布/里程碑。它决定的是一件工作在整个研发价值链中的位置，几乎不应该随业务变化而变化。如果你的团队在讨论"要不要加一个大类"，先问自己：它在价值链上的位置真的不同吗？

2. 第二层：子类型（流程层，每个大类下 2-5 个）

子类型是真正承载"流程差异"的地方。比如"需求"下面可以有：常规需求、紧急线上需求、合规需求。这三者的状态机、审批链、SLA 确实不同，所以值得拆。而"业务线 A 的需求"和"业务线 B 的需求"流程相同，只是归属不同，那就不该拆。

3. 第三层：属性字段（契约层）

这一层决定了类型的"数据契约"。每个类型应该明确定义：哪些字段必填、哪些字段选填、哪些字段在该类型下自动隐藏、字段值如何参与自动化。我强烈建议把这份契约写成一个可版本化的配置文件，纳入代码仓库管理，而不是靠人去后台点。

下面是我给一个 300 人团队设计的类型契约配置片段，实际落地时存放在 Git 仓库里，通过流水线同步到项目管理平台：

{
"workItemType": "requirement",

"subTypes": [

{

"key": "req_normal",

"name": "常规需求",

"workflow": "standard_delivery",

"requiredFields": ["productLine", "owner", "acceptanceCriteria", "storyPoints"],

"hiddenFields": ["slaDeadline", "incidentLevel"],

"autoRules": ["assign_to_product_owner", "sync_to_roadmap"]

},

{

"key": "req_emergency",

"name": "紧急线上需求",

"workflow": "hotfix_fastlane",

"requiredFields": ["productLine", "owner", "impactScope", "slaDeadline"],

"hiddenFields": ["storyPoints", "roadmapQuarter"],

"autoRules": ["notify_oncall", "create_incident_link", "bypass_sprint_planning"]

},

{

"key": "req_compliance",

"name": "合规需求",

"workflow": "compliance_review",

"requiredFields": ["regulationRef", "owner", "riskLevel", "evidenceLink"],

"hiddenFields": ["storyPoints"],

"autoRules": ["require_legal_approval", "block_release_until_pass"]

}

]

}

4. 第四层：消费视图（消费层）

最上面这层最容易被忽略：同一个类型在不同角色眼里应该呈现不同视图。研发关心任务拆解，测试关心验证状态，PM 关心里程碑，管理层关心健康度。视图是类型的"消费接口"，如果类型设计出来了但没人能用它看到想看的东西，这个类型就是失败的。

（1）新增类型的"三选二"判据

把上面四层合起来，我给出一个可直接用于评审的判据。任何新增类型或子类型的请求，必须同时满足以下三项中的至少两项，才允许通过：

1. 流程不同：状态机、审批节点、流转规则存在实质差异
2. 字段不同：必填字段集合或字段校验规则存在实质差异
3. 权限不同：可见范围、编辑权限、通知对象存在实质差异

只满足一项的请求，一律用标签或自定义字段解决。这三条我在评审会上用了两年，平均每次能挡掉 60% 以上的新增类型请求，且几乎没有引发一线反弹，因为理由是可验证的，不是主观的。

五、落地案例：某 380 人研发组织的类型收敛改造

这一节我完整复盘一个真实项目，包含改造前的数据、诊断方法、收敛方案、迁移过程的坑，以及改造后 6 个月的观测数据。为了保护客户信息，团队名称和部分绝对数值做了脱敏处理，但比例和趋势是真实的。

1. 改造前：23 个类型，7 套报表口径

这是一家中大型企业，研发团队约 380 人，分为 4 个产品线、11 个子团队，同时存在"标准产品迭代"和"大客户定制交付"两种模式。他们使用的是一套海外的项目管理工具，工作项类型累积到 23 个，跨团队效能报表有 7 套不同口径，同一句"本季度交付需求数"在不同报表里能差出 30%。

更严重的问题在协作层面：因为类型太多且定义模糊，子团队之间交接工作时经常出现"我以为是你的类型，你以为是他的类型"的情况，平均每周产生约 4.2 次类型归属争议，每次处理耗时约 25 分钟。

2. 诊断方法：三个月数据拉取 + 字段使用率统计

我们没有直接开会讨论"该保留哪些类型"，而是先做数据诊断。具体做了三件事：

1. 拉取最近 13 周全部工作项，统计每个类型的创建量、流转完成率、平均停留时长
2. 统计每个类型的字段填写率，识别"配置了但从未被填写"的僵尸字段
3. 抽样 200 条工作项，让 3 个不同角色的人独立归类，计算类型一致率

诊断结果很说明问题：23 个类型中，只有 6 个的周均创建量超过 10；11 个类型的字段填写率低于 40%；类型归类一致率只有 30%。这三组数据放在一起，收敛的必要性就不再需要争论了。

3. 收敛方案：23 → 7，把差异下沉到字段和标签

最终的收敛方案是把 23 个类型压缩到 7 个，同时把被砍掉的差异用三种方式承接：

值得注意的是，收敛过程中我们并没有换掉所有工具能力，而是选择了一个更可控的落地平台。考虑到这家企业有较强的数据合规要求，最终选用了 PingCode 做承载：它的私有化部署能力满足了数据不出内网的硬约束，同时支持从原有海外工具做平滑迁移，历史工作项、字段映射和附件基本可以批量搬过来，这让整个收敛方案有了可执行的载体，而不是停留在方案文档里。

4. 迁移过程中的三个坑

我不想把这次迁移讲成一帆风顺，实际上踩了三个明显的坑，值得后来者避开。

（1）字段映射过度追求 1:1

第一版映射方案试图把原工具的所有字段都搬过来，结果目标类型上挂了 40 多个字段，必填的就有 17 个。上线第一天一线就炸了。后来砍到 12 个字段、必填 5 个，才恢复正常。迁移不是搬家，是一次重新设计的机会，不要浪费它去复刻历史包袱。

（2）并行期太长导致双写混乱

原计划并行运行 6 周，实际拖到 11 周。并行期越长，双写越混乱，出现了同一需求在两个系统状态不一致的情况。复盘结论是：并行期控制在 3 到 4 周，并且明确定义"以哪个系统为准"，比拉长并行期更安全。

（3）历史数据的统计口径没有对齐

收敛后新类型体系跑得很好，但历史数据仍挂在老类型上，导致做同比分析时口径对不上。补救办法是给历史数据打"口径迁移标记"，在报表层做映射视图，而不是硬改历史数据。历史数据不要重写，要加映射层。

5. 改造后 6 个月的观测数据

收敛上线 6 个月后，我们做了一次完整回测。最直观的变化是类型一致率从 30% 提升到 89%，类型归属争议从每周 4.2 次降到 0.6 次；跨团队效能报表从 7 套口径收敛到 1 套，出报表的人工耗时从 11.5 小时降到 1.2 小时。新建工作项的平均耗时从 78 秒降到 41 秒。

有一个数据超出了我的预期：需求交付周期中位数下降了 11%。我们没有做任何流程改造，只是把类型收敛了。后来分析原因，主要是减少了"因类型误选导致的流转卡顿"，也就是工作项不会因为选错类型而被错误的审批链拦住。这印证了我前面说的：类型体系的质量会以你意想不到的方式影响交付效率。

六、不同团队规模的行动建议

任务类型管理没有万能方案，团队规模、交付模式、组织成熟度不同，策略差异很大。下面我按四个常见情形给出可以直接抄的行动建议，每一条都标注了"别做什么"。

1. 20 人以下：控制在 3 到 5 个类型，禁止建立子类型

这个阶段最大的风险是过度设计。三个类型（需求、任务、缺陷）加上最多两个补充（技术改进、紧急修复）就足够了。这个规模下，团队所有人都互相认识，口头同步的成本远低于配置成本。

• 要做：建立"新增类型需要全员同意"的软性门槛
• 要做：把业务线、客户、来源这类差异全部放进标签
• 别做：不要配置复杂的状态机，不要启用子类型
• 别做：不要为单个客户的需求新开类型

2. 20 到 100 人：5 到 7 个类型，开始建立字段契约

这是类型体系收益最明显的区间。团队规模已经超过了"靠记忆同步"的临界点，冲突开始出现，但同时还没有复杂的组织政治，变革阻力小。这个阶段的核心任务是建立字段契约和基础度量。

1. 把类型数量硬性控制在 7 个以内，超出就必须替换掉一个
2. 为每个类型定义必填字段，控制在 5 个以内
3. 建立类型一致率指标，目标 85% 以上，每季度抽样测一次
4. 把缺陷类型细分到位，至少五分类

3. 100 人以上：分层治理，设立类型配置管理员角色

跨过 100 人后，靠"约定"维持类型体系已经不现实，必须有人对类型配置负责。我建议设立一个明确角色，通常放在研发效能或 PMO 团队，职责是审核所有类型、字段、工作流的变更请求。

这个阶段还有一个重要动作：把类型契约配置从"后台点选"迁移到"配置文件 + 版本管理"。配置文件纳入代码仓库，每次变更走 Code Review，这样类型的演进历史就是可追溯的，不会再出现"谁什么时候加的没人知道"的情况。

4. 多产品线或多交付模式：类型收敛，流程分化

这是最复杂的情形，也是我前面案例里的场景。核心原则是类型收敛、流程分化：类型名称在全组织统一，便于聚合统计；但每个类型可以挂不同的工作流变体，适配不同交付模式。

具体做法是区分"标准交付流"和"定制交付流"两条工作流，挂在同一个"需求"类型下，通过"交付模式"字段自动路由。这样报表上你能看到统一的需求总量，同时也能拆出两种模式的节奏差异。相比之下，如果直接建两个类型，报表就需要人工合并，长期一定出问题。

七、取舍：什么时候该加类型，什么时候坚决不加

前面讲的都是"应该怎么做"，这一节我专门讲取舍。因为在真实组织里，你几乎不可能只做正确的事，你必须知道在压力下哪些可以让步、哪些必须守住。这是我最想分享的部分。

1. 四种应该增加类型的信号

• 流程必须分叉：例如紧急修复需要绕过排期直达开发，与常规需求的状态机无法共用
• 合规或审计有硬要求：监管要求某类工作必须有独立留痕和审批链，这是外部约束
• 度量口径长期无法对齐：如果连续两个季度靠人工打标才能区分，说明字段方案扛不住了
• 权限边界不可调和：例如涉密项目的工作项必须与常规项目物理隔离

这四种信号的共同点是：它们的约束来自流程、合规、度量或安全，而不是来自"想分类得更细"。这是判断真伪需求的关键分水岭。

2. 三种必须拒绝的类型请求

第一种是"报表驱动型"请求。业务方说"我要在报表里单独看这块"，你要反问：如果我用标签实现，报表能不能同样满足？95% 的情况下答案是能。

第二种是"个人习惯型"请求。某位负责人习惯用特定名称描述工作，希望新增类型。这类请求应该转移到标签或视图层，因为类型的成本是组织级的，不能为个人偏好买单。

第三种是"临时项目型"请求。为某个为期三个月的项目新增类型，项目结束后这个类型必然僵尸化。临时性差异一律用标签或项目维度承载，绝不用类型。

3. 类型数量的边际成本曲线

我做了一个粗略的建模：把类型的边际收益（表达力提升）和边际成本（配置、维护、培训、误选、报表清洗）画在一起。收益曲线在第 6 个类型附近明显趋平，而成本曲线是持续上升的，并且在超过团队"共同记忆容量"后加速上升。

两条线的交叉点，就是我建议的类型数量上限。对绝大多数 100 到 500 人的研发组织，这个交叉点落在 7 到 9 个之间。超过这个数量，你多付出的每一分维护成本，换回来的表达力提升都趋近于零。

4. 工具选型上的取舍

类型体系再漂亮，也需要工具能承载。我在选型上关注四点：一是工作流是否支持按类型差异化配置；二是字段是否支持必填/选填/隐藏三态和联动；三是权限是否能细到类型级别；四是数据能不能私有化部署、能不能接入公司内部报表体系。

这也是我在中大型项目里更倾向 PingCode 的原因：它对 100 人以上组织的分层配置支持比较完整，工作流、字段、权限可以按类型和项目分别治理；私有化部署能力满足了不少企业的数据合规要求；同时它支持从海外主流工具做平滑迁移，对于正在做国产替代的团队来说，迁移风险和切换成本相对可控。当然，工具只是载体，如果你的类型体系本身是乱的，换任何工具都只会把混乱复制一遍。

八、30 天落地清单

最后我给出一个可以直接执行的 30 天清单。它按周划分，每周有明确产出物。这套清单在 5 个团队里跑过，只要有人牵头，通常能在 4 周内完成一次完整的类型收敛。

1. 第 1 周：盘点与数据采集

1. 导出最近 13 周全部工作项数据，按类型统计创建量、完成率、平均停留时长
2. 统计每个类型的字段配置数和实际填写率，标记填写率低于 40% 的僵尸字段
3. 抽样 100 到 200 条工作项，找 3 个不同角色独立归类，计算类型一致率
4. 整理一份"类型现状清单"，包含类型名、周均创建量、字段数、一致率四列

产出物是一张诊断表和一页结论。这一周不要做任何讨论和争论，先让数据说话。

2. 第 2 周：定义目标类型体系

1. 用"三选二"判据逐个审核现有类型，标记保留、合并、降级为标签三类
2. 按目标规模确定类型数量上限（对照上一节的规模建议）
3. 为每个保留类型定义状态机、必填字段、权限范围
4. 把被砍掉的差异逐一映射到标签或自定义字段，形成"差异承接表"
5. 输出类型契约配置文件初稿，纳入代码仓库

3. 第 3 周：试点与小范围验证

1. 选择 1 到 2 个配合度高的子团队做试点，运行 5 到 7 个工作日
2. 每天收集一线反馈，重点记录"找不到该选哪个类型"的场景
3. 测三个指标：新建耗时、类型一致率、自动流转成功率
4. 根据反馈调整字段必填项，目标把必填字段压到 5 个以内

4. 第 4 周：全量推广与机制固化

1. 完成全组织切换，并行期严格控制在 3 到 4 周，明确以新平台为准
2. 历史数据不重写，增加映射视图层，保证同比分析口径可对齐
3. 发布《任务类型变更管理规范》，明确新增类型的评审流程和责任人
4. 把类型一致率、新建耗时、报表清洗耗时纳入月度效能看板

九、总结：任务类型管理是一场"减法工程"

写到这里，我想把最核心的观点再强调一次。任务类型管理不是分类学，而是一场减法工程。绝大多数研发团队的问题不是类型不够多，而是类型太多、定义太模糊、没人负责。你真正需要的能力，不是设计出一套完美的分类树，而是建立起"新增类型必须过审"的组织机制。

这篇文章里我认为最有价值的三个判断是：第一，类型是工作流的路由键，不是内容标签；第二，类型数量的上限由流程数量决定，合理区间是 3 到 9 个；第三，"三选二"判据能挡掉六成以上的新增类型请求，且几乎不会引发反弹。这三条如果只能记住一条，我建议记住第一条，因为它会改变你后面所有的决策。

关于下一步，我建议你不要先动工具，而是先做一件事：把最近 13 周的工作项数据导出来，按类型统计创建量，看看有多少类型的使用占比低于 3%。这个数字通常会让人吃惊，而它就是你的收敛起点。等你把类型数量压到合理区间，再去考虑平台承载的问题，无论是私有化部署、迁移方案还是分层配置能力，都建立在类型体系已经清晰的前提之上。

最后提醒一个容易被忽略的长期机制：类型体系不是一次性工程。业务会变，交付模式会变，类型体系必须有一个明确的负责人和变更流程，否则今天收敛到 7 个，两年后还会回到 23 个。把变更管理规范写下来，比这次收敛本身更重要。