怎样排出一份经得起推敲的软件项目排期
软件项目为什么总是延期
很多软件项目的排期，其实只是开发工期。需求反复确认、原型来回改、测试环境迟迟搭不起来、甲方业务人员没时间做验收，这些时间在报价时没人算，最后全部变成延期。尤其是外包项目，合同上的交付日期往往和回款节点绑在一起，晚一周就意味着晚一笔钱。
这个模板把这些容易被忽略的环节都排了进去。第一个 Sprint 开始之前，需求、待办列表、原型和 UI 设计一共占 22 个工作日；三个 Sprint 的开发占 30 个工作日；功能测试与安全测试、UAT 验收、缺陷修复合计 15 个工作日，所以生产环境部署落在第 67 个工作日，之后再留 5 个工作日做上线监控。如果你手上的排期把八成时间都给了编码，就值得再看一遍。
它和产品发布计划不同：这里不管市场推广，只管把一个系统按时、按质交付，并且让甲方签字验收。
适合哪些团队使用
同一套排期，在不同项目里侧重点不一样，可以按下面的场景调整。
- 软件外包公司（乙方）承接定制开发：排期要作为投标文件或合同附件，需求确认、初验、终验通常对应付款节点，验收单上写谁签字、几天内签，都要提前约定。
- 企业信息部门开发内部系统，比如用 OA 流程或自研 CRM 替代 Excel 台账：没有合同压力，但要配合业务部门的数据迁移、培训和新旧系统并行。
- 互联网团队开新业务线，例如小程序加运营后台：迭代节奏快，排期主要用来对齐提测时间、灰度发布和运营活动的日子。
- 政府和国企项目：要走招投标，常常要求等保测评、国产化适配和完整的项目文档，审批环节不由开发团队控制，必须单独留出时间。
关键节点和交付物清单
把下面这些节点作为里程碑放进甘特图，甲乙双方对进度的理解就不容易出偏差。模板里没有单独的文档任务，建议加一项，与第三个 Sprint 和测试并行，不要等上线后再补。
- 需求规格说明书通过需求评审
- 交互原型和 UI 设计稿通过评审
- 技术方案评审：架构、数据库设计、接口规范
- 每个 Sprint 结束时的演示
- 提测：冒烟测试通过，提交提测单
- 测试报告和安全扫描报告
- UAT 验收通过，甲方签署初验单
- 上线方案、回滚预案和灰度发布
- 用户手册、接口文档、运维手册，以及软件著作权申请材料
- 试运行结束后终验
按步骤编排你的排期
第一步，和甲方一起把需求说清楚，并组织一次正式的需求评审。模板给了 5 个工作日，小系统够用，大系统可能要两三周。第二步，把需求拆成用户故事并写好验收标准，这是后面 UAT 时判断“做没做完”的依据。
第三步，架构设计和环境搭建与原型设计同时进行。模板里架构这条线有 8 个工作日的机动时间，稍微晚几天不影响上线，但 UI 设计稿一旦延误，Sprint 1 就得跟着推迟。第四步，把三个 Sprint 改成团队真正要交付的内容；范围更大时增加 Sprint，而不是硬把现有的拉长。
第五步，给提测、测试和 UAT 留足时间。最后排上线方案、生产环境部署这个里程碑，以及上线后的监控和保障期。在 Great Gantt 里修改任何一项工期，后续日期都会按工作日自动重排，关键路径也会高亮显示。
国内项目要额外留出的时间
春节前后通常有两周左右基本推不动，国庆也有 7 天长假，还要注意调休，周末上班的日子要在日历里标成工作日。等保二级、三级测评一般需要数周，最好在 UAT 阶段就和测评机构约好时间。面向公众的系统还涉及 ICP 备案，App 上架和小程序审核也各有周期，这些都应该作为单独的任务放进进度计划。
计划确认后，保存一条基线。每次 Sprint 评审时对比实际进度和基线，延误能在提测前几周就被看见，而不是上线前一周才暴露。需要向甲方或领导汇报时，可以导出 PDF 或 Excel。