CMMI过程改进之路—需求管理误区

　　在项目管理中，需求的重要性是众所周知的，在IT业界的研究是：高达60%缺陷来源于需求不清晰，超过80%的项目维护成本用于需求问题处理，需求管理影响了整个项目成败，而关键项目成败则影响了公司的生存。
　
　　在需求管理中常遇到三种情况：

    （1）需求定义清晰，没有异议性：

    对于这种情况处理，我们一般要根据项目规模的大小进行同行专家评审，根据成本/效益之比，可以采用walkthouth或Inspection的方式来确定项目需求说明书；对于需求的跟踪，可以根据实际情况，采用需求跟踪矩阵，主要目的是跟踪相对应的Function需求在设计、编码、测试阶段是否有遗漏，其实并不是必须的，如果项目规模很小，或者可裁剪掉或者可以采用其他替代方式。
　
　　（2）项目需求有部分不明确：

    我们一般都会采取分期实施的办法，先进行需求明确的一期的需求合同的开发，如有重大变更，征得客户同意后列入下期开发，这样相对容易规避风险，否则项目永远没有完结的时候，质量也难以保证。
　
　　（3）项目需求基本上都是未知的：

    这种项目风险最大，如果采用闭门造车，可能采用了很好的技术，结果却找不到市场，造成投资血本无归。一般而言，我们都采用原型Demo的方法，让典型的客户去参与原型的评审，不断确认需求，形成需求基线。相信这种方法能有效缓解风险。
　
　　对于项目需求控制，一般都是采取与客户协商的方式进行：“客户就是上帝”，是的，但并不表示客户的所有需求都要马上得到满足，曾经看过一些公司，规模都很大，所做的项目都是全省推行的，一般人都会想，项目利润是很大的。但是询问起来，都是有苦难言，都说公司没有真正赚到钱。后来一分析情况，发现项目估算时，软硬件原来都是有较大利润的，但最后都倒贴到后期的维护成本。根本原因公司为了争取客户，对于每个大客户的需求都无条件满足，定制化版本，每个地级市都有一个版本，可想而知，整个省就有二、三十个版本。前期开发是工作量不算太大，在原始版本上修修改改，多加点功能，当时客户满意度都很好，但一旦所有地方版本都上线了，麻烦就来了。单一个产品就要维护如此之多版本，维护成本可想而知，公司还要不要生存？公司发展就会因此而被拖累，甚至被市场淘汰。
　
　　针对这种情况，一般而言，都是采取与财政拨款的上级单位一起控制需求，统一版本。业内有些公司的做法是很好的，对于全省的项目，取得省相关部门的支持，和省公司一起共同分级规范全省需求提出（如根据重要性、紧急性分为ABCD类需求，每类需求成本是多少，一清二楚，而且也有计划），能有效地避免版本的频繁变更，保证了项目质量，也大大地提升了客户满意度。