系统化学习 · 从业务骨干到卓越管理者
看板（Kanban）源自丰田生产方式，是一种拉动式（Pull）的 workflow 可视化方法：用看板卡片代表工作任务，通过限制在制品数量（WIP Limit）暴露瓶颈、减少多任务切换，让工作流顺畅。它的核心不是「把任务贴墙上」，而是WIP 限制——这一步决定了看板是真正的方法论还是一块装饰板。
| 对比 | 推动式 Push | 拉动式 Pull（看板） |
|---|---|---|
| 驱动信号 | 计划/预测：上游生产多少，下游就接收多少 | 下游消耗：下游取走多少，上游才补多少 |
| 库存表现 | 工序间大量堆积（WIP 高） | 由超市上限控制，WIP 低且稳定 |
| 问题暴露 | 库存掩盖问题（设备停机也不影响下游） | 库存低，一停机立刻全线感知 |
| 适用场景 | 需求稳定、品种少、大批量 | 需求波动、多品种、需快速响应 |
| 实践 | 说明 |
|---|---|
| ① 可视化 | 把工作流与任务状态全部呈现出来（列 = 阶段，卡片 = 任务），让所有人看到全局 |
| ② 限制 WIP | 每个「进行中」列设定最大同时处理数量。这是看板最核心、也最容易被省略的一条 |
| ③ 管理流动 | 关注任务流经系统的速度与阻塞点，而非个人忙碌程度 |
| ④ 显性化规则 | 明确定义每列的含义、准入准出条件（Definition of Done）、优先级规则 |
| ⑤ 持续改进 | 基于数据（周期时间、吞吐量）定期回顾并调整规则与 WIP 上限 |
为什么限制 WIP 能提速？因为多任务并行会产生大量切换成本：三个人同时做五个任务，每个任务都要等待，实际完成时间远长于串行做。限制 WIP 强迫团队先完成再开始。
初始设定方法（经验法则）：
触发时的正确反应（关键）：当某列达到 WIP 上限（卡片无法前移），不要提高上限，而应：
| 指标 | 定义 | 用途 |
|---|---|---|
| 周期时间 Cycle Time | 一张卡片从进入「进行中」到「完成」的时长 | 衡量交付速度；用于 SLA 承诺（如 85% 的任务在 10 天内完成） |
| 吞吐量 Throughput | 单位时间完成的任务数 | 衡量团队产能；用于预测 |
| WIP | 同时在进行的任务数 | 利特尔法则：WIP 越高，周期时间越长 |
| 累计流图 CFD | 各列任务数随时间变化的堆叠图 | 看趋势最有用：某列带宽持续变宽 = 该处堵了 |
这条公式揭示了一个反直觉的事实：想让任务完成得更快，应该减少同时在做的数量，而不是让人更忙。
背景：某研发组 8 人，同时推进 20+ 个任务，人均并行 3 个，需求方抱怨「什么都答应，什么都交付慢」。引入看板。
| 看板列 | WIP 上限 | 规则定义 |
|---|---|---|
| 需求池 | 无限 | 所有待评估需求；按优先级排序 |
| 分析中 | 3 | 输出：需求说明 + 验收标准 |
| 开发中 | 6（8人×1.5→12，收紧至6） | 输出：代码完成 + 自测通过 |
| 评审中 | 3 | 输出：评审通过并合入主干 |
| 已完成 | 无限 | 交付需求方验收 |
推行过程与阻力：第 2 周「开发中」列达到上限，团队第一反应是「把上限提到 10」。负责人拒绝，改为全员集中清空。过程中发现真实瓶颈：评审环节积压（只有 1 位资深工程师能做评审），而非开发能力不足。
改进措施：① 培养第 2 位评审人；② 评审列 WIP 从 3 提到 4 并明确「评审需在 1 个工作日内响应」；③ 站会改为从右往左看。
| 指标 | 引入前 | 3 个月后 | 变化 |
|---|---|---|---|
| 平均周期时间 | 28 天 | 11 天 | -61% |
| 月均完成任务数 | 14 个 | 23 个 | +64% |
| 平均并行任务/人 | 3.0 | 1.2 | -60% |
| 需求方满意度 | 6.2/10 | 8.7/10 | +40% |
最重要的认知转变：团队原以为问题是「人手不够」，看板数据显示真正问题是WIP 过高与评审瓶颈。没有增加一个人，吞吐提升 64%。