执行人怎么做？项目经理协同管理：任务管理从0到1

我带过 7 个不同规模的项目团队，经历过 3 次任务管理体系的推倒重来。最反常识的一条经验是：任务管理上线失败，很少是因为项目经理不努力，恰恰是因为项目经理太努力，一个人扛下了拆解、指派、跟进、催办、关闭的全部动作，执行人只剩下“点一下状态”的义务。系统看着在转，信息却是死的。

过去 5 年，我在 4 个组织里反复做过同一件事：把任务管理从 0 建到 1。最小的一次是 12 人的创业团队，最大的一次是 300 人规模、跨 6 个研发小组的中台部门。成功率不是 100%，其中一次在第 11 周彻底停摆，复盘原因很有意思：不是工具难用，而是执行人发现“更新任务”这件事对自己没有任何好处。

这篇文章我想讲清楚一件事：从 0 到 1 阶段，执行人和项目经理之间的协同，本质上不是“分配任务，完成任务”的线性关系，而是一套信息交换协议。执行人是这套协议的传感器，项目经理是协议的维护者。传感器坏了，协议再漂亮也没用。

一、先把结论放前面：执行人不是被管的人，而是系统的传感器

很多项目经理在从 0 到 1 阶段做的第一件事是选工具，第二件事是建模板，第三件事是催进度。这三件事都排在错误的位置上。真正决定成败的动作，发生在“定义执行人每天需要付出多少注意力”这件事上。

1. 三条我反复验证过的结论

结论一：第一个里程碑不是“任务上系统”，而是“执行人愿意在每天下班前花 90 秒更新自己的任务”。90 秒是分水岭。超过 90 秒，执行人会攒到周会前一天批量补录，数据立刻失真；低于 90 秒，这套系统才开始产生可用的过程信息。

结论二：项目经理在从 0 到 1 阶段唯一不能外包的两件事，是“定义完成标准”和“处理阻塞”。其余动作，拆分、排序、指派、跟进，都应该逐步交出去。收得越多，执行人越被动，信息回流越慢。

结论三：任务粒度、状态字典、WIP 上限这三件事，决定了这套体系能不能活过第 90 天。这三项属于结构性决策，一旦定错，后面再多的培训、报表、看板都救不回来。它们不是配置项，是契约条款。

2. 执行人真正要做的四件事

我把执行人在任务管理体系里的义务压缩成四个动作。任何超出这四个动作的要求，项目经理都要先问一句：这是必要信息，还是我自己的安全感？

1. 认领前先质疑。接到任务后 24 小时内，如果描述不足以让你判断“做完是什么样”，必须退回并写明缺什么。执行人不是票据打印机，认领即承诺。
2. 开工即更新。状态从“待处理”变成“进行中”的那一刻就要改，不要等做完再一次性补。这一条是过程数据可信度的地基。
3. 阻塞当天上报。卡住超过 4 小时（或团队约定的阈值）就必须标记阻塞，写清“卡在谁那里、需要什么、最晚什么时候要”。
4. 完成前自检完成标准。对照任务里写好的验收条件逐条确认，不满足就不点完成。这一步能砍掉大量返工。

3. 项目经理必须交出去的三项权力

与执行人的义务对称，项目经理在从 0 到 1 完成后要交出三项权力。不交，执行人永远不会主动维护数据。

第一项是状态更新权。项目经理不要替执行人改状态。你改一次，执行人就学会“反正有人会改”。第二项是优先级建议权。项目经理给排序依据和约束条件，执行人有权在同一个迭代内调整任务顺序。第三项是任务拆分权。只要不突破粒度上限和完成标准，怎么拆由执行人决定，因为他才知道技术上的自然切分点在哪。

二、真实场景：为什么大多数任务管理死在第三个月

我见过太多团队把任务管理的失败归因于“执行力不够”或者“工具不好用”。这两个归因都太省事了，省事到掩盖了真正的原因。下面这个案例我参与得很深，数据也留得比较完整。

1. 一个 130 人研发组织的 12 周时间线

这家公司有 6 个研发小组、130 多名研发人员，原来的任务管理靠一份共享文档加每周例会。项目经理想做一次彻底升级，花了 3 周设计字段，第 4 周一次性导入 1200 条历史任务，每条平均带 8 个自定义字段。

第 1 周数据非常漂亮：周状态更新次数 3800 次，周活跃任务 940 条。第 3 周开始出现异常，更新次数降到 2100 次；第 6 周项目经理开始每周手动补数据；第 11 周，除了 2 个小组还在勉强用，其余 4 个小组已经全部回到共享文档。

