阶段里程碑要写成“可验收的交付物+验收方式+确认期限+超期处理”,而不是只写“完成设计”“完成开发”。判断标准很简单:把这一条交给没有参与沟通的人看,他能否判断当前是否完成、由谁确认、确认后进入哪一步。若不能,这条里程碑就还不具备约束力。
常见写法是“第1周需求确认、第2周设计、第4周上线”。它只描述时间,不描述交付物。到验收时,双方对“需求确认”的理解可能完全不同:一方认为口头聊过即可,另一方认为要有签字文档。争议不是出在态度,而是出在约定颗粒度。
另一个现象是里程碑与付款、素材提供、域名和服务器准备脱节。建站项目里,客户方延迟提供文案、图片、备案资料,会直接推迟后续节点。如果里程碑只约束服务方,不写客户方义务和等待规则,进度表就失去意义。
适用条件要说明:需求已经相对明确的项目,可以按设计、开发、测试、上线划分;需求仍在探索的项目,更适合先设“需求冻结”里程碑,再进入固定报价和排期。判断结果是,如果需求未冻结就承诺总价和总工期,后续变更几乎必然引发争议。
建议用表格或清单形式落到书面附件,与主合同同等效力。可以按下面的结构逐条填写:
涉及代码或技术交付时,交付物可以写成可核对的描述,例如“测试环境返回状态码200的页面清单”,而不是只写“网站能打开”。如果约定中需要提到标签示例,应写成文字形式,如<h2>,避免歧义。
每个里程碑确认时做一次复查,记录确认时间、确认人、遗留问题。上线前再整体对照一次:所有阶段是否都有确认记录,未完成项是否已转为书面待办,付款节点是否与实际交付匹配。
如果出现延期,先区分原因:是服务方未交付,还是客户方前置条件未满足,或是双方对验收标准理解不同。不同原因对应不同处理,不能一律归为“项目延期”。
下一步可以直接做一件事:把现有报价单或合同里的阶段名称逐条改写成“交付物+验收方式+确认期限”,再发给对方确认。改写后仍无法判断是否完成的条目,就是需要继续谈清楚的条目。