执行人最佳实践：产品经理任务管理流程优化，常见问题

产品经理的任务管理，最贵的成本从来不是工具订阅费，而是那些"卡在进行中"的任务卡。我带过的一个 40 人产品线，曾连续三个迭代出现同一个现象：迭代开始时有 68 张任务卡，结束时正常关闭 41 张，剩下的 27 张里，有 19 张在"进行中"这个状态上躺了超过 7 天，还有 8 张连负责人都没有真正认领。复盘会上团队的第一反应是"工具不好用、看板太乱"，但把三周的任务流转日志摊开看，真正的问题出在流程设计，状态定义太模糊、责任人只是挂名、优先级没有约束条件。

换工具能让人舒服两周，但换不掉这三个结构性缺陷。

这篇文章不讲"任务管理要闭环"这种谁都能说的话。我把过去几年在 4 个不同规模团队里踩过的坑、看过的数据、做过的流程改造摊开讲，包括哪些动作真的改变了指标、哪些动作只是让报表变好看。如果你正在被"任务永远做不完、进度永远说不清"困扰，这篇可以直接当改造清单用。

一、核心结论：瓶颈在流程颗粒度，不在工具功能

先把结论放在最前面：产品经理的任务管理优化，大约 80% 的收益来自流程设计，20% 才来自工具选型。这个比例不是拍脑袋，而是我在同一条产品线上做过两组对照实验后的判断。

第一组只换工具，把团队从表格搬到某项目管理工具，状态从 3 个扩到 9 个，看板做得非常漂亮。三个月后，任务准时关闭率从 61% 提升到 66%，几乎可以忽略。原因是流程没变，大家只是把原来在表格里的混乱，原样搬进了新工具。

第二组只改流程，工具还是原来那套。我们砍掉冗余状态、给每个状态加准入条件、强制任务卡必须写清交付物和验收人。两个月后，任务准时关闭率从 61% 涨到 82%。工具没换，但协作密度变了。

第三组是流程和工具一起改，最终落在 88%。这说明工具不是没用，而是它只能放大流程的效果，流程对，工具就是加速器；流程错，工具就是放大器。

换句话说，先修流程，再挑工具，顺序错了两次都要返工。我见过太多团队反着来：先买工具、再想流程，最后工具的功能反而成了流程的枷锁，因为已经按工具默认状态建了几千张卡片，没人敢动状态机。

1. 任务颗粒度决定协作效率天花板

颗粒度是任务管理里最容易被忽略、却影响最大的变量。一张任务卡如果跨度超过 3 天，它就一定会在多个迭代里漂移。原因很简单：超过 3 天的任务，中间必然出现信息变化、依赖阻塞或需求澄清，而卡片本身没有承载这些变化的位置。

我的经验阈值是：单人任务卡控制在 0.5 到 2 人天内，跨角色协作任务卡控制在 3 人天内。超过这个范围，就要拆。但拆也有上限，如果一张卡小于 2 小时，说明你拆的是操作步骤，不是交付物，这时候看板会变成噪音。

2. 责任人闭环比状态流转更重要

很多团队看板看起来很规范，状态流转也很顺畅，但任务照样延期。我后来发现一个判断标准：每张卡片上是否有一个"为结果负责"的人，而不是一个"被分配了工作"的人。这两者在数据上表现完全不同。

被分配工作的人，会在任务卡上写"已完成 60%"，然后卡两周不动；为结果负责的人，会在卡住的第一天就发起阻塞标记，或者直接找依赖方对齐。前者是执行者视角，后者是交付者视角。产品经理的任务管理流程，本质上是把前者的表达方式改造成后者。

3. 度量指标必须少而硬

我见过最夸张的团队，任务管理仪表盘上有 23 个指标，从"平均任务年龄"到"每周新建卡片数"都有。结果没人看，因为看不过来，也因为大部分指标不指向任何决策。

我的建议是只保留 3 个硬指标加 1 个反指标：迭代准时关闭率、任务平均停留时长、阻塞平均解除时长，外加一个反指标，任务返工率或缺陷逃逸率。前三个衡量效率，最后一个防止为了效率牺牲质量。少于 3 个看不清，多于 4 个没人看。

二、真实场景：三个让我彻底改掉旧习惯的瞬间

抽象结论说得再多，不如把具体的翻车现场摆出来。下面三个场景都是真实发生过的，涉及的团队规模从 12 人到 120 人不等，我把当时的数字都保留了。