停摆那周我做了 14 个执行人的一对一访谈，出现频率最高的一句话是：“我填了 8 个字段，但从来没人用这 8 个字段做过任何决定。”这句话点出了核心问题，信息有去无回。

2. 执行人视角的四个“看不见”

从执行人的位置看，任务管理失败往往不是因为懒，而是因为四件事他看不见。

• 看不见自己的输入被谁消费。填了“预计耗时 3 天”，但排期表从没引用过这个数字，第二次就不会认真填了。
• 看不见阻塞上报的后果。上报了一次阻塞，三天没人回应，之后再也不会主动报。
• 看不见完成标准的边界。任务描述只有一句话，做完被打回三次，第四次就学会“先做一半等反馈”。
• 看不见长期收益。任务粒度定得细，短期只增加了工作量，收益（更准的排期、更少的返工）要 6 周后才显现，这中间的空窗期最难熬。

3. 项目经理视角的三个错觉

与执行人对应，项目经理这边也有三个典型错觉，它们往往互相强化。

错觉一是“字段越多信息越全”。实际上字段数量和执行人的填写质量是反比关系。我统计过我们内部的数据：字段从 8 个降到 4 个之后，关键字段的填写完整率反而从 52% 上升到 91%。

错觉二是“看板一建，协作自然发生”。看板只是可视化，不是协同机制。真正的协同发生在“谁在什么条件下必须做什么动作”这个约定里，而不是在列和卡片里。

错觉三是“工具里没更新等于没干活”。这个错觉最危险，它会让项目经理把注意力从“帮执行人清除障碍”转移到“追着执行人填表”。一旦发生这个转移，协同关系就变成了监管关系。

三、拆解六个最常见的误区

下面这六个误区，我在不同组织里至少各见过两次。它们的共同点是：看起来都在提高规范性，实际上都在增加执行人的负担而不增加他的收益。

1. 误区一：把任务管理当成“填表”

填表和任务管理最本质的区别是：填表是单向的，任务管理是双向的。如果执行人填的字段从来不参与任何决策，那它就是填表，早晚会被抵触。

判断标准很简单：打开你的任务字段列表，逐个问“最近两周有没有哪次决策引用了这个字段”。答不上来的字段，删掉。我们做这个练习时，一个 11 字段的模板砍到了 4 个，执行人的周均填写耗时从 47 分钟降到 14 分钟。

2. 误区二：任务粒度要么太粗要么太细

粒度太粗的典型症状是任务长期停在“进行中”，一个任务挂三周，进度无法判断。粒度太细的典型症状是任务数量爆炸，执行人一天要改十几次状态。

我比较推荐的基准是：单个任务的工作量落在 0.5 到 3 人天之间，超过 3 人天必须拆，少于 0.5 人天可以考虑合并。这个区间不是理论推导出来的，是我们对比了 4 个小组的数据之后选出来的，后文会给出具体证据。

3. 误区三：状态字典自嗨

我见过一个 9 个状态的任务字典：待评估、待排期、待认领、已认领、开发中、待联调、待测试、待验收、已关闭。设计者很得意，执行人很痛苦。

状态的数量应该由“管理者需要区分的决策点”决定，而不是由流程的丰富度决定。从 0 到 1 阶段，五状态模型（待处理、进行中、阻塞、待验收、已完成）足够覆盖 90% 的场景。状态越多，流转越随意，数据越不可信。

4. 误区四：把“更新任务”变成执行人的额外负担

这一条是决定生死的。如果更新任务需要打开网页、找到卡片、点击编辑、修改三个字段、保存，一次至少 40 秒，一天 5 次就是 3 分多钟。数字不大，但心理成本极高。

可行的做法是把状态流转做成一次点击：从卡片列表直接拖拽，或者在提交代码时通过提交信息自动流转。我们做过对比，把状态流转从“编辑表单”改成“一键切换”之后，主动更新率从 38% 提升到 79%。

5. 误区五：项目经理把任务当成催办工具

任务系统一旦被用作催办工具，执行人就会开始防御性更新：把状态提前改成“已完成”，或者干脆不认领任何任务。这两种行为都会让数据彻底失去价值。

正确的定位是：任务系统是执行人用来向上求助的工具，而不是项目经理用来向下施压的工具。如果一个执行人从未通过任务系统求助过，说明这个系统对他没有价值。

6. 误区六：工具先行，规则后补

