一、进度管理从分解开始

项目计划里只写一个"几个月后上线"，中途任何偏差都要等到最后才看得见。临沂物联网应用公司的做法是把长项目切成里程碑：需求冻结、设计评审通过、硬件联调完成、试运行开始，每个里程碑对照标准检查达成情况。在物联网应用这类周期长、环节多的项目里，里程碑就是中途的方向盘。

对企业方来说，理解软件开发的进度规律也很重要。需求调研与设计阶段看不到"明显进展"，不代表团队在闲着；编码期看起来热火朝天，不代表离上线很近。把每个阶段的交付物（需求文档、原型、测试报告）作为检查点，比单纯盯"写了多少页面"更能判断项目真实进度。

进度管理的最终目的不是把日期守得分毫不差，而是让交付可预期。可预期的项目里，客户敢安排推广计划，团队敢安排资源，商务敢做承诺。建立在透明、分解、检查点之上的进度管理，带来的是整个协作链条的确定性。

二、甘特图怎么用

软件项目进度管理的第一步是工作分解。"做一套系统"这样的大目标无法估算工期，必须拆到用户登录模块、商品列表页、订单接口这样粒度的工作包，每个工作包估算工时、指定负责人、定好完成标准。拆得太粗没法跟踪，拆得太细管理成本又过高，经验上单个工作包一到三天的工作量比较合适。

分解完任务之后要排依赖关系。哪些任务必须等前一个完成才能开始，哪些可以并行，连成网络图之后，那条最长的任务链就是关键路径——它决定了项目的最短工期，链上任何一个任务延期，整个项目必然延期。管理者的精力应当优先盯在关键路径上，非关键路径上的任务则有一定机动余量可以调配。

甘特图是最直观的进度展示方式：横轴时间、纵轴任务，横条标出每个任务的起止。它的价值不只是排计划，更是让各方对"什么时候该看到什么"有统一预期。实践中很多项目计划做完就锁进抽屉，真正发挥作用的甘特图是每周更新、对着它过进度的那一份。

里程碑不占工期，但让长项目始终有中途体检的机会。

进度延误的原因可以归为几类：需求没说清导致返工、估算时低估了联调与测试时间、关键人员被临时抽调、第三方接口迟迟不交付、风险发生时没有预案。其中最普遍的是把开发时长当成总时长，忘了测试、修复、联调、部署各自需要的周期，计划排得满满当当，实际一跑就延期。

延误之后最常见的应对是赶工：加班、加人、砍测试。但软件项目有其规律，向已经延期的项目继续加人，沟通与培训成本往往让项目更加延期，这是被反复验证过的经验。更稳妥的做法是回到范围、时间、成本、质量的权衡桌上：要么砍范围，要么延时间，要么加预算，三者总要动一个，指望靠硬扛全都保住是不现实的。

备注：多设里程碑检查点，比单点押注上线日更可控。