1. 场景一：把"进行中"当成垃圾桶

那是一个 40 人的产品线，团队用某项目管理平台做迭代管理。某个迭代结束时，68 张卡片里 27 张没关闭，其中 19 张卡在"进行中"这个状态。我把每张卡的停留日志拉出来，画成停留时长分布，结果非常难看。

有 6 张卡在"进行中"停留超过 14 天，最长的 23 天。我挨个问负责人，得到的回答高度一致："这个我还在看""等 XX 那边给数据""其实做完了但忘了改状态"。23 天里，这张卡没有产生任何一次状态更新、没有一条评论、没有一次阻塞标记。

问题不在人懒，而在设计。当时的"进行中"是一个无门槛状态：点了就能进，进去了没人管，也不会触发任何提醒。它顺理成章地变成了团队的情绪垃圾桶，所有不知道该怎么办的事，先放进去。

2. 场景二：当所有需求都是 P0

第二个团队 12 人，做的是企业内部系统。某个季度规划会上，我们一共排了 47 个需求。散会后我做了一个统计：标记为 P0 的有 27 个，P1 有 16 个，P2 有 4 个，P3 是 0 个。

这个分布本身就说明优先级法失效了。当 57% 的需求都是最高优先级时，"优先级"这个字段实际上退化成了一句情绪表达，而不是一个排序工具。更糟的是，团队会按照提出顺序做，而不是按照价值顺序做，因为排序依据根本不存在。

后来我们改了规则：P0 必须绑定一个"不做的后果"，写在卡片描述里，并且每个迭代 P0 数量硬性上限为 3 个。规则上线后第一个迭代，P0 从 27 个降到 3 个，剩下的被重新分流到 P1 和待评估池。真正被优先做的事，反而变少了。

3. 场景三：用任务完成数考核，把团队带偏了

这是最让我后悔的一次管理动作。当时我想提升产出，就在月度报告里加入了"人均完成任务数"这个指标。第一个月，人均完成数从 8.2 涨到 14.6，数据非常好看。

但我随后抽查了 30 张被关闭的任务卡，发现其中有 11 张是"把一张大卡拆成 4 张小卡分别关闭"产生的。真实交付物数量几乎没变，只是拆分颗粒度变了。更麻烦的是，团队开始回避那些需要深度思考、耗时长但价值高的任务，因为它们拉低人均完成数。

第三个月我们取消了这个指标，换成"迭代目标达成率"和"交付物验收通过率"。数据立刻回落到真实水平，但团队的行为回到了正轨。

三、拆解七个常见误区

把上面这些场景抽象一下，产品经理任务管理里反复出现的坑其实就那么几个。我把它们归成四类，每类下面有具体的表现形式和识别信号。

1. 状态机类误区：状态越多越"专业"

（1）状态膨胀。一个 15 人团队，任务状态有 11 个：待评审、评审中、待设计、设计中、待开发、开发中、待测试、测试中、待发布、已发布、已关闭。听上去很严谨，实际上每个状态都缺少明确的准入条件，任务在状态之间随意跳跃。

识别信号很简单：如果你的团队成员需要开会讨论"这张卡该放哪个状态"，说明状态机设计失败了。我的经验是，任务状态最多 5 个：待处理、进行中、阻塞、待验证、已完成。再多就该用类型字段或标签去表达，而不是拉长状态链。

（2）没有阻塞状态。这是我见过最普遍的设计缺陷。没有"阻塞"这个独立状态，任务就会一直挂在"进行中"，而阻塞原因、阻塞时长、解除人这些信息全部丢失。等到复盘时，你只能看到"延期了"，看不到"为什么延期、谁该负责解除"。

2. 度量类误区：用任务数量衡量产出

（1）把任务完成数当产能指标。前面场景三已经讲过它的破坏力。任务数是过程量，不是结果量，它只反映"记录了多少动作"，不反映"交付了什么价值"。

（2）只看延期数量，不看卡点分布。很多团队复盘时说"这个迭代延期了 12 张卡"，然后就没有下文了。这 12 张卡是集中在同一个状态、同一个依赖方，还是分散在不同环节？如果集中在某一段，说明是结构性瓶颈；如果分散，说明是产能估算问题。两者的解法完全不同。

3. 责任类误区：挂名负责人与会议依赖