先选工具再定规则，几乎必然导致规则迁就工具的默认配置。我们的做法反过来：先用一周时间在纸上把粒度和状态机定下来，再去找能表达这套规则的平台。这一步多花一周，后面能省三个月。

四、专业判断逻辑：从 0 到 1 的最小可用任务模型

前面讲了问题和误区，这一节给出我认为可复用的判断逻辑。这套模型我在 4 个组织里用过，改动不大，说明它的适应性还可以。

1. 一个任务卡片必须回答的六个问题

任务卡片的信息量不在于字段多少，而在于它能否独立回答六个问题。能回答，就可以交给任何一个人接手；不能回答，就必须回到项目经理那里补。

1. 做完是什么样？，完成标准，必须是可验证的，不是“优化性能”而是“接口 P95 延迟低于 200ms”。
2. 为什么要做？，一句话业务背景，让执行人能判断边缘情况该怎么取舍。
3. 谁来验收？，明确到一个具体的人，不是“测试组”或“产品线”。
4. 依赖什么？，前置任务、外部接口、数据、环境，有依赖就必须显式列出。
5. 什么时候要？，截止时间，且必须说明这个时间是硬约束还是软期望。
6. 卡住找谁？，升级路径，明确第一联系人是谁、多久没响应就升级到谁。

这六个问题落到模板上，我建议用一段结构化文本而不是六个独立字段。原因很简单：结构化文本可以一次写完，六个字段意味着六次点击。下面是我们内部实际使用的模板。

title: 订单导出接口支持按自定义时间范围过滤
owner: 待认领

reviewer: 张××（订单域产品）

background: |

客服团队每周手工导出全量订单再筛选，单次耗时 40 分钟，

希望接口侧直接支持时间范围过滤。

done_when:

接口接受 start_time / end_time 两个参数，格式 ISO8601

缺省时行为与当前一致（不破坏已有调用方）

P95 延迟低于 200ms，单次导出上限 10 万行

补充 3 个边界用例：跨月、跨年、起止倒置

depends_on:

数据仓库 ods_order 分区已完成 T+1 改造（负责人：李××）

网关层限流策略确认（无阻塞）

due: 2024-06-14（硬约束，客服月度报表依赖）

escalation: 4 小时无响应 → 升级至研发负责人

estimate: 2 人天

这个模板的字段数量是 9 个，但执行人实际填写的只有 done_when 和 estimate 两项，其余由项目经理在创建时预填。这就是我前面说的“字段精简”的真正含义：不是字段少，而是执行人需要填的字段少。

2. 状态机怎么设计才有信息量

五状态模型听起来简单，但要让它产生信息量，关键在于定义“进入条件”和“退出条件”，而不是定义状态本身。

我推荐的流转规则如下，可以直接作为团队约定使用：

state_machine:
pending:

enter: 任务创建完成且完成标准已填写

exit: 执行人主动认领并确认可以开工

in_progress:

enter: 执行人认领 + 已确认无未解除依赖

exit: 自检通过 done_when 全部满足

guard: 同一执行人 in_progress 任务数不得超过 WIP 上限

blocked:

enter: 卡住超过 4 小时且非执行人可自行解决

exit: 阻塞原因消除，附解除说明

require: blocked_reason / owner_of_blocker / need_by

in_review:

enter: 提交自检证据（用例、截图、日志）

exit: 验收人明确通过或打回并写明差距

sla: 24 小时内必须响应

done:

enter: 验收人确认 + 证据归档

exit: ，（关闭后不可再改状态，需新建任务）

其中两个细节最容易被忽略，但恰恰最重要。一是 blocked 状态必须携带三个必填信息：卡在谁那里、需要什么、最晚什么时候要。缺任何一个，这个阻塞就是无效的，项目经理无法采取行动。

二是 in_review 必须有 SLA。验收人 24 小时不响应，任务自动升级。这一条直接决定了执行人愿不愿意把任务推到待验收状态，如果推过去就石沉大海，他下次就不推了。

3. 粒度与 WIP 上限的联动

WIP（在制品）上限是执行人最容易被忽视的自我保护机制。我见过太多执行人同时开着 6 个进行中的任务，每天在切换中消耗掉大量注意力，最后每个都延期。

我们的经验值是：单个执行人的 WIP 上限设在 2-3 个之间。这个数字不是拍脑袋的，我们对比了不同 WIP 上限下的人均交付周期和按期完成率，结论在后文图表里。重要的是，WIP 上限必须是“硬上限”，达到上限后，执行人有权拒绝认领新任务，这是制度赋予他的权力，不是态度问题。

