甘特图和看板都是研发项目进度管理的常用视图，区别在于它们回答的进度问题不同：需要看时间轴、任务依赖和交付日期时，甘特图更直接；需要看任务流转、在制品数量和阻塞位置时，看板更有效。多数研发项目会组合使用两者，用甘特图管计划与关键路径，用看板管日常执行与瓶颈暴露。下面按判断框架、同口径对照、典型场景和选择步骤展开。
要点总览（TL;DR）
- 选择依据是团队当前要回答的进度问题：需要看时间轴、任务依赖和交付日期时用甘特图，需要看任务流转、在制品数量和阻塞位置时用看板。
- 两种视图在时间表达、依赖呈现、流动可视化和协作方式上各有侧重，甘特图适合计划评审与跨团队对齐，看板适合每日同步与即时调整。
- 研发项目常见做法是组合使用：计划层用甘特图排里程碑和跨团队依赖，执行层用看板推进任务和暴露阻塞。
- 组合使用的前提是两个视图基于同一套工作项和状态定义，否则会出现进度口径分叉。
- 建议选一个版本或迭代同时启用两种视图试点两到三周，复盘依赖是否被真正使用、阻塞是否及时更新，再确定主视图与辅助视图。
两种视图各自回答什么进度问题
把甘特图和看板放在同一张进度管理桌面上，它们承担的是两类不同的信息任务。甘特图沿时间轴铺开任务，每项任务有起止日期和工期长度，任务之间可以标注前后置依赖，里程碑则标出关键时间点或决策点。它回答的是“什么时候做什么、谁在等谁、哪个节点必须按时到”。看板把任务按状态列排开，任务卡片从待办流向进行中、待验证、已完成，团队可以给某一列设置在制品上限，并用标记暴露阻塞。它回答的是“现在有多少事在做、卡在哪一步、下一步该拉什么”。
这两种表达在研发进度管理中形成互补。甘特图给出承诺和顺序，看板给出当下的流动状态。一个版本计划在甘特图上看起来排期合理，执行中却可能因为测试环节积压而整体后移，这类问题只有看板的在制品和阻塞信息能及时反映；反过来，看板上每张卡片都在流动，也不代表版本能在约定日期交付，时间与依赖的判断仍要回到甘特图。团队先明确当前最需要回答哪类问题，再决定主视图，比争论哪种视图更先进更有用。
| 进度问题 | 更适合的视图 | 视图提供的具体信息 |
|---|---|---|
| 任务何时开始、何时结束，工期多长 | 甘特图 | 时间轴、任务条、工期长度 |
| 哪些任务存在前后置依赖，谁在等谁 | 甘特图 | 依赖连线、任务顺序 |
| 关键时间点、决策点是否按期到达 | 甘特图 | 里程碑标记 |
| 当前有多少任务在进行中 | 看板 | 状态列、任务卡片分布 |
| 任务卡在哪个环节，是否存在阻塞 | 看板 | 阻塞标记、列内积压情况 |
| 团队下一步应该拉取哪项工作 | 看板 | 待办列与在制品上限 |
同口径差异对照：时间、依赖、流动与协作
比较两种视图时，用统一的维度看差异，比逐条罗列功能更容易做出选择。下面从时间表达与计划粒度、依赖关系与关键路径、任务流动与在制品可视化、变更响应与协作方式、角色适配五个方面对照。
| 对照维度 | 甘特图 | 看板 |
|---|---|---|
| 时间表达与计划粒度 | 以日期和工期表达，适合周、月、季度跨度的计划；任务颗粒度通常到可排期的交付项 | 以状态和顺序表达，弱化具体日期；任务颗粒度通常到可在一两天内流转的工作项 |
| 依赖关系与关键路径 | 可标注前后置依赖，据此识别影响交付日期的关键链路；依赖越多，图的价值越大 | 依赖通常体现在卡片备注或阻塞标记中，不自动呈现跨任务的链路关系 |
| 任务流动与在制品可视化 | 能看出某段时间任务是否重叠，但对“当前卡在哪”反映较弱 | 状态列直接呈现流动，在制品上限和阻塞标记让积压位置一目了然 |
| 变更响应与协作方式 | 调整日期或依赖需要重排计划，适合变更受控、需要留痕的场景 | 拖动卡片即可反映状态变化，适合每日站会和持续调整节奏 |
| 角色适配 | 项目经理、版本负责人用它对齐交付承诺和跨团队依赖 | 开发、测试用它领取任务、暴露阻塞、控制并行数量 |
差异的核心在时间与流动的取舍。甘特图把不确定性收进日期和依赖里，代价是维护成本较高，计划一变就要重排；看板把不确定性交给流动规则，代价是难以直接回答“这个版本能否在月底交付”。依赖关系上，甘特图能呈现跨任务的链路，适合多团队协作的版本；看板更关注单项任务是否顺畅，跨任务依赖需要额外约定。协作方式上，甘特图偏向计划评审和变更记录，看板偏向每日同步和即时调整。角色适配也随之分化：项目经理需要时间与依赖的全局视图，开发和测试需要清晰的状态与阻塞信号。
研发项目中的典型使用场景与组合方式
场景判断比视图偏好更能决定选择。版本发布、多团队依赖、对外承诺交付日期这类场景，优先用甘特图。比如一个版本包含客户端、服务端、测试三条工作流，服务端接口未完成会阻塞客户端联调，这类前后置关系在甘特图上可以直接标出，版本负责人据此判断关键链路是否来得及。迭代执行、缺陷流转、日常任务领取这类场景，优先用看板。比如测试阶段缺陷从提交到修复到回归验证，用状态列和阻塞标记能快速看出积压发生在哪一环。
研发项目更常见的做法是组合使用：计划层用甘特图，执行层用看板。版本负责人在甘特图上排出里程碑和跨团队依赖，各工作流把可执行的任务放进看板，按状态推进；每日站会看看板的阻塞和在制品，版本评审回到甘特图核对日期与依赖。组合使用时有两处需要对齐：一是工作项字段，两个视图应基于同一套任务数据，避免甘特图上的任务和看板上的卡片各记一套；二是状态定义，看板的状态列要与甘特图上的完成判断口径一致，否则会出现看板显示已完成、甘特图仍显示进行中的情况。
在工具承载上，ONES 的项目计划支持创建工作分解结构、制定进度计划，并为任务设置前后置依赖、用里程碑标记重要时间点；ONES Plan 提供甘特图，支持多时间跨度查看进度和成员共享，并可监控及规划 ONES Project 中的相关项目和迭代，查看工作量和进度。组合使用时，团队可以把计划层的排期与依赖放在甘特图，把迭代内的任务推进放在项目协作视图中，让两个视图引用同一批工作项。具体到看板侧的状态列配置和在制品规则，需结合团队实际使用的版本方案确认。
适配场景与选择建议
按项目阶段看，立项与版本规划阶段依赖关系和交付日期最需要被看清，甘特图应作为主视图；进入迭代开发与测试阶段，任务流转速度和阻塞位置成为主要矛盾，看板应作为主视图。按团队规模看，单团队、依赖较少的项目可以先用看板维持流动，等出现跨团队依赖再引入甘特图；多团队协作、共享交付节点的项目，建议一开始就用甘特图明确依赖，再用看板管理各自执行。团队规模不是唯一依据，依赖复杂度和变更频率往往影响更大。
选择前可以用一份清单做验证：
- 依赖复杂度：任务之间是否存在大量前后置关系，跨团队交接是否频繁。依赖多且跨团队，甘特图的收益明显。
- 变更频率：计划是否经常调整。变更频繁时，甘特图的维护成本会上升，需要明确谁负责重排、多久同步一次。
- 角色协作方式：团队是否依赖每日站会推进任务。若是，看板的状态和在制品规则应成为日常节奏的一部分。
- 交付承诺：是否存在对外或对上的固定交付日期。若有，甘特图的里程碑和关键链路不可缺。
- 数据一致性：两个视图是否基于同一套工作项和状态定义，避免口径分叉。
试点建议选一个版本或一个迭代，同时启用两种视图，运行两到三周后复盘：甘特图上的依赖是否真的被用来做判断，看板上的阻塞标记是否被及时更新，两个视图的数据是否一致。根据复盘结果确定主视图和辅助视图，再逐步推广。常见误用有三类：把看板当成排期工具，用卡片顺序代替日期承诺；把甘特图做成每日任务清单，维护成本高但判断价值低；两个视图各维护一套任务，导致进度口径不一致。规避方式分别是：交付日期回到甘特图确认，日常推进交给看板；甘特图只排到可交付颗粒度；组合使用时坚持同一套工作项和状态定义。
常见问题
团队规模小、任务不多，还有必要同时用甘特图和看板吗？
可以先从一种视图起步。单团队、依赖较少的项目，用看板维持任务流动通常已经够用；等出现跨团队依赖或固定交付日期，再引入甘特图明确时间与依赖。判断依据是依赖复杂度和交付承诺，而非团队人数本身。若团队已有对外承诺的交付节点，即使规模小，也建议在甘特图上标出里程碑，避免日期只停留在口头约定。
甘特图和看板组合使用时，最容易出现什么问题？
最常见的问题是两套数据各记一份：甘特图上的任务和看板上的卡片不是同一批工作项，或者完成判断口径不一致，导致看板显示已完成、甘特图仍显示进行中。规避方式是在组合前先约定两件事：两个视图引用同一套工作项，状态列与甘特图的完成判断使用同一套定义。此外，甘特图只排到可交付颗粒度，日常任务推进交给看板，避免甘特图被做成每日任务清单而维护成本过高。
计划变更频繁的研发项目，还适合用甘特图吗？
适合，但需要配套维护规则。变更频繁时甘特图的重排成本会上升，团队要明确谁负责调整日期与依赖、多久同步一次，以及哪些变更需要留痕。如果变更主要发生在执行层，可以把甘特图固定在版本或里程碑层面，日常调整在看板上完成，减少甘特图的频繁改动。判断标准是甘特图上的依赖是否仍被用来做交付判断；如果依赖关系已经很少变化，甘特图的维护负担会明显下降。
看板能替代甘特图回答交付日期问题吗？
看板擅长呈现任务当前处于哪个状态、卡在哪一步，对“这个版本能否在月底交付”这类问题反映较弱。交付日期涉及任务工期、前后置依赖和关键链路，需要甘特图来承载。实践中可以让看板负责执行层的流动，交付日期的确认回到甘特图核对里程碑与依赖，两者分工而不是互相替代。
试点两种视图时，应该观察哪些信号来判断主视图？
试点运行两到三周后，可以观察三类信号：甘特图上的依赖是否真的被用来做排期和风险判断，看板上的阻塞标记是否被及时更新，两个视图的数据是否一致。如果团队大部分判断发生在依赖和日期上，甘特图适合作为主视图；如果主要讨论集中在任务卡点和并行数量上，看板适合作为主视图。根据复盘结果确定主视图与辅助视图，再逐步推广到其他版本或团队。