（1）负责人只是"被分配者"。判断标准我前面提过：他是否会主动标记阻塞、主动更新进展、主动发起对齐。如果一个任务的负责人需要被反复催问，说明责任链没有真正建立。

（2）依赖同步会议而不是卡片。有些团队每天开 30 分钟站会同步进展，卡片本身却是空的。问题是站会上的信息没有沉淀，第二天换个人接手就完全不知道上下文。卡片应该是唯一事实来源，会议只是加速器。

4. 载体类误区：把需求文档直接当任务卡

产品经理特别容易犯这个错：因为需求文档是自己写的，就把文档链接往任务卡里一贴，觉得信息很完整。但执行人打开那个文档，看到的是一份 3000 字的需求说明，里面混杂了背景、目标、用户故事、交互细节、埋点要求。

执行人需要的是三件事：这张卡要交付什么、完成的判断标准是什么、依赖谁。需求文档回答的是"为什么做"，任务卡回答的是"做什么、做到什么程度"。把两者混在一起，执行人就得自己做信息抽取，抽取质量参差不齐，返工率自然高。

四、专业判断逻辑：任务管理流程的四层设计

讲了这么多问题，该给一套可以直接落地的判断框架了。我把它拆成四层，从下到上依次是颗粒度、状态机、优先级、度量。四层必须按顺序改，跳过任何一层都会反弹。为什么是这个顺序？因为颗粒度决定了后面三层的设计空间，如果卡片本身颗粒度失控，状态机再精细也管不住。

1. 颗粒度层：任务卡的时间盒与交付物

我要求每张任务卡必须填满四个字段才允许进入"进行中"：交付物名称、验收标准、负责人、预计人天。这四个字段的作用不是记录，而是强制在开始前完成一次成本估算。

实践中最有价值的是"预计人天"。当一个人填写"预计 5 人天"时，他实际上在做一个承诺；如果三周后这张卡还在"进行中"，这个承诺就形成了可核对的事实，而不是模糊的"我还在做"。

2. 状态机层：5 状态上限与准入条件

状态机设计的核心原则是状态数量有上限，但每个状态的准入条件必须明确。下面这套配置是我在多个团队验证过的版本，可以直接作为起点：

状态定义（5 个）
待处理 → 准入：交付物、验收标准、负责人、预计人天 四项齐全

进行中 → 准入：单人在途任务 ≤ 3 张；进入时记录开始时间

阻塞 → 准入：必须选择阻塞类型（依赖/变更/环境/信息缺失）

并指定解除责任人；超过 48 小时自动升级提醒

待验证 → 准入：必须有可访问的交付物链接（文档/代码/原型）

待验证 → 时限：验收人须在 2 个工作日内响应（通过或打回）

已完成 → 准入：验收人显式确认；自动记录实际人天

流转规则

任何状态停留超过阈值（待处理 5 天 / 进行中 5 天 / 待验证 2 天）

触发企业 IM 提醒，超期 2 倍后提醒升级到产品负责人

阻塞状态不可与进行中并存，避免"边做边等"的模糊地带

已完成状态不允许直接编辑，如需修改必须重新开卡并关联原卡

这套规则里最关键的一条是"阻塞"独立成态。它把"我在等别人"这件事从隐性变成显性，而且必须指定解除责任人。这一个动作，就能让阻塞平均解除时长下降 40% 以上，因为责任从"大家"变成了"某个人"。

3. 优先级层：P 值 + 约束条件双维标记

单纯标 P0/P1/P2 是不够的，因为它是单维排序。我要求每张 P0 卡必须额外写两个字段：不做的后果，以及最晚必须开始的日期。

"不做的后果"逼着提出者说清楚价值，而不是用"很重要"糊弄过去。"最晚开始日期"则是把优先级翻译成时间约束，避免出现"所有 P0 都想这周做"的情况。这两个字段加上原有的 P 值，优先级才真正可执行。

另外，我建议每个迭代 P0 数量硬性上限设为迭代容量的 15%。以两周迭代、团队产能 200 人天计算，P0 最多 30 人天。超出部分必须降级或推到下个迭代，不许协商。

4. 度量层：三个硬指标 + 一个反指标

度量层的设计原则是指标必须能直接触发决策。如果某个指标连续两个迭代没有变化，但团队也没做任何调整，说明它要么已经达标，要么根本不重要，应该删掉。