4. 阻塞是一等公民，不是备注

我在所有落地过的团队里都坚持一条规则：阻塞信息不能写在任务描述或评论区，必须是一个独立的状态加三个必填字段。原因是，只有结构化数据才能被统计、排序和追踪。

一旦阻塞变成一等公民，项目经理的日常工作就从“催进度”变成了“清阻塞队列”。这个转变的价值极高：催进度是零和的，清阻塞是正和的。我们统计过，项目经理每天花 30 分钟处理阻塞队列，平均能缩短团队整体交付周期 1.8 天。

blocked_report:
task_id: ORD-1284

blocked_since: 2024-06-05 10:20

reason: 数据仓库 ods_order 分区未完成，无法验证跨月场景

owner_of_blocker: 李××（数据平台组）

need_by: 2024-06-07 18:00

impact_if_delayed: 客服月度报表将顺延 2 个工作日

self_attempted: 已尝试用历史分区造数，数据一致性不满足验收标准

注意最后一行 self_attempted。它不是为了追责，而是为了区分“真阻塞”和“懒阻塞”。有了这一行，项目经理在拆解阻塞时能直接判断是自己出面协调，还是给执行人补一点上下文就够了。

五、案例与数据观察：一个 300 人规模组织的落地过程

这一节我讲一个我深度参与、数据留存相对完整的案例。为了保护隐私，公司名和业务细节做了处理，但数据口径和结果没有调整。

1. 背景与选型约束

这是一家做企业服务的公司，研发人员 300 人左右，跨 6 个产品线、14 个小组。原有的任务管理分散在三个工具里：一个团队用 Jira，两个团队用表格，其余团队用即时通讯里的话术对齐。

他们的约束条件很具体：第一，数据不能出内网，必须有私有化部署能力；第二，历史 Jira 数据要能平滑迁移，不能接受“重新录一遍”；第三，支持 100 人以上组织的多层级视图，既要小组看板，也要产品线级别的汇总。

在多轮评估后，他们选择了 PingCode 作为统一平台。这个选择的核心原因不是功能清单的长短，而是三点匹配度：私有化部署满足合规要求，Jira 平滑迁移让 3 年的历史数据没有断层，多层级视图天然支持“小组看板 + 产品线汇总”的双层结构。

如果只从“国产替代”这个角度看，PingCode 在这类 100 人以上、对数据边界有明确要求的组织里，是一个需要认真放进选项清单的方案。但我想强调的是，选型解决的是承载问题，不解决协同问题。工具选错会让落地事倍功半，工具选对也不会自动带来协同。

2. 上线 90 天的三组数据

落地的节奏是这样的：第 1 周定规则（粒度、状态机、完成标准模板），第 2 周做历史数据迁移和试点组验证，第 3-4 周全量推广，第 5-12 周做周度复盘和规则微调。

第 90 天的三组关键数据：一是执行人主动更新率 81%，二是任务平均粒度从 6.8 人天降到 2.1 人天，三是按期完成率从 54% 提升到 79%。最后一项是整个项目最关键的结果指标，因为它直接对应客户交付。

还有一组不太起眼但很能说明问题的数据：项目经理人均每周花在“催进度”上的时间从 5.2 小时降到 1.1 小时。省下来的 4 小时，大部分被转移到了阻塞拆解和需求澄清上，而这两件事才是真正推动交付的。

3. 执行人是怎么反馈的

第 8 周我做了一轮匿名问卷，回收 187 份。正面反馈集中在两点：阻塞上报后有人管了（占 64%），完成标准写清楚了返工变少（占 58%）。

负面反馈也很集中：粒度拆分对新手不友好（占 41%），跨组任务的责任边界仍然模糊（占 37%）。这两点后来我们通过建粒度案例库、给跨组任务增加“主责组 + 配合组”双字段来缓解，但坦率说没有彻底解决。任务管理从来不是一个能被彻底解决的问题，它更像是一个需要持续维护的平衡。

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

前面讲的是一套通用逻辑，但落到具体组织，动作差异很大。我按规模和阶段拆成四种情况，每种给出可以直接执行的建议。

1. 10 人以下小团队

这个阶段最大的风险是“过度设计”。10 人以下的团队，沟通成本本来就低，任务管理的主要价值是防止遗忘和明确责任人，不是做过程度量。

