软件项目付款里程碑

固定范围项目可以将付款与明确的交付物和验收证据关联起来。按时间和材料计费或采用预付服务费的工作，可以使用基于日历的计费方式，并配合经批准的工时记录和预算控制。应根据项目范围选择模式，并在工作开始前记录变更、延误和验收事项。

按日历付款需要额外控制的情况

可以考虑一个示例性方案：“签约时支付30%，第六周支付30%，第十二周支付40%。”如果付款只取决于日期，延期的固定范围项目仍可能触发开票。应加入双方同意的交付物、验收证据以及延误/变更处理流程；这只是示例，并非行业付款标准。

在每次付款前设置审核节点。对于固定范围的里程碑，应审核约定的交付物；对于按时间计费的工作，应审核获授权的工作、工时记录和预算。计费模式本身并不能证明项目进展。

适用于小型项目的结构

以下是固定范围项目的示例性分配，并非 Manboo 的定价或通用付款计划。五项比例合计为100%；合同必须明确实际交付物和支持条款。

每个阶段都有可验证的触发条件。“核心构建完成”意味着客户可以登录并走通主要工作流程，而不是开发人员声称已经完成。

定金

应围绕项目启动、预留产能以及定金所支持的工作，就定金金额达成一致。记录启动安排和定金对应的交付物；并不存在安排开发工作所必需的统一25%最低定金。

记录负责联系人、约定的启动安排，以及项目延期或取消时定金的处理方式。仅有定金并不能验证交付能力。

尾款留存

如果约定尾款留存，应明确其金额、释放日期和缺陷处理流程。上例中的5%是假设性分配，并非市场惯例。需要确定的两个条款是：

• 明确的期限，包含具体的开始和结束日期，或明确无歧义的触发条件，而不是无限期扣留。
• 明确的释放条件——保修期结束且没有未解决的缺陷，而不是笼统地以客户满意为条件。

无限期的尾款留存并不是真正的留存，而是开发人员未同意的折扣；合理的开发人员会拒绝这种安排。

应与付款计划一并写明的内容

1. 付款条款——开票后多少天付款。
2. 里程碑延期时的处理方式，分别说明因开发人员和因客户导致延期时的处理方式。客户导致的延期很常见，例如未提供反馈或未提供内容；忽略这类情况的计划反过来也不公平。
3. 变更请求的付款方式，因为变更请求不属于里程碑结构。
4. 终止时的处理方式——已完成工作的应付款项，以及需要移交的内容。

明确终止付款、已验收和未完成的交付物、代码仓库和部署移交、知识产权以及第三方许可限制。合同应说明谁可以使用相关工作成果以及应支付哪些款项；单独一句话无法解决所有权或终止相关的每个问题。

拟议付款计划中的警示信号

• 预付100%。对于非常小的工作，偶尔可能有合理性；除此之外通常意味着重大风险。
• 没有可验证触发条件的里程碑——例如“后端完成”，却没有定义什么算完成。
• 未定义上线后支持。明确约定的缺陷支持期限、维护范围和升级流程。即使没有尾款留存，也可以在合同中定义支持；不要依赖非正式承诺。
• 在验收前支付最后一笔款项。这会在最关键的节点恰恰反转谈判筹码。

相关 Manboo 服务

• 面向 iOS 和 Android MVP 的Flutter 应用开发。
• 面向 CRM、预订、库存和工作流程系统的业务软件开发。
• 面向运营仪表板和后台管理的管理面板开发。
• 当您的产品准备好进行智能搜索、聊天或自动化时，提供AI API 集成。
• 准备规划第一个版本时，可申请范围评审和项目估算。