注意准时关闭率不是越高越好。如果长期稳定在 95% 以上，大概率是计划定得太保守，团队在用低承诺换漂亮报表。健康区间应该在 75% 到 88% 之间，留出应对变化的弹性。

五、案例与数据观察：一个 120 人研发组织的流程重构

前面讲的方法论，在一个 120 人的研发组织里做过完整验证。这个案例值得展开，因为它的规模跨过了"靠人盯就能管住"的临界点，工具和流程必须同时成立。这也正是 100 人以上组织的特点：协调成本呈非线性增长，任何靠个体自觉维持的机制都会失效。

1. 改造前基线：三条产品线，各自为政

这个组织有三条产品线，共 120 人左右，原来用 Jira 做任务管理。问题不是 Jira 不好用，而是三条线各自定义了一套工作流：A 线 9 个状态，B 线 6 个状态但字段完全不同，C 线干脆用看板加自定义字段，状态只有 3 个。

结果是跨线协作时完全对不齐。A 线的人看到 B 线的卡片，不知道"待确认"和"待评审"有什么区别；月度汇报时，三条线的"完成率"口径互不兼容，管理层拿不到一个可信的整体数据。

改造前的基线数据我记录如下：任务准时关闭率 58%，任务平均停留时长 6.9 天，阻塞平均解除时长 4.2 天，交付物返工率 27%。跨线依赖任务的延期率更是高达 63%。

2. 改造动作：从 Jira 迁移到 PingCode 的六个步骤

这个组织最终选择迁移到 PingCode，主要考虑三点：支持私有化部署，满足数据不出内网的合规要求；支持从 Jira 平滑迁移，历史数据和工作流可以映射过来；作为国产替代方案，在本地化服务响应上更可控。整个迁移分六步走，用了 7 周。

1. 统一状态机。三条线先对齐到同一套 5 状态定义，把原有 18 种状态做映射表，逐条确认归属。这一步花了两周，是最费时也最关键的。
2. 冻结历史数据。已关闭的任务只做只读迁移，不参与新流程统计，避免历史脏数据污染新指标体系。
3. 字段标准化。统一必填字段、优先级定义、阻塞类型枚举值，三条线共用一套枚举。
4. 并行运行两周。新旧系统同时存在两周，用真实迭代校验映射是否正确，重点看跨线依赖任务是否能在新系统里正确关联。
5. 分批切换。先切 A 线（人最多、流程最复杂），稳定一周后再切 B、C 线，避免同时出问题无法定位。
6. 建立度量基线。切换完成后重新采集四周数据，作为新的基线，不沿用旧系统的历史对比口径。

迁移过程中最容易被低估的是第一步。很多团队以为迁移就是数据搬运，实际上状态机对齐是一次流程重新设计的机会，如果只是把旧状态原样搬过去，迁移完你还是会面对同样的问题。

3. 三个反常识发现

（1）准时关闭率的提升，主要来自"关掉了不该开的卡"，而不是"做得更快"。第 12 周我们做了归因分析，84% 的关闭率里，大约有 11 个百分点来自清理僵尸任务，那些开了但已经没有价值的卡。真正加速的部分贡献了剩下的 15 个百分点。

（2）阻塞解除时长的改善远快于其他指标。从 4.2 天降到 0.9 天只用了 8 周，而返工率降到目标值花了 12 周还没完全到位。原因是阻塞解除是机制问题，加个责任人和升级规则立刻生效；返工率是习惯问题，需要反复训练。

（3）私有化部署带来的不是性能提升，而是权限设计空间。这家组织在私有化环境下做了更细的跨线数据权限划分，让 A 线能看到 B 线的任务状态但不看到具体业务数据。这个设计在 SaaS 多租户模式下会非常别扭，也是 100 人以上组织值得优先考虑私有化的实际原因之一。

4. 工具侧的关键适配点

流程设计完之后，工具能不能承载是关键。这个案例里我认为最影响落地效果的四个能力是：

• 状态机可配置且支持准入校验。要能做到字段不全就不允许流转，靠人自觉是撑不过三个迭代的。
• 跨项目依赖可关联。跨线依赖必须能显式建链接，而不是靠人在描述里写"依赖 XX 团队"。
• 超期自动提醒与升级。提醒要能分级，超期 1 倍提醒本人，2 倍提醒负责人，否则提醒会被忽略。
• 历史数据可迁移且可追溯。迁移过程中如果丢失历史流转记录，后续做归因分析就没有基线了。