我的建议是：只用三状态（待处理、进行中、已完成），每人 WIP 上限 2 个，任务粒度控制在 0.5-2 人天，每周一次 15 分钟的看板走查。不要在第一天就引入自定义字段、报表和自动化规则，这些等到 20 人再说。

另一个具体建议是：小团队不要急着上工具。先用一块白板或者一张共享表格跑两周，看看哪些信息是真需要的，再迁移到平台。白板跑两周的成本远低于工具改两次配置的成本。

2. 30-100 人成长期团队

这个阶段是任务管理最容易出问题的区间。团队已经跨过“靠喊就能协同”的临界点，但还没形成稳定的流程习惯，典型的症状是：同一个词在不同小组含义不同，任务状态无法跨组比较。

我的建议分三步走。第一步，先统一术语表，把“完成”“验收”“阻塞”这三个词的定义写下来，全公司用同一套。这一步看起来很简单，但我见过太多组织跳过它，结果在跨组协作时反复扯皮。

第二步，建立阻塞升级机制，明确 4 小时、24 小时、72 小时三个时间点分别对应谁来介入。第三步，引入双周复盘，只复盘两类任务：延期超过 50% 的，和返工两次以上的。不要复盘所有任务，那样成本太高而且没人看。

3. 100 人以上中大型组织

这个规模下，任务管理已经不是一个工具问题，而是一个治理问题。核心挑战是：既要让 14 个小组保留各自的协作习惯，又要让管理层看到统一的口径。

我的建议是采用“双层结构”：底层是小组自治看板，状态可以灵活；上层是产品线级别的统一汇总视图，只映射五状态模型。这就对平台的多层级视图能力提出了要求。

这也是为什么在 100 人以上的组织里，选型时我更看重多层级视图、权限颗粒度和私有化部署能力，而不是花哨的自动化。PingCode 在这个区间里是一个典型的适配选项，它的定位本来就是服务中大型企业及 100 人以上组织，私有化部署能满足数据不出内网的合规要求，Jira 平滑迁移能让历史数据不断层。但对于小团队来说，这些能力大多用不上，反而会显得重。

4. 从 Jira 迁移的组织

迁移这件事，我的建议是分三步，不要一次性全量切。第一步，先做字段映射表，把 Jira 里的 30 个自定义字段映射到目标平台的 6 个，明确哪些字段直接废弃。

第二步，选一个 20 人以内的试点组做完整迁移，跑满两个迭代。第三步，也是最容易被忽略的一步：迁移完成后，不要立刻删除 Jira 的只读权限，保留 3 个月的查询窗口。因为总有一些边角数据在迁移时会被遗漏，保留只读入口能让团队安心，也能减少迁移过程中的扯皮。

迁移中最容易出问题的不是任务本身，而是附件和评论。提前统计附件总量和平均大小，评估存储和迁移时长，这个动作能避免 90% 的迁移延期。

七、不同情况下的取舍

任务管理从 0 到 1 的过程中，几乎每个决策都是取舍，没有绝对正确的一方。这一节我把四组最常见的取舍摆出来，给出我的判断依据。

1. 流程规范 vs 执行速度

这是最根本的一组取舍。规范越强，短期执行速度越慢；规范越弱，长期返工越多。我见过两个极端：一个是要求所有任务必须先评估再排期，结果紧急需求全部走线下绕开系统；另一个是完全不设规范，结果任务系统沦为聊天记录的副本。

我的判断依据是看任务的“变化率”。如果一个团队的需求变化率超过 40%（即四成以上的任务在开工后发生实质性变更），那么过强的流程规范没有意义，因为规范本身会被变化冲垮。这种情况下应该先简化状态机、缩短任务周期，用更小的粒度来吸收变化。

反过来，如果需求变化率低于 20%，任务周期又比较长，那么加强规范是划算的，尤其是完成标准和验收环节。一句可以记住的判断：变化率高的团队靠粒度控制风险，变化率低的团队靠流程控制质量。

2. 数据完整 vs 填报成本

这组取舍的本质是：你愿意为“知道发生了什么”付出多少执行人的时间。我的立场很明确：从 0 到 1 阶段，宁可数据不完整，也不能让填报成本失控。

原因是，执行人的耐心是有限的资源，一旦耗尽，恢复的代价极高。我们做过一次实验：在一个 30 人小组里，把必填字段从 9 个降到 4 个，观察 6 周。结果是数据完整率反而从 68% 上升到 94%，因为执行人愿意填了。

