对于不断变化的软件项目,范围管理是非常麻烦的事,特别是国内的软件项目。 据朋友介绍,在欧美,不少软件项目的范围和需求是第三方咨询公司完成的,开发公司在立项之时已经有“法定”的项目范围和需求,这样就避免了很多范围管理上的问题。 在PMBOK中,项目的启动是以合同、工作说明或者初步的产品描述作为基本输入的,因为这里面有项目范围的雏形。 在国内不少软件项目,合同的签订往往滞后于项目的启动,客户由于不明确知道自己到底需要一个什么东西,往往无法提出所谓的产品描述或者工作说明,他们希望先看到一个东西,然后做类比,过滤出项目范围(和产品特性),这就是所谓的“快速原形法”。有一个朋友建议一个项目签2个合同,一个是需求调研合同,以确定项目范围和软件需求为目标,另一个就是开发合同。。。很受启发~ CASE 1: 我公司在2年前做第一个项目(从零开始)的时候,差不多化了3个月(9个人月)的时间在客户现场,反复沟通才初步确定项目范围和初步需求(然而这个时候合同还没有签订,如果这个合同没有签下来,这9个人月就成了沉没成本!!),在2年的不断升级中,范围和需求都不断频繁的变更。。。 CASE 2: 最近和另外一个客户在合同谈判期间,由于是类似的产品,我们在产品(以前那个项目完成的东东)演示上做足功夫,很快,客户在看了演示后,就提出了各种各样的问题,不到1周时间,项目范围的雏形就形成了,对顶层的产品特性也有了比较大的把握。 两个案例的对比,从一个侧面提示在国内做软件项目,对范围管理要有灵活(比如:快速原形)的做法,在这点上,pmbok不一定能帮什么忙,或许还会限制你的选择:还没有合同、范围,我怎么做啊? 良好的范围定义和管理,也可以屏蔽项目验收的不少问题。。
|