很多项目方案里都有一页里程碑计划，横轴上几个圆点，标着需求确认、设计完成、开发完成、上线。真跑起来，除了延期的时候拿出来对一对，平时没人看。
里程碑该起的作用是让甲方在过程中就能发现问题，而不是等上线。做不到这一点，说明设的方式有问题。
一、里程碑要挂一个能看的东西
判断标准很简单，到了这一天，能不能拿出一样东西让人看。拿得出来的是真里程碑，拿不出来的只是墙上的日期。
需求确认这一天应该拿出签字的需求文档和原型。设计完成应该拿出全部页面设计稿，能点开看。开发完成不能只看一句已完成，要拿出可访问的测试环境地址，甲方自己能点进去操作。测试完成要有测试报告和已知问题清单。上线要有可用的正式环境和操作手册。
把交付物写进里程碑之后，进度的真假就一目了然。到期交不出东西，不用争论有没有拖延，事实就摆在那里。
二、每个里程碑都该有甲方要做的事
只写开发方该干什么的里程碑，最后一定会因为甲方环节卡住。合理的做法是每个里程碑下面同时写两行，开发方做什么，甲方做什么。
比如设计稿完成这个里程碑，开发方的动作是提交全部设计稿，甲方的动作是在三个工作日内确认或提出修改意见。如果甲方没按时确认，后面的日期自动顺延，这个规则要提前说好，并且写进合同或方案里。
把甲方的动作写明还有一个作用，能让业务部门意识到自己也是项目的一部分。很多人以为项目是交给外面做，自己只要等着用，这种心态是延期的主要原因。
三、里程碑的数量别太多也别太少
三个月左右的项目，五到七个里程碑比较合适。少于五个，中间隔得太久，出问题发现不及时。多于十个，每个都要走一遍确认流程，甲方也会疲。
按经验，项目前期里程碑要密一些，因为需求阶段最容易跑偏，越早发现越省钱。到了开发后期可以疏一些，留出连续的工作时间。
每个里程碑之间最好不超过三周。间隔太长的话，甲方那头的参与感会断掉，等到下次评审会，人对项目的记忆已经模糊了。
四、付款节奏跟着里程碑走
付款节点和里程碑对齐，是保护甲方最直接的手段。常见做法是分四笔，签约付三成，设计稿确认付三成，测试通过付三成，上线稳定运行一个月付一成。
比例可以协商，但两个原则值得坚持。一是上线之前要留足至少三成未付，保证开发方有动力做完全部工作。二是最后一笔要挂一段时间的稳定运行，而不是挂上线这个动作，因为上线当天的系统往往还有一堆小问题，运行一个月之后才算真稳。
反过来，如果甲方要求开发方先垫资做完再付，开发方通常会压缩投入的人力来控风险，最终受损的还是项目质量。合理的付款节奏对双方都有好处。