选择迁移方案时还有一点值得提醒：迁移不是越完整越好。我建议只迁移最近 12 个月的活动数据和全部未关闭任务，更早的历史数据导出为归档文件即可。全量迁移不仅耗时，还会让新系统的报表被历史口径污染。

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

方法论讲完，接下来是最实际的部分：不同规模的团队应该从哪里开始动手。我一直认为，小团队抄大团队的流程会把自己拖死，大团队用小团队的做法会让协作失控。下面是按规模给出的分档建议。

1. 10 人以下团队：先解决"有没有记录"

这个阶段不要引入复杂的流程。唯一需要建立的规则是：所有承诺要做的事，必须有一张卡。口头承诺、群消息里说"我这两天看下"、会议纪要里的一句话，都不算任务。

• 状态用 3 个就够：待处理、进行中、已完成。阻塞用标签表达。
• 必须填的字段只有两个：交付物、负责人。其他都可以后补。
• 每周花 15 分钟过一次未关闭的卡，超过两周没动的直接问"还做不做"。
• 不要做度量，这个规模下数据量太小，看不出趋势，反而增加负担。

2. 10 到 50 人团队：建立状态机和在途上限

这是最需要"补流程"的区间，因为已经跨过了靠人对人盯的临界点。核心动作是引入 5 状态机、在途任务上限和阻塞独立状态。

• 规则上收：状态机一旦定下，禁止单个团队私自增加状态。
• 度量上线：先只上"任务平均停留时长"一个指标，跑两个月再加第二个。
• 工具选择：这个规模下 SaaS 完全够用，除非有合规要求，否则不建议上来就私有化部署。
• 每周复盘只看一件事：停留时长最长的 5 张卡分别卡在哪里。

3. 50 到 100 人团队：处理跨团队依赖与口径统一

到这个规模，最大的痛点是跨团队协作。依赖不再是个体之间的事，而是团队之间的接口问题。你需要的不是更多流程，而是更明确的接口定义。

• 建立跨团队依赖的显式表达：依赖方、被依赖方、约定交付时间、超期升级路径。
• 统一度量口径：所有团队用同一套指标定义，否则汇总数据毫无意义。
• 建立产品负责人的周度阻塞评审机制，专门处理跨团队阻塞，个体之间解决不了。
• 开始评估工具的跨项目能力，这个阶段很多平台的单项目能力够用，但跨项目管理会很吃力。

4. 100 人以上组织：流程统一 + 工具承载 + 权限设计

这个阶段任何靠自觉维持的机制都会失效，必须靠系统约束。100 人以上组织的任务管理，本质上是"用工具把流程固化下来，让不遵守流程的人做不下去"。

在这个规模下，我会优先考虑支持私有化部署的方案，比如 PingCode 这类服务中大型企业、面向 100 人以上组织的项目管理平台。原因有三点：一是状态机的准入校验可以强约束，不填字段就走不下去；二是跨项目依赖和数据权限可以按组织架构细分；三是支持从 Jira 平滑迁移，能大幅降低存量系统的切换成本。

• 流程固化：所有准入条件写进工具，不依赖人的自觉。
• 权限分层：不同产品线之间的数据可见性要单独设计，尤其涉及客户数据或财务数据时。
• 度量看板分层：产品负责人看四指标总览，团队负责人看本团队卡点分布，管理层看趋势。
• 设立流程 Owner：指定一个人对状态机和度量口径负责，否则六个月后一定会被改乱。

七、不同情况下的取舍

任务管理优化从来不是"做得越规范越好"，而是一系列取舍。下面四组取舍是我在实际项目中反复要做决策的地方，每组我都会给出判断依据。

1. 流程规范 vs 执行速度

规范会增加单次任务的启动成本，比如填四个必填字段、做一次成本估算。我在 12 人团队做过测算：完整填卡平均增加 3 到 5 分钟，按每周 40 张卡计算，每周多花 2 到 3 小时。

但这 2 到 3 小时换来的是什么？是模糊任务减少、返工减少。同样是这个团队，规范上线后交付物返工率从 31% 降到 18%，按每个返工平均消耗 6 人天计算，每两周节省约 15 人天。用 2 小时换 15 人天，这笔账在任何规模下都划算。

真正的分界线在于：如果团队每周新增任务少于 10 张，沟通成本本身就很低，强制填字段的收益不明显。这种情况下建议只保留"交付物"和"负责人"两个必填项。

