开发进度总说 80%，剩下的 20% 为什么永远做不完

「进度怎么样了？」「快好了，80%。」——两周后再问，还是 80%。这种情况在软件项目里极其常见，几乎成了一种行业默契。

多数时候不是开发在撒谎，而是软件项目的完成度本身就很难度量。剩下那 20%，往往包含了最难的部分。

一、为什么永远是 80%

• 前 80% 是「能跑起来」：页面能打开、流程能走通、数据能存进去，看起来就快成了；
• 后 20% 是「能交付」：异常处理、边界条件、权限、日志、性能、兼容、部署、文档；
• 越往后，问题越碎，且大量依赖业务方确认，不是开发一个人能推的；
• 「完成度」通常按功能点算，不按工作量算，一个功能「做完了」和「可以上线」之间，常常还差一倍工时。

所以 80% 这个数字，往往对应真实工作量的一半左右。

二、把进度拆成可验证的节点

不要问「百分之几」，改问「这周能演示哪几个场景」。可验证的节点长这样：

• 能用真实数据跑通一条完整业务链，比如下单、支付、发货、对账；
• 异常场景有明确提示，不是白屏或者一串报错代码；
• 权限按角色区分，越权访问确实被拦住；
• 已部署到测试环境，业务方可以自己点、自己试。

每个节点都能当场演示，演示不过就是没过。这比任何百分比都实在。

三、里程碑付款怎么设

常见做法是「3-3-3-1」：签约 30%、原型与设计确认 30%、核心功能验收 30%、上线稳定运行一个月 10%。几个要点：

• 每个节点配明确的验收标准，写进合同附件，不用「基本完成」这种词；
• 约定验收期限：甲方在多少天内不提意见视为通过；
• 尾款比例别太低，也别高到让乙方现金流断裂，影响后期投入；
• 需求变更单独计价，不要用「包含在总价里」含糊过去。

四、工期延误的责任怎么分

延误通常来自三个方面：乙方人力不足或技术方案失误；甲方需求变更、资料提供不及时、验收拖延；第三方依赖（接口审批、应用商店审核、云资源到位）。

合同里应当分别约定：乙方原因延误的违约责任、甲方原因导致的工期顺延、第三方原因的告知与共同应对。如果全部写成「乙方承担一切延误」，实际执行时往往扯不清，最后谁都不认。

五、甲方自己能做的四件事

• 指定唯一的决策人，避免业务、老板、运营多头提意见；
• 需求一次说清，后续变更走书面变更单，口头修改不算数；
• 每周看一次演示，不要等到验收才第一次看到系统；
• 提前准备测试数据和真实业务场景，别让开发用假数据自测自夸。

很多项目的延期，根子在甲方内部：没人拍板、需求反复、验收没人敢签字。

六、如果已经卡在 80%

先做范围裁剪：把「必须有」和「可以有」分开，先让必须有上线；再确认阻塞点：是技术难题、是人手不足、还是卡在等甲方确认；最后重排时间表，把剩余的碎活列成清单，逐项销号。

不要再用「快好了」互相安慰，那只会把问题推到上线之后。

写在最后

软件项目的进度管理，本质是把「感觉」换成「证据」。能演示的东西才算完成。名牌商务网提供软件定制开发与项目监理咨询，可以在立项阶段把节点、验收标准和付款节奏一起定下来。