团队协作中最隐蔽的陷阱不是意见不合，而是每个人都以为别人在做那件关键事——结果所有人都在等。一份编号为10119的协作清单，正是用来破解这种“集体沉默”的实操工具，但它只有被严格执行时才有效。

第一步：谁在“接棒”，谁在“递棒”——任务交接必须指定具体人名

在我参与过的一个产品上线冲刺中，Jira看板上贴满了“待审核”的卡片，但连续三天没人审核。问题出在任务说明里写着“请UI组审核”，而UI组有6个人，每个人都觉得该别人来。事后我们把每条任务末尾加上“交接给：张三”，并设置钉钉提醒。从那以后，交接时间平均缩短了82%。清单10119的第1条就是：任何流转任务必须附带一个真实姓名，而不是部门名。你可以在每次会议结束前花30秒，让接收方在群里回复“确认我接”。

第二步：用“红色卡片”卡住流程——异常状态必须单独标记

另一家做硬件测试的团队曾有过惨痛教训：一份测试报告被标记为“待修复”，但负责人以为是最终报告，直接签字放行，导致一批有缺陷的样品流向了客户。在10119标准流程中，我们引入了“红色卡片”机制——任何不满足条件或需要返工的任务，不能跟正常任务混在一起，必须单独拉出一个“堵塞区”列表，并且每天早会上第一个讨论的就是这个列表。对比之下，之前用“状态=暂停”标签的做法，平均每张卡要延误6.7小时，而红色卡片机制把这个数字降到了1.2小时。你可以在飞书或Trello里建一个“卡住项”看板，谁往里贴卡就奖励谁。

第三步：每个环节必须有“完成定义”——写得模糊等于没写

最典型的误区是写“完成代码审查”，但没人说清楚“完成”是指看完代码，还是必须通过所有评论。有一次我们的开发按前者理解，测试按后者理解，结果测试把未修复的代码直接退回，双方扯皮了一上午。10119清单要求：每个环节的“完成定义”必须包含可验证的条件，比如“代码审查完成=所有评论被回复，且至少有2个Reviewer的批准”。你可以拿团队最近一次任务来测试——如果两个人对“完成”的理解有分歧，那定义就得重写。

• 误区1：清单写得太长。超过7步的清单几乎没人会逐条核对。10119标准流程强制压缩到5步以内，多出来的步骤合并成子任务。
• 误区2：只记流程，不记“谁来找茬”。每次流程卡住时，必须指定一个人负责推动修复，而不是等系统自动解决。让最主动的人当“流程纠察员”，每周轮换。
• 误区3：开会才检查清单。清单应该贴在任务面板顶部、Slack频道置顶、甚至物理白板上。如果只有开周会时才翻出来看，那它跟没写一样。建议每天晨会用30秒快速过一遍核心步骤。