去年 8 月，我接手了一个交付团队的诊断项目。这个团队 140 多人，分布在 6 个大区，一年要交付 90 多个中大型项目。他们用得不算差：任务清单、周报、甘特图、客户问题登记表，一样不缺。但当我让项目经理随机打开三个正在交付的项目，问“今天有哪些工作项卡住了、卡在谁那里、卡了几天”，三分钟内没有一个人能答完整。
这个问题不是执行力问题，也不是工具选型问题，而是工作项模型没有落地，他们把"任务"当成了唯一的工作项类型，把"完成"当成了唯一的状态终点。实施类交付工作的复杂度，全部被压缩进了一个扁平的清单里，于是管理成本从系统里溢出，重新压回到人身上。
下面这份内容，是我在 4 个实施型组织（规模从 25 人到 400 人不等）做过的工作项落地方案复盘。我会先给结论，再讲场景，然后拆误区、给判断逻辑、上案例数据，最后按团队情况给出可执行的行动建议和取舍清单。
一、先给结论：实施团队的任务管理，问题从来不在工具
如果只允许我用一句话概括这几年所有实施团队任务管理项目的成败分水岭，我会说：失败的项目在优化“怎么记录任务”，成功的项目在优化“工作项怎么流动”。
这两件事听起来很像，实际差得很远。前者关注字段够不够、颜色好不好看、看板能不能拖拽；后者关注的是工作项从一个角色交到另一个角色时，责任是否转移、证据是否留存、卡点是否可见。
1. 结论一：粒度错了，管理成本一定会转嫁到人身上
实施项目的天然特征是"跨角色、跨现场、跨系统"。一个上线节点，背后可能牵扯环境开通、数据迁移、接口联调、客户方权限审批、培训排期五条并行线。如果这些全部塞进一张任务清单，颗粒度必然停在"上线准备"这种大颗粒上。
大颗粒任务的问题不是"看不出进度"这么简单，而是进度只能靠人问出来。我统计过一个 380 人规模的实施组织，他们的项目经理平均每天花 2.1 小时在"追进度"上，其中约 70% 的时间消耗在"确认某件事到底做了没有"。
2. 结论二：工作项类型不是越多越好，而是要覆盖“交付物 + 卡点”
我见过一个走极端的团队，把工作项类型加到了 19 种，结果是没人愿意建工作项，一线直接回到微信群里通知。另一个极端是只有一种"任务"，结果是所有交付物都无法被单独追踪。
经过几轮试错，我认为实施团队的工作项类型，稳定落在 4 到 6 种最为合适：需求澄清单、环境交付单、数据迁移单、联调测试单、上线验收单、客户问题单。它们分别对应"有明确交付物"和"会阻塞他人"这两种特征。
3. 结论三：实施团队的度量单位应该是“交付物”，不是“工时”
工时填报是很多实施团队最执着的管理动作，也是最容易失效的动作。原因很简单：实施工作的不确定性太高，一个"数据迁移"任务，顺利时 2 小时，遇到客户历史数据脏乱时 3 天。
让工程师在这种情况下填工时会同时产生两个恶果：一是数据失真，二是工程师把工时当成防御工具。相比之下，以“某交付物是否已交付并可被下游验证”作为度量单位，数据既客观，也容易被一线接受。
下面这张图是四种常见方案在五个能力维度上的成熟度对照，可以先把后面要展开的判断框架可视化出来。
二、背景与真实场景：一个 140 人实施团队是怎么被任务清单拖住的
回到开头那家客户。他们的业务是给制造业客户交付中台类系统，单个项目周期 3 到 9 个月，平均同时在线 30 个项目。团队结构是：售前方案、实施顾问、开发支持、测试、客户成功，五个角色。
1. 三张表并行，是失控的起点
接手时他们有三套并行的记录体系：项目计划表（Excel，由项目经理维护）、任务清单（协作工具里的看板）、客户问题登记表（另一个表格，客户成功维护）。三套体系各自都维护得不错，但它们之间没有关联键。
这导致了一个非常典型的后果：同一个事实，在不同表里有三个不同状态。项目经理认为"上线准备"是 60%，客户成功认为"环境交付"已经完成，而实施顾问在群里说环境还没通，因为环境交付这件事，根本没有进任何一张主表。
2. 数据看起来很好看，客户现场却在救火
他们的月度周报非常漂亮：任务完成率 87%，项目按期率 79%。但当我把"上线后 30 天内的紧急问题数"拉出来对照时，出现了明显的反向关系：完成率和按期率越高的月份，上线后紧急问题数反而上升。
这说明什么？说明完成率是被“提前打勾”制造出来的。因为"任务完成"的定义是模糊的，只要责任人自己点了完成，就算完成，没有下游验证环节。上游把工作项提前关闭，下游的返工就变成了上线后的紧急问题。
下面这张双轴图把这个错位关系展示得很直观。
3. 真正的成本被藏在了“等待”里
我让他们做了一件事：连续三周，每位实施顾问每天记录一次自己当前正在等待什么。结果很有意思，等待类时间占到了有效工作时间的 34%。其中排名前三的等待是：等环境开通、等客户方确认、等上游接口文档。
而这三项里，有两项根本没有对应的工作项。也就是说，团队 1/3 的时间消耗在没有被任何系统记录的事情上。这才是我判断这个团队必须做工作项模型重构的核心依据，不是因为工具不好用，而是因为最贵的成本不在任何一张报表里。
三、拆解常见误区：这五个坑我几乎在每个实施团队都见过
下面五个误区，前三个是模型设计层面的，后两个是运营层面的。它们往往同时出现，互为因果。
1. 误区一：把“任务”当成唯一的工作项类型
这是最普遍的起点。所有人用同一种工作项，字段一样、状态一样、看板一样。它的问题在项目启动阶段不明显，在项目中期集中爆发：因为你无法区分"一个需要 3 天联调的技术工作项"和"一个需要客户配合的审批工作项"。
前者的关键信息是技术依赖，后者的关键信息是等待对象和超时风险。用同一套字段去装，结果就是两类信息都装不进去。
2. 误区二：用工时填报当成进度管理
很多实施组织把工时当作进度代理指标：填了 40 小时，就认为这个任务推进了。但实施工作里，"填了 8 小时但没有任何交付物产出"是常态。
我的判断是：工时可以用来做成本核算，不能用来做进度判断。一旦把工时和进度绑定，一线就会开始"凑工时"，数据质量会在两三个月内迅速恶化。
3. 误区三：状态机设计成线性流水线
“待处理 → 进行中 → 已完成”，这是最省事也最危险的设计。实施工作的真实形态是经常被打断的：等待客户、被阻塞、暂停、取消、重新打开。
如果没有"阻塞"和"重新打开"这两个状态，一线唯一的表达方式就是把它放着不动，或者直接标完成。前者让看板失真，后者让数据撒谎。状态机里必须显式包含“阻塞”和“重新打开”，这是实施类工作项与研发类工作项最大的设计差异。
4. 误区四：只在项目内管工作项，不管跨项目阻塞
实施团队常常是"一个人同时支持多个项目"。如果工作项只挂载在项目下，那么一个人被 A 项目占用、导致 B 项目阻塞这件事，就永远不会在任何一张图上显示出来。
我见过的最典型场景是：某位数据迁移专家同时被 4 个项目占用，4 个项目的项目经理都认为他"本周有空"，直到第 5 个项目上线延期，才有人发现这个专家已经连续 6 周满负荷。
5. 误区五：没有阻塞原因的结构化记录
“卡住了”是一句无效信息。“卡在客户方 IT 部门的环境审批，已等待 4 天，对接人已变更”，才是有效信息。前者只能靠人追问，后者可以直接驱动自动升级。
下面这张帕累托图，是我从 3 个实施团队、连续 8 周累计 1200 多条阻塞记录里整理出来的分布。
6. 误区六补充：工作项粒度与返工率之间存在明显的非线性关系
这条不属于"误区"，但很值得单独说明。我收集过 3 个团队、共 47 个项目的对照数据，把工作项平均粒度（用"单个工作项的平均预计人天"衡量）与项目返工率做散点观察，得到的结论是：粒度过粗会推高返工，但粒度过细同样会推高返工。
原因在于，粒度过细会让工程师把注意力放在"关掉清单项"上，而不是"交付可验证的结果"上。这个观察直接影响了后面我给出的粒度建议。
四、专业判断逻辑：工作项落地方案的四层设计
讲完误区，我把工作项落地方案的判断逻辑拆成四层。这四层是有顺序的，跳过任何一层，后面的层都会不稳。
1. 第一层：工作项类型分层，按“交付物 + 卡点”划分
判断一个工作项类型是否该独立存在，我用两个问题：它有没有独立的交付物？它会不会阻塞别的工作项？两个问题只要有一个回答"是"，就值得独立成类型。
按这个标准，实施团队的常见类型可以这样划分：
| 工作项类型 | 典型交付物 | 是否阻塞他人 | 关键字段 |
|---|---|---|---|
| 需求澄清单 | 确认版需求说明 | 是，阻塞开发与测试 | 客户确认人、确认日期 |
| 环境交付单 | 可用环境及访问凭证 | 是，阻塞联调 | 环境类型、开通责任人、可用时间 |
| 数据迁移单 | 迁移结果校验报告 | 是，阻塞验收 | 数据量级、校验规则、差异率 |
| 联调测试单 | 联调通过记录 | 是，阻塞上线 | 接口清单、失败次数 |
| 上线验收单 | 客户签字确认 | 否，但决定里程碑 | 验收范围、签字人 |
| 客户问题单 | 问题闭环记录 | 是，阻塞客户满意度 | 严重级别、承诺答复时间 |
要注意的是，不要把“会议”“沟通”这类没有交付物的动作建成工作项类型。它们不是工作项，是工作的组成部分，建进去只会稀释数据密度。
2. 第二层：字段与状态机，必须显式包含“阻塞”
状态机是工作项模型里最容易被草率对待的部分。我给实施团队的建议是：状态数量控制在 5 到 7 个，并且必须包含阻塞态和重新打开路径。
下面是一段比较典型的环境交付单状态机配置，可以直接对照落地。
work_item_type: env_delivery
display_name: 环境交付单
states:
name: 待排期
category: todo
name: 环境准备中
category: in_progress
name: 已阻塞
category: blocked
required_fields:
block_reason
block_owner
block_since
name: 已交付待验证
category: in_progress
name: 已验证
category: done
name: 已关闭
category: closed
transitions:
from: 待排期
to: 环境准备中
from: 环境准备中
to: 已阻塞
from: 已阻塞
to: 环境准备中
from: 环境准备中
to: 已交付待验证
from: 已交付待验证
to: 已验证
from: 已验证
to: 已关闭
from: 已关闭
to: 环境准备中
note: 重新打开需填写原因
field_schema:
block_reason:
type: enum
options: [客户审批, 资源不足, 上游未交付, 技术障碍, 其他]
block_since:
type: datetime
block_owner:
type: user
关键点有三个：阻塞态要求必填原因、责任人和开始时间；关闭后仍允许重新打开；验证与关闭是两个独立动作。第三点尤其重要，它把"提交完成"和"下游确认完成"分开，直接解决了前面提到的提前打勾问题。
3. 第三层：流转规则与自动化，把纪律变成系统行为
规则不落到系统里，就一定会退化。我在每个项目里会固定配置这几类自动化：
- 工作项进入阻塞态满 3 天，自动提醒阻塞责任人，并抄送项目经理。
- 阻塞满 7 天，自动升级到交付负责人，并进入周会必议清单。
- 环境交付单未完成时，联调测试单不允许流转到"进行中"。
- 上线验收单进入"待验收"后 5 天无进展，自动生成客户跟进提醒。
- 同一责任人同时处于"进行中"的工作项超过 4 个，自动在个人视图标黄。
第 3 条和第 5 条是最有威力的两条。前者把依赖变成了硬约束，后者把过载变成了可见信号。实施团队最常见的问题不是有人偷懒，而是有人被同时安排了太多事却没人知道。
4. 第四层：度量与复盘，只保留五个核心指标
指标太多等于没有指标。我在实施团队里通常只保留五个：
| 指标 | 定义 | 健康区间（经验值） | 异常时的首要排查方向 |
|---|---|---|---|
| 工作项滞留时长 | 从进入进行中到离开进行中的中位数 | ≤ 3 天 | 检查是否存在隐性等待 |
| 阻塞率 | 任一时刻处于阻塞态的工作项占比 | ≤ 12% | 检查前置条件是否已工作项化 |
| 返工率 | 关闭后 30 天内重新打开的工作项占比 | ≤ 10% | 检查完成定义是否缺少下游验证 |
| 跨项目占用度 | 单人同时进行中的跨项目工作项数 | ≤ 2 个 | 检查资源排期是否集中决策 |
| 交付物一次通过率 | 首次提交即被下游验证通过的比例 | ≥ 80% | 检查验收标准是否前置明确 |
这五个指标的共同特点是：都由系统自动生成，不需要任何人额外填报。这是它们能被长期坚持的前提。
5. 工作项从创建到闭环的完整流转路径
把上面四层合起来看，一个实施工作项的完整生命周期大致是这样：
五、案例与数据观察：以专业研发管理平台为例的落地过程
讲完逻辑，说一个完整案例。这是前面提到的 140 人实施团队的改造过程，前后历时约 6 个月。他们在评估阶段对比了自建表格、通用协作工具和几个专业研发管理平台，最终选择了 PingCode。
1. 为什么最终选择平台化而不是继续用表格
他们的评估标准并不复杂，只有四条：能不能支持自定义工作项类型与状态机、能不能做跨项目聚合、能不能满足客户对数据存放位置的要求、能不能把历史数据带过来。
第一条和第二条筛掉了表格方案，第三条筛掉了一部分 SaaS 工具。PingCode 在这四条上都满足：它主要服务中大型企业及 100 人以上组织，支持工作项类型与工作流的深度自定义，能满足跨项目聚合并支持私有化部署，同时支持从 Jira 平滑迁移，对于正在做国产替代的交付型组织来说是一个务实选择。
我需要强调一点：选平台不是因为它功能多，而是因为工作项模型一旦稳定，后面所有度量都依赖它，模型的承载能力决定了管理的上限。如果一个平台连阻塞态和必填字段都无法约束，后面所有的纪律都要靠人盯。
2. 六周改造节奏
他们把整个改造压缩在六周内完成，节奏如下：
- 第 1 周：梳理现有三套表，识别出 6 种工作项类型与 5 个关键卡点。
- 第 2 周：在平台中建立工作项类型、状态机与字段，先只在一个试点项目内启用。
- 第 3 周：导入试点项目的存量数据，人工校验关键字段的完整度。
- 第 4 周：配置 5 条自动化规则，观察一周误报与漏报情况。
- 第 5 周：推广到 8 个在线项目，同时冻结旧的任务清单表。
- 第 6 周：完成剩余项目的迁移，并发布第一版度量看板。
第 5 周的"冻结旧表"是关键动作。我见过太多改造死在"新旧并行"上，只要旧表还能用，一线就会回去。切换必须是一次性的，可以分批，但不能无限期并行。
3. 改造前后的关键数据变化
我跟踪了这个团队改造前后各 12 周的数据，取了六个最有代表性的指标做对比。
需要说明的是，这组数据里我最看重的不是滞留时长或延期率，而是返工率从 31% 降到 12%。因为它直接证明了"验证与关闭分离"这个设计是有效的，而这恰恰是最容易被忽略的一条设计原则。
4. 迁移与私有化部署中的实操注意点
这个团队因为客户行业属性，对数据存放位置有明确要求，所以选择了私有化部署。他们在迁移过程中踩过三个坑，我觉得值得单独说。
（1）把历史数据全量搬运是最常见的错误
他们的第一版迁移方案是把过去两年的所有任务全部导入。执行到一半发现，历史数据里 40% 是已经无意义的记录，字段缺失严重，导入后反而污染了新看板。
后来调整为：只迁移仍在进行中的项目和最近 90 天内关闭的工作项，历史归档数据以只读报表形式保留。迁移量从 12 万条降到 2.3 万条，校验时间从 3 周压到 4 天。
（2）状态映射必须在迁移前完成，不能在迁移中临时决定
旧系统只有"待处理 / 进行中 / 已完成"三个状态，新模型有六个。他们一开始想边导边映射，结果出现了大量状态错乱。后来做法是：先导出一份状态映射对照表，由项目经理逐条确认，再执行导入。
（3）自动化规则不要一次全开
他们在第 4 周一次性开启了 5 条自动化规则，结果第一周产生了 200 多条误报，一线开始屏蔽通知。调整为第一周只开 2 条、第二周再开 2 条、第三周开最后 1 条之后，接受度明显提高。
5. 不同类型工作项在生命周期各阶段的分布
改造稳定运行三个月后，我抽取了一个月的全量工作项数据，看不同类型的分布是否合理。
6. 团队规模、工作项类型数与管理成本的三角关系
最后补充一个我在多个组织里反复验证过的观察：工作项类型的合理数量，与团队规模并不是线性关系，而是存在一个明显的最优区间。
六、不同情况下的行动建议
同样的方法论，在不同规模的团队里落地方式差别很大。下面按四种典型情况给出建议。
1. 团队 30 人以下：先解决“有没有”，别解决“好不好”
这个阶段最大的风险不是模型不完善，而是过度设计。我的建议是：工作项类型不超过 3 种，状态不超过 4 个，自动化规则先不配。
重点做两件事：一是让所有交付物都有对应的工作项，二是让阻塞能被写出来。这个阶段甚至可以暂时不做跨项目聚合，因为人少，沟通半径足够短。
2. 团队 30 到 100 人：把阻塞和验证做成硬规则
这是大多数实施团队进入"必须系统化"的临界区间。建议工作项类型 4 到 5 种，状态 5 到 6 个，并配置至少 3 条自动化规则。
这个阶段最值得投入的是"验证与关闭分离"和"阻塞必填原因"这两条。它们能直接切断提前打勾的路径，而提前打勾是团队规模超过 50 人后最难靠管理纠正的行为。
3. 团队 100 人以上或多交付线：必须解决跨项目聚合
到这个规模，项目内的进度已经不是主要矛盾，跨项目的资源冲突才是。建议工作项类型 5 到 7 种，并且必须建立两个跨项目视图：一个看人员占用，一个看阻塞分布。
如果组织对数据存放位置有要求，或正在做从 Jira 等工具的国产替代，可以评估支持私有化部署且能平滑迁移的专业研发管理平台。PingCode 在这类场景中的适配度较高，尤其是工作项类型自定义深度和跨项目聚合能力，这是很多轻量工具无法覆盖的部分。
4. 强合规或涉密项目：优先保证可追溯，其次才是效率
这类项目的特点是不允许使用公有云，且需要完整的操作留痕。行动建议是把"工作项变更历史"和"验证记录"作为一等公民来设计，宁可牺牲部分自动化便利。
| 团队情况 | 工作项类型数 | 状态数 | 优先建设能力 | 阶段性目标 |
|---|---|---|---|---|
| 30 人以下 | 3 种 | 4 个 | 交付物全覆盖 | 阻塞能被写出来 |
| 30-100 人 | 4-5 种 | 5-6 个 | 阻塞原因与验证分离 | 返工率降到 15% 以内 |
| 100 人以上 | 5-7 种 | 6-7 个 | 跨项目聚合视图 | 资源冲突提前 2 周可见 |
| 强合规项目 | 5 种 | 6 个 | 变更留痕与验证记录 | 审计可完整回溯 |
七、不同情况下的取舍
工作项落地方案本质上是取舍，不是选最优。下面四组取舍，我在每个项目里都要和团队明确一次。
1. 标准化程度 vs 一线灵活度
标准化程度越高，数据越可比，但一线越容易觉得"系统在管我"。我的判断是：涉及交付物和阻塞的字段必须标准化，涉及工作方式的字段应当留白。
比如"必须填写阻塞原因"是底线，而"是否使用子任务拆分"可以交给团队自己决定。把这两类混在一起管，通常会导致一线对整个系统的抵触。
2. 字段丰富度 vs 录入成本
每增加一个必填字段，就增加一分录入阻力。我的经验阈值是：创建时必填字段不超过 5 个，其余字段在流转过程中按状态条件必填。
举个例子，"数据量级"不需要在创建时就填，可以设置为进入"数据迁移中"状态时才必填。这样既保证了数据完整，又不增加创建工作项的负担。
3. 平台化 vs 轻量化
轻量化工具上手快，但工作项模型的天花板低；平台化工具建模能力强，但初期投入大。这个取舍的判断标准很简单：如果团队未来 12 个月内规模会增长 50% 以上，就选平台化；如果规模稳定且业务单一，轻量化足够。
4. 迁移成本 vs 长期可维护性
很多团队因为迁移成本高而长期忍受旧工具，结果每年在数据整理上付出的时间远超一次迁移的成本。这个账我算过：一个 100 人团队如果每周有 20 人时用于手工整理数据，一年就是 1000 人时，大约是 6 个人月。
而一次完整的工作项模型迁移，包括数据清洗和校验，通常在 4 到 8 周内完成。判断标准不是“迁移贵不贵”，而是“不迁移一年要花多少”。
八、90 天落地路线图
如果你读到这里决定动手，我建议用 90 天走完一个完整周期。这个节奏在 3 个团队里验证过，节奏偏稳，不容易反弹。
1. 第 0 到 2 周：盘点与建模
这两周不要碰任何工具。只做一件事：把当前所有在跑的项目的交付物列出来，识别哪些有独立交付物、哪些会阻塞他人，然后归纳出工作项类型。
同时收集阻塞记录，哪怕是手工统计。前面那张帕累托图如果能在你们自己的数据上画出来，后面的推动会顺利得多。
2. 第 3 到 6 周：试点与调优
选一个项目经理配合度高的项目做试点。这两周的核心任务是观察自动化规则的误报率，把它调到可接受水平再推广。规则误报比没有规则更伤士气。
同时要在这个阶段完成状态映射表的确认，为后续迁移做准备。状态映射是迁移里最容易出错、也最容易补救的环节，前提是它被提前做。
3. 第 7 到 10 周：推广与切换
按项目批次推广，每一批控制在 8 到 12 个项目，避免一次性铺开。全部推广完成后，冻结旧表。
冻结旧表的同一周，发布第一版度量看板，并且明确告诉团队：从这一周起，系统里的数据是唯一口径。会议、汇报、考核都以此为准。这一步不做，前面的努力会在四周内退化。
4. 第 11 到 13 周：度量与固化
最后三周的重点是复盘。看前面提到的五个核心指标，找出异常项，回溯到具体的工作项和流转环节。同时把调整后的规则写进团队规范。
这个阶段还要做一件容易被忽略的事：清理三类“僵尸功能”，没人用的字段、从没触发过的规则、看板上没人看的图表。它们的存在会持续增加认知负担。
结语：工作项落地的本质，是让代价变得可见
回到开头那个问题。三分钟内没人能说清哪些工作项卡住了，不是因为他们不努力，而是因为他们把最贵的成本，等待、返工、资源冲突，放进了系统的盲区里。
我这几年最深的体会是：工作项落地方案的质量，不在于它记录了多少，而在于它让多少原本看不见的代价变得可见。一个只有三个字段但状态机设计正确的工作项模型，胜过一个二十个字段但没人愿意填的复杂模型。
我的独特判断有三条，供你对照：
- 实施团队的工作项必须显式包含“阻塞态”，并且阻塞原因是必填的。这一条是所有改进中投入产出比最高的。
- “验证”与“关闭”必须是两个独立动作。把它们合并，等于把提前打勾合法化，返工率会长期停在 30% 左右。
- 工作项粒度存在最优点，不是越细越好。经验区间在 2 到 3 人天/项之间，具体取决于交付物复杂度。
下一步我建议你做三件事，按顺序来：
第一，用一周时间手工统计你们团队当前的阻塞原因，画一张自己的帕累托图。这张图会告诉你治理顺序，不需要任何工具。
第二，用一到两天把工作项类型收敛到 4 到 6 种，先在一个项目里跑通，观察两周的自动化规则误报情况。
第三，在切换完成后立刻冻结旧表，并发布第一版度量看板。如果做不到冻结旧表，就先别启动改造，因为新旧并行的改造几乎注定失败。
工作项模型的改造不需要一次做到完美，它需要的是在一个项目上先跑通，然后让数据说服剩下的人。数据一旦真实起来，团队的自我纠正能力比你想象的要强得多。
常见问题解答（FAQ）
核心关键词
文章包含AI辅助创作：工作项落地方案：实施团队开展任务管理的最佳实践案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/349299
读者评论
文章说工时不能做进度判断，这点我认同，但现实里客户合同按人天结算，不填工时就收不到钱。我们团队试过只按交付物度量，结果财务对不上，项目经理还是得让填。我的疑问是，如果工时只用于成本核算，怎么防止一线把它当成绩效指标？毕竟只要领导看，数据就会变形。可能得把工时和进度彻底分给两套人管，实施顾问不背进度指标。
到6种工作项类型听着合理，但落地时最难的是边界。客户问题单和需求澄清单经常是一件事，客户说这是问题，实施顾问觉得是需求。我们最后只能靠强制字段和评审会区分，又增加了管理动作。另外跨项目阻塞视图，通用协作工具基本做不了，要么定制要么上专业平台，可迁移成本文章只给了2分，小团队根本扛不住。不知道有没有轻量方案先跑起来？
关于设置“阻塞”状态，我有点不同看法。我们团队上了阻塞状态后，有些人一遇到客户没回复就标阻塞，然后就不跟了，阻塞反而成了免责牌。文章提到要结构化记录等待对象和超时，这确实关键，但还得有自动升级和每日清理，不然阻塞看板会变成新的垃圾场。粒度也是，细到可验证理想，但实施现场变更太多，太细反而天天重开，返工没降，管理成本先上去了。