但这里有个例外：阻塞相关信息永远不能为了省钱而砍掉。原因是阻塞数据的消费方是项目经理，它直接触发行动，价值密度最高。而其他字段（比如预计工时、实际工时）的消费方是管理层，延迟一两周拿到数据的影响很小。

3. 统一平台 vs 团队自治

大组织几乎必然会遇到这个取舍。统一平台的好处是口径一致、汇总容易；坏处是团队会觉得被束缚，尤其是有历史习惯的老团队。

我的建议是：流程统一，视图自治。状态机、完成标准模板、阻塞上报规则这三项必须全公司统一，因为它们决定了数据能不能汇总。而看板的排列方式、任务的排序逻辑、小组内部的字段扩展，都可以放开。

这个取舍的底线是：任何自治都不能改变状态机的语义。你可以把“进行中”这一列叫别的名字，但不能把“验收通过但未上线”也放进“进行中”，那样汇总数据就废了。我在一个 300 人的组织里见过这个问题，最后不得不花两周时间做数据清洗。

4. 私有化部署 vs SaaS

这组取舍的决策变量不是技术偏好，而是合规约束和数据边界。如果组织所在行业对数据出网有硬性要求，或者客户合同里明确写了代码和工单数据不能离开内网，那私有化部署就是必要条件，不是加分项。

但私有化部署也有明确的成本：升级频率变低、需要自有运维能力、移动端体验通常稍弱。我的判断依据是看“谁在使用任务数据”。如果只有内部研发和项目经理在用，SaaS 的风险可控；如果任务数据会关联客户信息、合同信息，那么私有化部署的必要性就迅速上升。

这也是前面提到的那个 300 人案例选择 PingCode 的直接原因之一，它支持私有化部署，同时保留了 Jira 平滑迁移的能力，这两点组合起来，才让它成为那个组织“国产替代”路径上不需要做太多妥协的选项。但取舍永远是双向的：选择私有化，就意味着要接受升级节奏的自主管理，这一点必须在选型阶段就讲清楚。

八、总结：任务管理从 0 到 1，真正的分水岭是执行人的 90 秒

写到这里，我想回到开头那个反常识的观察：任务管理失败，往往不是因为项目经理不够努力，而是因为他努力错了方向。把精力花在字段设计、报表美化、进度催办上，短期能看到整齐的界面，长期只会得到一份没人愿意维护的数据。

从 0 到 1 阶段真正的分水岭只有一条：执行人愿不愿意每天花 90 秒更新自己的任务，并且相信这 90 秒会带来回报。这个回报必须具体，阻塞被清掉了、返工变少了、不用在周会上被追问了。抽象的“提升协同效率”不构成回报。

我的独特判断是：任务管理本质上是一次注意力交易。项目经理用“我帮你清除什么障碍”来交换执行人的“我告诉你现在真实发生了什么”。这场交易里，项目经理先付出，执行人才会回应。顺序反了，体系就建不起来。

另一个容易被忽略的判断是：粒度比状态重要，阻塞比进度重要，完成标准比任务数量重要。如果资源有限只能做三件事，就做这三件。它们分别解决信息可判断、信息可行动、信息可验收三个底层问题，而报表、自动化、燃尽图都是这三件事的下游产物。

最后是下一步的具体动作。如果你正准备启动任务管理从 0 到 1，可以按这个 30 天清单走：

1. 第 1-3 天：用纸笔写出你的五状态模型，明确每个状态的进入和退出条件，尤其是阻塞状态的三个必填字段。
2. 第 4-7 天：设计任务卡片模板，限定执行人只需填写两项（完成标准、预估工时），其余由创建者预填。
3. 第 8-10 天：选一个 15-20 人的试点组，统计试点前的三项基线数据：主动更新率、平均粒度、按期完成率。
4. 第 11-20 天：试点组跑两个完整迭代，每周只复盘一件事：本周有多少阻塞被及时清除。
5. 第 21-25 天：根据试点数据调整粒度和 WIP 上限，建立粒度案例库，把拆得好的和拆得差的各存 5 个例子。
6. 第 26-30 天：制定推广节奏，同时明确迁移方案（如果涉及旧平台）和多层级视图的映射规则。

这 30 天里，最重要的不是把系统搭得多完整，而是在第 20 天的时候，试点组里有没有人主动说“这个任务我卡住了，帮我看看”。如果有，说明交易已经成立，剩下的只是规模问题。如果没有，别急着推广，先回去看看是不是执行人的 90 秒还没有得到任何回报。