研发项目进度管理选甘特图还是看板，取决于团队要回答的进度问题。甘特图以时间轴承载任务起止、依赖与交付节点，适合排期和识别前后置关系；看板以状态列承载工作项流转，适合需求持续进入、需要暴露在制品与瓶颈的团队。多数研发项目按“计划层用甘特图、执行层用看板”组合使用，判断依据是时间约束强度、依赖复杂度和需求变动频率。
要点总览（TL;DR）
- 甘特图回答“什么时候做完”，以时间轴呈现任务起止、依赖和关键路径；看板回答“现在卡在哪”，以状态列呈现工作项流转和在制品积压。
- 交付节点硬、任务依赖多、需求相对稳定时，甘特图作为主视图更合适；需求持续进入、优先级频繁调整、关注流转效率时，看板更直接。
- 多数研发项目按计划层用甘特图、执行层用看板组合使用，两层共享同一批工作项，状态变化回写排期，排期调整同步到执行视图。
- 选择依据可归为时间约束强度、依赖复杂度和需求变动频率三条，建议先用一个迭代或一个交付周期试运行，观察排期偏差与流转积压。
甘特图与看板各自回答什么进度问题
甘特图和看板在研发项目里承担不同的进度问题。把它们放在同一张表上比较“哪个更好”，容易得出模糊结论；先分清各自回答什么，选择才有依据。
甘特图的核心对象是任务及其时间属性。每个任务有开始时间、结束时间、持续时长，任务之间可以设置前后置依赖，整体沿一条时间轴展开。项目经理通过甘特图回答的是“什么时候做完”：某项任务计划何时开始、何时结束，前置任务延期会不会影响后续任务，关键路径上的节点能否按期交付。它把时间作为第一维度，进度表现为计划条与实际完成情况在时间轴上的偏差。
看板的核心对象是工作项及其状态。工作项按状态列排列，从待处理、进行中到待验证、已完成，团队以拉动方式领取任务，状态列之间可以设置在制品限制。看板回答的是“现在卡在哪”：哪些工作项堆积在某一阶段，哪个环节的在制品超过团队处理能力，需求从进入到完成的流动是否顺畅。它把状态流转作为第一维度，进度表现为工作项在各列之间的移动速度和积压情况。
这两类问题在研发项目中同时存在。团队既需要知道一个版本能否在承诺日期交付，也需要知道当前迭代里测试环节是否积压。因此，同一批研发工作项可以同时被两种视图呈现：甘特图读取任务的时间与依赖字段，看板读取任务的状态字段。视图不同，数据来源可以是同一套工作项，这也是后文讨论组合使用的基础。
判断归属时可以用一个简单方法：如果团队当前最需要解决的问题是“交付日期能否守住、前后任务会不会互相拖累”，优先建立甘特图；如果最需要解决的问题是“工作在哪一列停得最久、团队同时开工是否过多”，优先建立看板。两类问题都突出时，进入组合使用的讨论。
同口径差异对照：时间、依赖、流转与变更
把两种视图放在时间表达、依赖管理、变更响应、进度可见性和使用维护成本五个维度上对照，可以看出差异集中在“显式计划”与“流动状态”两种管理方式上。下表按同一口径列出两种视图的表现。
| 比较维度 | 甘特图 | 看板 |
|---|---|---|
| 时间表达 | 显式排期，每个任务有起止时间和持续时长，整体沿时间轴展开 | 不直接排定每个工作项的日期，通过周期、流动时间和完成趋势间接体现进度 |
| 依赖管理 | 可设置任务前后置依赖，识别关键路径，评估某一任务延期对后续任务的影响 | 侧重状态流转，依赖通常体现为工作项之间的关联或阻塞标记，不形成时间链 |
| 变更响应 | 排期调整敏感，插入新任务需要重排时间、复核依赖与关键路径 | 对需求插入更灵活，新工作项进入待处理列后按优先级排队，由团队拉动领取 |
| 进度可见性 | 看整体时间偏差：计划与实际的时间差、里程碑是否临近或滑移 | 看阶段积压与在制品：各状态列的工作项数量、停留时长、瓶颈环节 |
| 使用与维护成本 | 维护排期与依赖需要持续投入，任务粒度越细、依赖越多，维护量越大 | 维护状态列相对轻，主要成本在状态定义与流转规则的统一 |
这张对照表说明，两种视图的成本结构不同。甘特图的前期投入在排期和依赖梳理，收益是时间偏差和交付风险可提前看到；看板的前期投入在状态列设计和流转规则约定，收益是瓶颈和积压能及时暴露。团队选择时，应把维护成本与需要获得的进度信息放在一起权衡，而不是只看哪一种视图更直观。
还需要注意，两种视图对“进度”的定义不同。甘特图的进度是相对计划时间的完成比例，看板的进度是工作项在状态序列中的位置和流动速度。同一个工作项在甘特图上显示“按计划进行”，在看板上可能正积压在测试列。两种信号并不矛盾，它们描述的是不同层面的状态，组合使用时需要同时读取。
研发项目在什么条件下选甘特图
甘特图适合时间约束明确、任务依赖较强的研发项目。以下条件出现得越多，甘特图作为主视图的价值越大。
- 存在明确交付节点与外部承诺时间。例如版本对外发布日、客户验收日、与其他系统联调的时间窗口。这类日期一旦承诺，团队需要一条统一的时间基线来安排任务，甘特图能把每个任务与交付节点对齐。
- 任务间有较强前后置依赖，需要识别关键路径。需求评审完成才能进入开发，接口定义完成才能联调，测试环境就绪才能执行系统测试。依赖链越长，越需要甘特图把前后置关系画出来，找出决定整体工期的关键路径。
- 多团队或多角色并行，需要统一时间基线对齐。前端、后端、测试、运维各自排期时，甘特图提供共同的时间参照，减少“我以为你们下周才交付”这类错位。
- 排期变更需要评估对整体交付的影响。当某个任务延期或插入新需求时，团队需要快速判断影响哪些后续任务、是否冲击交付节点。甘特图的依赖链让这种影响评估有据可依。
选择甘特图有两个适用前提。一是任务粒度可估时，任务拆分到能够给出合理工期估计的程度，否则排期只是形式；二是依赖关系可明确，团队能说清任务之间的先后顺序。如果任务边界模糊、依赖经常变化，甘特图的维护成本会迅速上升，此时应先改善任务拆分，再决定是否以甘特图为主视图。
一个判断信号是：团队在进度会议上反复讨论“这个任务会不会影响那个节点”，却缺少一张能直接看到依赖和时间偏差的图。出现这种情况，说明甘特图要解决的问题已经存在。
研发项目在什么条件下选看板
看板适合需求持续进入、按状态推进的研发场景。以下条件可以作为选择看板的判断信号。
- 需求持续进入、优先级频繁调整。产品需求、线上问题、技术优化交替进入团队，排期难以提前固定。看板让新工作项进入待处理列并按优先级排队，团队按当前能力领取，减少频繁重排整张计划。
- 关注工作项在各阶段的流转效率与积压。团队需要知道需求在评审、开发、测试各环节停留多久，哪一列经常堆积。看板按状态列呈现工作项，积压位置一目了然。
- 需要限制在制品以暴露瓶颈。团队同时开工过多时，完成速度反而下降。给状态列设置在制品上限，可以迫使团队先完成再领取，让瓶颈环节显现出来。
- 团队按状态推进、以拉动方式领取任务。成员从待处理列自行领取工作项，完成后移动到下一列，管理动作集中在状态流转和阻塞处理上。
看板的适用前提是状态列定义清晰、流转规则稳定。状态列过多会让看板变成一张复杂的流程图，状态列过少则无法暴露中间环节的积压。团队需要约定每个状态列的进入条件和完成条件，例如“开发中”列的工作项必须已有明确验收标准，“待验证”列必须已提交测试。流转规则稳定后，看板上的积压和停留时长才有解释力。
一个判断信号是：团队说不清当前有多少工作同时在进行，测试环节经常在迭代末期集中爆发，或者需求插入后原有计划频繁失效。这些现象指向流转和在制品问题，看板是更直接的视图。
组合使用：计划层与执行层如何分工
多数研发项目并不需要在两种视图之间二选一。更常见的做法是分层使用：计划层用甘特图确定里程碑、依赖与时间基线，执行层用看板承载日常流转与在制品控制。两层分工的关键是共享同一批工作项，避免双份维护。
计划层的职责是回答“交付能否守住”。项目经理在计划层把版本目标拆解为任务，设置起止时间、前后置依赖和里程碑，形成时间基线。当外部承诺日期确定后，计划层是评估排期可行性和变更影响的依据。
执行层的职责是回答“当前流动是否顺畅”。团队在日常工作中使用看板，按状态列推进工作项，控制在制品数量，处理阻塞。看板上的状态变化是执行层最及时的信号。
两层衔接需要遵守几条规则：
- 共享工作项。甘特图上的任务与看板上的工作项是同一对象，状态、负责人、时间字段来自同一数据源，避免在两张表里各维护一份。
- 状态变化回写排期。工作项在看板上完成或阻塞时，计划层的时间偏差随之更新，项目经理不需要手工同步。
- 排期调整同步到执行视图。计划层调整任务时间或依赖后，执行层的工作项优先级和截止信息同步更新，团队看到的是同一套安排。
衔接处需要设置检查点：依赖变更时，复核关键路径是否改变；里程碑临近时，对照计划层偏差和执行层积压，判断是否需要调整资源；在制品超限时，检查是否由计划层任务集中到期引起。这些检查点让两层视图互相校验，而不是各自独立运行。
在工具承载上，ONES 的项目计划支持创建工作分解结构、制定进度计划，并为任务设置前后置依赖和里程碑；ONES Plan 提供甘特图，可多时间跨度查看进度，并监控及规划 ONES Project 中的项目和迭代。计划层与执行层共享工作项的衔接方式，可以在同一项目下管理需求范围、研发任务，并在项目计划中关联迭代和研发任务，让状态变化与排期调整在同一套工作项上发生。团队可以据此把甘特图用于计划层、看板用于执行层，减少两套数据之间的手工同步。
适配场景与选择建议
把前文的依据收束成可执行的判断路径，可以按三个特征依次判断：时间约束强度、依赖复杂度、需求变动频率。
| 项目特征 | 建议主视图 | 判断理由 |
|---|---|---|
| 交付节点硬、任务依赖多、需求相对稳定 | 甘特图为主 | 需要显式排期、识别关键路径、评估变更对交付的影响 |
| 需求持续进入、优先级频繁调整、关注流转效率 | 看板为主 | 需要灵活排队、限制在制品、暴露阶段积压 |
| 既有明确交付节点，又有持续进入的需求和并行团队 | 计划层甘特图加执行层看板 | 两层回答不同问题，共享工作项即可避免双份维护 |
组合使用的判断条件可以更具体一些：项目存在对外承诺的交付日期，同时团队在一个交付周期内会接收计划外需求；或者任务依赖链较长，但日常执行需要按状态推进并控制同时开工数量。这两类情况都适合分层使用，而不是把全部任务塞进一张甘特图或一块看板。
确定方向后，建议先用一个迭代或一个交付周期试运行，观察两个指标：排期偏差和流转积压。排期偏差看计划时间与实际完成时间的差距是否在可接受范围，流转积压看状态列是否出现持续堆积。试运行期间保持工作项单一来源，记录哪些信息在甘特图上缺失、哪些在看板上看不清，再据此调整视图分工和字段设置。
本文聚焦研发项目进度视图的选择与分工，综合状态汇报与里程碑达成判定不在本文展开。团队在完成视图选择后，可以另行建立状态报告和里程碑验收机制，与本文的进度视图配合使用。
常见问题
团队规模较小、任务依赖不多，还有必要同时维护甘特图和看板吗？
不一定需要同时维护两张视图。如果团队规模小、任务依赖少、交付节点相对宽松，可以先选一种主视图运行。判断依据是当前最突出的进度问题：如果主要是“交付日期能否守住”，先用甘特图；如果主要是“工作在哪一列停得最久”，先用看板。等出现两类问题并存的信号，再考虑分层使用，并确保两层共享同一批工作项，避免双份维护。
需求变动频繁的研发项目，用甘特图会不会很快失效？
需求变动频繁时，甘特图的排期调整确实更敏感，插入新任务需要重排时间、复核依赖与关键路径。但这不意味着甘特图不能用，而是需要控制使用范围：把甘特图用在相对稳定的交付节点和关键依赖链上，把频繁变动的需求放到执行层的看板中排队和拉动。如果需求变动已经导致排期频繁失效，可以先检查任务拆分粒度和依赖关系是否稳定，再决定是否以甘特图作为主视图。
看板的在制品限制应该怎么设置，设置后团队不习惯怎么办？
在制品限制没有统一数值，可以从团队当前同时进行的工作项数量出发，先设置一个略低于现状的上限，观察一两周内是否出现持续阻塞。设置后团队不习惯，通常是因为限制值与实际处理能力不匹配，或者状态列的进入和完成条件不清晰。建议先明确每个状态列的含义和流转规则，再逐步收紧在制品上限，让限制成为暴露瓶颈的信号，而不是额外的管理负担。
计划层甘特图和执行层看板共享工作项，具体要保证哪些字段一致？
至少需要保证工作项的状态、负责人、开始与结束时间、依赖关系来自同一数据源。状态变化时，计划层的时间偏差应随之更新；排期调整后，执行层的工作项优先级和截止信息应同步变化。团队不需要在两张表里各维护一份，否则会出现甘特图显示按计划进行、看板却已积压的矛盾信号。衔接处可以设置检查点：依赖变更时复核关键路径，里程碑临近时对照偏差与积压，在制品超限时检查是否由计划层任务集中到期引起。
试运行一个迭代后，应该看哪些指标来判断视图选择是否合适？
重点观察两个指标：排期偏差和流转积压。排期偏差看计划时间与实际完成时间的差距是否在可接受范围，如果偏差持续扩大，说明甘特图的排期依据或任务粒度需要调整；流转积压看状态列是否出现持续堆积，如果某一列长期超限，说明看板的状态定义或在制品限制需要复核。同时记录哪些信息在甘特图上缺失、哪些在看板上看不清，据此调整视图分工和字段设置，而不是在试运行结束后直接推翻原有选择。
