你们的周期看起来比较快，后续会不会持续延期？

结论：没有负责任的团队能承诺项目永不延期。判断滚水科技的周期是否可信，应看排期是否包含需求、设计、开发、联调、测试、整改和上线，关键依赖是否有负责人和日期，以及每次预测是否由已完成成果更新。范围改变或外部依赖延迟时，应保留原基线并书面给出影响和选择，不能悄悄把截止日往后移。

快不一定危险，慢也不代表稳。成熟组件、明确范围和并行团队可以缩短日历时间；模糊需求、未取得接口和层层决策则会让任何报价失真。需要审查的是估算依据和过程证据，而不是比较两家公司口头给出的总周数。

延期来源	早期信号	应怎样处理	客户能看到的证据
范围持续增加	待办增长快于完成、验收条件反复变化	变更评估后替换、延后或追加资源预算	原范围、变更单和新旧基线
客户决策或材料等待	未决问题老化、账号和内容未到位	指定负责人、截止日和默认或降级选择	依赖清单与阻塞时长
第三方接口不确定	无沙箱、无样例、配额或权限未批	先验证关键调用、准备 mock 和退出方案	接口验证记录与供应商反馈
技术或质量低估	缺陷重开、集成频繁失败、返工增加	缩小并行、处理根因、重估剩余工作	构建、测试和缺陷趋势
团队产能变化	关键人员单点、完成量持续下滑	知识备份、重新分配并更新预测	人员风险和交接状态
审核或监管变化	政策更新、材料被退、功能需整改	隔离受影响功能或调整发布日期	官方反馈、整改项和重提状态

可信排期必须同时显示基线和预测

基线是双方在某个范围、资源和假设下确认的计划，用来判断是否偏离；预测是根据今天已完成工作、剩余工作和风险得到的最新区间。二者不能互相覆盖。如果原定 6 月上线、增加功能后改到 7 月，报告应同时显示原基线、变更原因和批准人，而不是把 7 月重新写成“始终按计划”。

每个工作项只有达到完成定义才计入完成：代码合并但未联调、页面做好但接口是假数据、测试发现严重缺陷未关，都不应算 90%。展示可运行版本、测试结果和验收样本比颜色漂亮的甘特图更可靠。对剩余工作用团队实际吞吐和完成周期更新预测，给出区间而不是精确到某一天的伪确定性。

风险预警要以决策窗口为准

“提前两周预警”不是通用保证。有些依赖在立项当天就必须解决，有些故障当天发生。风险记录至少包含发生概率、影响、触发信号、负责人、缓解动作、最迟决策时间和备选方案。预警应在客户仍能选择缩范围、换供应商或调整发布策略时发出，而不是等日期必然错过才通知。

周报只列“本周完成、下周计划”还不够。应显示本期承诺、实际完成、未完成原因、累计阻塞、需求变化、缺陷趋势、关键路径和最新上线区间。会议结论落到决定记录；客户若延期反馈，也作为依赖事实记录，但不用于甩责。双方共同目标是尽早看到偏差并做取舍。

缓冲也不能机械写成 15% 或 20%。风险高的未知接口可能需要先做技术验证，低风险重复模块可以使用较小不确定区间。缓冲应附着在已识别风险或整体预测分布上，不应被当成可以随意塞新需求的空闲时间。增加人手也未必立刻缩短关键路径，新成员培训和模块耦合可能先降低速度。

里程碑验收使用实际环境和关键任务。项目中期至少应能演示一条端到端闭环，而不是所有模块都“各完成 80%”但不能集成。上线门槛包括严重缺陷处置、生产配置、监控、备份恢复、回滚和运营负责人，不能为守日期把未测试版本直接推向用户。

滚水科技会保留最初范围和排期，在需求看板、演示环境、版本、测试和风险记录中持续展示事实。发生偏差时提供至少两种可执行选择，例如守日期缩非核心范围，或守范围调整日期；成本和风险一起写清，由客户负责人决定。合同中的延期责任、客户依赖和第三方排除项仍以双方书面约定为准。

参考资料：

• 滚水透明交付标准：用于核对本站公开的里程碑、需求变更、客户依赖、风险暴露与交付证据原则。
• 滚水科技软件开发服务流程：用于了解需求、设计、研发、测试、验收和上线如何形成完整排期，具体日期仍以项目计划与合同为准。
• The Scrum Guide 官方版本：用于参考基于可用增量进行检查和调整的方法，不用于证明某个项目不会延期。