项目做到 90% 后为什么停住：用交付物和流动指标管理协作

先解释“完成”代表什么

一个任务显示 90%，可能是文件已经写完但无人确认，也可能是开发完成却未通过测试。把这些状态压成一个比例，容易让管理者误以为只剩最后一点工作。

Scrum Guide 对完成定义的讨论，强调对成果状态形成共同理解。[1] 企业不一定采用 Scrum，也可以借鉴这种思路，为设计评审、设备导入、客户交付或内部流程建设约定可检查的完成条件。

这份文章以跨部门项目为例，讨论如何组织任务与交付证据。具体角色和流程名称可以调整，但每个关键节点都应有清楚的责任与确认方式。

点击放大

把任务改写成能够交接的成果

“推进系统上线”范围太大，既难估计，也难验收。可以拆成“确认试点范围”“完成权限清单评审”“通过接口异常测试”“完成培训与交接”等成果，每项对应附件、确认人和下一步使用者。

任务负责人负责推进，验收人负责确认是否达到约定标准，两者不一定是同一岗位。还应写清输入条件，避免工作已经被指派，实际却缺少客户资料、批准图纸或测试环境。

完成定义不宜只写“领导确认”。例如接口测试可以要求正常与异常用例都有结果，遗留问题有分级和处理安排，相关责任人能够读取记录。这样团队才能判断工作是否真的可以交给下一环节。

用流动指标补充进度汇报

Kanban Guide 将在制工作、吞吐量、工作项年龄和周期时间作为理解工作流的重要指标。[2] 它们帮助团队观察工作如何从开始走到结束，而不是只看每个人手中分了多少任务。

在制工作是已经开始但尚未完成的任务；周期时间描述一项工作从约定开始点到完成点所经历的时间。未完成任务的工作项年龄则提醒团队：这项工作已经停留了多久。

这些指标要先定义起止点，并按任务类型解释。一个审批单和一个大型交付包的规模不同，不能把它们直接混在一起，用平均耗时评价哪个团队更快。任务拆分方式改变后，吞吐量也可能变化，却不代表实际交付能力必然提高。

点击放大

看板列不宜照搬部门名称

如果看板只是“销售部、技术部、生产部”，工作在各部门之间移动，读者仍然不知道现在是在执行、等待确认还是被阻塞。可以按实际流转设置“待就绪、执行中、待验证、已完成”，部门作为负责人或协作字段。

对阻塞项，应保留阻塞开始时间、原因、需要谁提供什么输入以及下一次复核安排。不要为了保持看板整齐，把等待外部确认的任务标成完成，再新建一个没有关联的任务继续追。

限制同时启动的工作，也不是让团队闲着。当某一环节堆积时，优先帮助已有任务完成、减少跨任务切换，往往比继续开启新任务更有助于交付。具体限制值可以从当前工作量与试点观察中调整。

点击放大

用一个交付包做一次演练

例如某项目包含 12 个试点交付项，其中 8 项通过验收，2 项等待业务确认，1 项等待接口修复，1 项尚未开始。这个状态比统一填写“整体完成 90%”更能帮助安排资源。

但 8 ÷ 12 也不能直接作为精确的项目完成比例，因为各项工作量和关键性可能差异很大。更合适的方式是同时展示已验收成果、关键路径或依赖、剩余风险与预计交付节点。

演练时抽取一项已完成任务，检查交付物链接是否有效、版本是否一致、验收是否有记录、遗留事项是否有去处。再抽取一个超期任务，验证团队是否能够根据记录识别等待原因并安排下一步。

任务数量为演练示例；不等同于工作量比例或个人绩效。

让复盘结果改变下一轮工作

每次复盘可以只选一个最明显的阻塞来源，例如需求频繁变化、验证人员排期不足或输入资料不完整。把改进动作写进下一轮的就绪条件、模板或资源安排，持续观察同类等待是否减少。

协作平台的配置应支持任务依赖、文件版本、讨论与验收记录的关联，减少结论散落在聊天里的情况。管理者则需要维护优先级和响应规则，避免系统只是把原有混乱搬到线上。

试点是否有效，可以看任务能否被另一位同事接手、跨部门交接是否有依据，以及风险能否在截止日前暴露。指标的用途是帮助团队改善工作流，而不是把复杂协作缩减为个人任务排行榜。

点击放大