Chinaunix首页 | 论坛 | 博客
  • 博客访问: 744009
  • 博文数量: 769
  • 博客积分: 6000
  • 博客等级: 准将
  • 技术积分: 4985
  • 用 户 组: 普通用户
  • 注册时间: 2008-10-15 16:37
文章分类

全部博文(769)

文章存档

2011年(1)

2008年(768)

我的朋友

分类:

2008-10-15 16:42:09

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

    (1)需求定义清晰,没有异议性:

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

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

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

【责编:michael】

--------------------next---------------------

阅读(551) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~