在之前监理的国内项目中，有很多项目都存在一个共性，那就是：国内项目邀标的时间很早，但是从合同签订到软件交付的时间却是非常的紧急。而且，基本上都是有很严格的上线时间，毕竟客户领导向上面汇报也是有时间要求的，一旦定下来是不愿意往后拖的，这种状况在大中型国企的项目中尤为明显。
举个目前跟进的实例来说：从最初接触客户到交付整个周期差不多有1年的时间，项目的整体规模也就100人月，照说怎么都是够的。可是，时间却是这么消费的：接触到确定给公司做花掉了3个月，然后到合同签订花掉了3个月，真正给的时间只有6个月。这其中还包括需求调研的时间，调研的对象大概有100个工作单位。
这样项目就需要在某个时间段需要同时投入大量的人力，这将会直接导致：
1. 峰值人员的倍数增加，管理和沟通成本升高。
2. 公司的整体人力资源调配波峰值增加，风险升高，空闲率升高。
3. 遇到人力资源无法满足时，会长期出现赶进度的状态，人员效率降低。
4. 为了保证按期交付，前期会牺牲质量控制和保证的工作，上线后会出现较多缺陷，客户满意度下降，同时人力成本增加。
为了解决以上问题，需要在项目实施方式上做一些调整：
1. 交付方式：国内项目都喜欢一次性交付，毕竟领导的概念中交付就可以看到所有的东西，多好。可是这样的交付风险是很大的，一般只到最后一周才知道是否真的能按期交付，万一不能按期交付，双方都是受害者。
我们可以将整个软件项目拆分成几个相对独立的模块集，根据模块集的规模和难度，将整个周期进行划分，分阶段进行交付。
这样客户领导会不断的看到有成果物提交，哪怕万一最终大家都非常努力了还是实在不能按时交付，至少也有部分成果是可用的；同时，也对延期的时间有个比较准确的估计。
前期交付的产出物还可以部署给最终客户使用和验收，缺陷和不确定性需求都可以提前发现。一方面可以提高软件的稳定性，另一方面还可以及时调整后面的计划。
大家会问，为什么分批交付这么好，国内项目却用的很少呢？
分批交付固然好，但是也有一些制约因素：
A. 需求的极度不确定性是个大问题，这个放到后面单独博文描述。
B. 分批其实是需要项目经理对软件开发技术有深刻了解，这样才能做出合理的分批方案。
毕竟所谓的独立业务其实也是有关联性的，一旦分批交付又要让交付产品能运作起来，那么就需要在系统设计和交付设计上下功夫。就类似于我们做白盒的单体测试时，需要自己编写一部分桩模块来替代一些未完成的基础功能。分批交付也需要做这样的设计和活动。
交付的顺序也是需要仔细考虑的。一般来说，交付物分配如下：
a. 第一批交付物包括：系统设置功能+1/5的功能模块。
b. 第二批交付物包括：已确定的外部接口功能+3/5的功能模块。
c. 第三批交付物包括：剩下的外部接口+1/5的功能模块。
交付批次不能太多，太多了会增加双方的沟通和实施成本，同时也容易引起不必要的需求变化。也不能只根据功能来划分，要考虑系统基础设置、外部接口、性能优化等因素。一般来说，
以MIS为主的100人月以上的项目可以按照以上方式分批交付，50-100人月的项目可以考虑分两批交付，50人月以下的项目就不怎么考虑分批交付了。
