看板和甘特图都是管理项目工作的工具。它们看起来完全不同，建立在对工作流动方式的不同假设上，试图在不需要的场景用其中一个的团队通常会感到沮丧。
混淆是可以理解的：两者都被归类为「项目管理工具」，两者都能可视化任务。但相似之处到此为止。
看板是什么？
看板把工作组织成代表工作流阶段的列。任务——通常以卡片形式表示——从左到右移动，表示进展。最简单的看板有三列：待办、进行中、已完成。实际使用中大多数看板有更多列，与团队真实工作流程匹配。
让看板超越美化版待办清单的核心机制是在制品上限（WIP Limit）。每一列可以设置最多持有多少张卡片。当一列满了，没有新工作进入，直到有什么移出。
这个约束才是看板真正关注的事：控制任意时刻有多少工作是活跃状态，来提升单个任务完成的速度。当团队同时进行太多事情，每件事都移动缓慢。在制品上限强制专注。
看板衡量的是：
- 周期时间（一个任务从开始到完成需要多久）
- 吞吐量（每周完成多少任务）
- 工作在哪里积压（哪些列会满起来）
它本身并不展示项目时间线、任务依赖关系，或任何东西的截止日期。
甘特图是什么？
甘特图把任务映射到日历上。每个任务以横向条形出现，从开始日期延伸到结束日期。条形之间的箭头表示依赖关系——任务 B 在任务 A 完成之前无法开始。图表整体形态揭示了项目的排期安排。
关键路径——最长的不间断依赖任务链——决定了项目最早能完成的时间。关键路径上任何任务的延误都会延迟整个项目。不在关键路径上的任务有浮动空间：可以在有限范围内延迟而不影响最终日期。
甘特图是规划和沟通工具。构建一张甘特图迫使你列出每项任务、估算每项需要多长时间、思考排序关系。结果是一个共同的视图，展示什么事情需要发生、以什么顺序、在什么时候——这正是利益相关方汇报需要的。
甘特图衡量的是：
- 从开始到结束的项目时间线
- 任务之间的依赖关系
- 关键路径
- 哪些任务按时，哪些延迟了
它不展示工作流的流动情况，不发现执行中的瓶颈，也不告诉你任务在团队工作流中实际移动得有多快。
正面对比
| 维度 | 看板 | 甘特图 |
|---|---|---|
| 核心问题 | 什么在流动、卡在哪里？ | 什么需要在什么时候发生？ |
| 时间模式 | 基于流动，没有固定终点 | 基于时间表，固定时间线 |
| 规划开销 | 低——设置列，添加卡片 | 高——需要任务列表、估算、依赖关系 |
| 灵活性 | 高——随时重新排序 | 较低——变更会连锁影响依赖任务 |
| 依赖关系追踪 | 不展示 | 核心功能 |
| 截止日期 | 隐式 | 显式 |
| 利益相关方汇报 | 展示当前状态 | 展示时间线和进度 |
| 最适合 | 持续性工作 | 有明确终点的项目 |
什么时候用看板
持续运营型工作。 支持工单、Bug 修复流水线、内容日历、维护待办列表——任何持续涌入、没有固定项目终点日期的工作，天然适合看板。整个系统没有「完成」状态，只有任务的持续流动。
优先级频繁变化。 在甘特图上中途调整优先级意味着重新绘制时间线，在看板上只是重排待办列。如果你的工作环境变化速度超过月度规划周期，看板能优雅应对，甘特图则不能。
跑敏捷 Sprint 的团队。 Scrum 团队经常用看板风格的 Sprint 板来可视化当前 Sprint 的工作。在制品上限和列结构与 Sprint 工作的流动方式天然契合。
想要找到并修复瓶颈。 卡片在某一列的视觉积累让运营问题变得可见，而时间线图表根本看不到这些。如果代码审查列总是满的，团队知道去哪里看——不是因为有人分析了数据，而是因为看板让这一点一目了然。
什么时候用甘特图
有固定截止日期的项目。 如果项目有上线日期、合同交付日期或外部承诺，你需要甘特图。在制品上限告诉你的不是你能不能在周五前完成。一张诚实构建的甘特图，能精确告诉你这一点。
有实质性依赖关系的工作。 当任务 B 真的在任务 A 完成前无法开始——开发人员在设计师确定规格前无法构建功能；内容在法务审核前无法发布——这种依赖关系需要明确表达。甘特图让排序约束变得可见且可追踪，而看板根本不尝试做这件事。
利益相关方沟通。 高管、客户和非技术利益相关方理解时间线。「我们在代码审查列」对他们没有意义。「我们预计 3 月 15 日上线，QA 将在 3 月 10 日完成」是他们能理解的语言。甘特图说的就是这种语言。
资源规划。 在时间轴上看到所有任务，能揭示哪些人被双重预定、什么时候某个瓶颈角色（一个设计师、六个开发人员）会成为制约，以及什么时候产能需要调整。看板追踪的是任务流动，不是资源分配。
真实案例
用看板： 一个三人工程团队管理持续涌入的 Bug 修复、小功能需求和技术债，同时跑常规 Sprint。新任务来自用户和内部利益相关方，从不间断。团队的主要挑战是防止事情在审核环节积压。设置了在制品上限的看板让待办和瓶颈变得可见。
用甘特图： 同一个团队正在上线一个有承诺客户日期的新功能。这个功能需要设计、后端 API 开发、前端实现、QA 和文档以特定顺序完成。产品经理需要向 CEO 展示是否按计划推进。甘特图映射了顺序、识别了关键路径，并让大家清楚地知道如果 API 工作延迟三天，上线日期就会移动。
两者都用： 这个团队用甘特图管理上线项目（向利益相关方传达时间线），同时用看板管理日常执行（实时管理流动、发现瓶颈）。
常见错误
需要截止日期时用看板。 团队有时因为看板设置更简单就采用它，然后三个月后发现没有人知道项目什么时候结束。如果截止日期很重要，按时间线来规划。
优先级持续变化时用甘特图。 建立在每周都在变化的假设上的甘特图，比没有计划更糟糕——它创造了虚假的确定感。如果你的环境真的难以预测，维护甘特图的开销超过了它的价值。
用不诚实的估算构建甘特图。 每项任务都估算为一周的甘特图不是计划，那是愿望。工具的价值来自于现实的估算和诚实的排序。
把看板当成只是待办清单。 没有在制品上限的看板是带列的待办清单，限制才是让它成为流程管理系统的关键。
简短结论
用看板的情况： 工作是持续的，优先级经常变化，你想优化流动并找到运营瓶颈，或者你在跑敏捷 Sprint。
用甘特图的情况： 你有定义明确终点的项目，任务有实质性依赖关系，你需要向利益相关方传达时间线，或者资源规划很重要。
两者都用的情况： 你有一个同时运行项目工作和运营工作的团队——项目用甘特图，持续性工作用看板。
