接下一项委托前，先看看尚未完成的工作

定义什么算尚未完成的工作

选择开始与结束都能识别的单位：一次目录审核、一次会谈及其交付物，或一份待批准的设计。如果一张卡代表三个月项目，另一张只代表简短修改，数卡片并不能说明负荷。必要时记录大致规模，或拆分结果。

Atlassian 将 WIP 上限解释为对进行中工作数量的限制。这个概念为本编辑练习提供参考；适合的数字需要在自己的运营中试行。团队人数本身无法决定通用上限。

画出能够支持决策的状态

在卡片上标记阻碍，并保留开始等待的时间。等待批准的交付物仍未结束，即使它不会占用全天。将其移入看不见的列表，可能隐藏收到回复后会重新出现的工作。

试行明确的进入规则

在虚构例子中，工作室有两项审核正在制作，另有一项等待资料。团队决定试行制作与审核阶段合计最多三项开放委托。第四个请求到来时，看板不会给出“今天就接下来开工”的答案，而是要求决定等待、另约日期，或先完成一项交付。

三项只是说明性选择，不是能力建议。记录哪些任务计入上限，以及谁能批准例外。出现急件时，写明哪个承诺会被移后，并通知受影响的人。不要只为消除饱和信号而提高数字。

启动更多工作前先检查等待

每个阻碍都写清缺少什么、谁能解决，以及什么动作由自己控制。“客户”过于宽泛；“周一发送的产品清单尚未获批”才便于具体沟通。如果其他人能帮忙，可用交接记录提供必要背景。

区分实际工作时间与经过的日历时间。两小时任务若需要外部回应，可能跨越数天。看板显示状态，不能自动把历史平均值变成承诺日期。确认新委托期限前仍需审核具体情况。

说明能力，无须公开私人看板

一条虚构回应可以是：“我能在本周审核材料，之后确认开始日期。范围达成一致且资料齐全后启动工作。”应根据真实流程调整。收到咨询与预留能力需要不同状态。

范围审核帮助处理开放工作扩大的情况。工作日规划帮助认识可用小时。本篇决定的是工作怎样进入系统，而不是怎样填满每个日历时段。

用案例记录复查上限

试行期间保留进入、完成、阻碍与例外的日期。问清哪些事情在等待、为什么等待。可能是开始前缺资料、单位太大，或某项审核成了瓶颈。修改规则时写明理由。

少启动一些事情属于运营决策，不保证交付更多。比较相似情境，记录范围或可用时间的变化。首次复查的实用成果，是一条大家能理解的进入规则，以及一份可见的未完成承诺清单。