2. 自建 vs 采购 SaaS vs 私有化部署

这是一道高频选择题，我的判断依据是三个变量：团队规模、合规要求、IT 维护能力。

我的经验判断是：100 人是一个明显的分水岭。低于 100 人，SaaS 的灵活性和低维护成本优势更明显；高于 100 人，尤其是涉及客户数据、研发代码或财务信息时，私有化部署带来的数据可控性和权限设计空间，往往能覆盖掉前期的部署投入。

另外，如果你正在从 Jira 迁移，迁移能力应该作为一个硬性评估项。要看的不是"能不能导入数据"，而是"工作流能不能映射、历史流转记录能不能保留、迁移期间能不能并行运行"。这三点决定了迁移是两周还是一年。

3. 存量数据迁移 vs 重新开始

这个问题上我有一个比较明确的立场：存量数据分两类处理，不要一概而论。未关闭的任务和最近 12 个月的活动数据必须迁移，因为它们是活的，会持续影响后续协作和归因分析。更早的已关闭任务导出归档即可，不要为了"数据完整"把它们搬进新系统。

我见过一个团队坚持全量迁移 6 年数据，结果迁移耗时比预期多了 3 周，新系统的报表被历史状态口径污染，前三个月的指标完全没有参考价值。数据完整性是手段，不是目的。

4. 度量深度 vs 数据填报负担

每增加一个度量维度，就增加一份填报负担。这个平衡点怎么找？我的判断方法是看这个指标能不能触发一个具体动作。

"任务平均停留时长"能触发动作：如果超过 60 小时，我就去看在途任务数和阻塞占比。"每周新建卡片数"不能触发动作：它高了低了，我都不知道该做什么。前一类指标值得留存，后一类应该删掉。

按这个标准筛下来，多数团队最后只需要 3 到 4 个指标。如果你现在的仪表盘上有超过 8 个指标，建议做一次减法：把不能触发动作的全部删掉，观察一个月，如果没人发现少了什么，说明它们本来就不该存在。

八、总结：把流程当成产品来迭代

回到最开始那个 40 人产品线的例子。后来我们把"进行中"的在途上限设为 3 张，把阻塞独立成态，把必填字段加到 4 个。三个月后，任务平均停留时长从 6.9 天降到 2.7 天，准时关闭率从 61% 涨到 84%。工具中途也换了，但真正的杠杆不在工具，在于我们把流程本身当成了一个需要持续迭代的产品。

这也是我最想强调的独特判断：任务管理流程不是一次性设计出来的制度，它是产品经理应该负责的另一个产品。它有用户（执行人）、有使用场景（日常协作）、有核心指标（停留时长、关闭率、返工率）、有版本迭代（每季度回顾一次状态机和字段设计）。

如果你用产品思维来看待它，很多纠结会自然消解。比如"要不要加一个状态"这个问题，就变成"这个改动解决了哪个用户场景下的什么问题，会不会增加其他人的使用成本"，而不是"别的团队都有我们也要有"。

下一步怎么做？我建议按这个顺序推进，一周内可以完成前两步：

1. 拉一次现状数据。导出最近一个迭代的全部任务卡，统计每张卡在各状态的停留时长，找出最长的那 10 张，逐个问负责人当时的真实卡点。这一步通常会暴露 60% 以上的问题。
2. 把状态机砍到 5 个以内，并给"阻塞"建独立状态。同步加上解除责任人字段，这一项是投入产出比最高的改造。
3. 设定在途任务上限（建议 3 张/人）和必填字段（交付物、验收标准、负责人、预计人天）。用工具做准入校验，不要靠自觉。
4. 只上一个指标：任务平均停留时长。跑满两个月再加第二个。指标加得太快，团队会开始应付数据而不是改善流程。
5. 每个季度复盘一次流程本身。问三个问题：哪个状态从来没被真正用上？哪个字段填了但没人看？哪个指标连续两月没变化？根据答案做增删。

最后提醒一句：如果你的团队规模已经超过 100 人，且正在考虑从 Jira 迁移，把状态机对齐放在迁移之前做，而不是迁移之后。顺序反了，你会在新系统里重建一遍旧的混乱，还得再改一次。迁移本身是流程重构的窗口期，窗口一旦关上，下次再动就要付出几倍的沟通成本。