你的位置:首页 > ASP.net教程

[ASP.net教程]需求背后的需求


  从软件开发的整个流程来讲,需求变更是软件行业,最令人忌惮的问题,一直困扰着我们的研发人员。南辕北辙的道理,每个人都明白。同样,需求变更的代价,会随着项目的进展成倍增长。按行业统计数据,如果在需求阶段只需要花费1个时间单位就能改正的错误,拖到设计阶段来改正需要5倍的时间,到了编码阶段将是10倍,测试阶段可能达到20-50倍,而到了运行或维护阶段或许达到200倍。这就好比盖房子,如果在设计阶段提出变更,只需要修改图纸,如果房子已经完工,却要推倒重来。

  软件公司大部分成本是人力成本,研发周期越长,项目成本越高。需求错误,势必造成研发周期的延长,过长的研发周期正在吞噬企业的利润。而需求变更的根源,在需求捕获上,开始获得的需求如果是错误的,后续再好的设计都无济于事。捕获用户需求不像设计和编码那样纯技术化,不容易建立标准,多少会有一些个人经验主义。有不少企业的需求人员,把客户需求理解成,客户想做成什么样一个产品,果真是这样吗?为什么有些人拿来的需求,很少变更,其他人获得的需求却频繁的变更。我们来看看,很多人认为正确,并且还依然这么做的需求捕获方法:很多需求人员在和客户谈需求时,淡化业务,更多希望客户告诉他要做什么。有些有“经验”的需求人员过早的提供页面设计:“我给你做成这样的吧”,拿出笔和纸开始和客户讨论起页面显示什么内容,最后不忘让用户签字确认。

  希望用户告诉他们要做什么,直接把对系统的呈现方式交给了用户。也有不少客户,因为不懂软件开发行业,所以会把需求理解成,系统做成什么样,直接告诉我们的需求人员,给我实现什么样一个功能。如果用户选择的方案不是最合适的,是拍脑袋想出来的,必将引发后续的需求变更。我见到的很多客户,提出的需求,拍脑袋得来的成分更多。

  需求人员获得的这种需求,向研发传递的往往不是业务,而是某某功能能否实现。需求文档看中不到业务,而是项目背景,功能描述,页面显示栏位等内容。这种带界面的“需求“(实际上不是需求)本身会非常脆弱。后续任何界面的改动都会引起“需求”(实际上不是需求)的变动。同时也剥夺了UI设计人员的机会。到了编码阶段,程序员发现不合理的“需求”(实际上不是需求),提出的改进反而变成了“需求”(实际上不是需求)变更。

  让客户在需求文档上签字确认,公司要求这么做,需求人员也热衷于这么做。客户签字,可以让客户慎重的提出的需求。但是,如果一开始捕获的需求就是错的需求,这种签字是否有约束力呢?签完字,最后改变的需求比比皆是。谁也不愿冒和客户关系闹僵的风险。没有良好的客户关系,项目注定也不会成功。这种签字更多的是为了一种流程(客户不签字,项目不能进行下去,客户没有其他选择)。客户怎能做到,在没有使用软件前,分析清楚系统是否符合业务要求呢。本人从事软件研发N年,自认为项目经验还算丰富,常为一个需求的实现方式,考虑很久。软件行业是公认的,高脑力劳动的行业,专业人士需要考虑很久的事情,让客户来精准的完成,太不现实。所以客户签字不代表需求正确,只要是错误的需求,就会变更。

  其实,许多需求的变化是假的,真正的需求,至始至终一直在那里,根本就没有变。只是开始我们就没有找到,拍脑袋得来假的需求。如果用户使用很长一段时间后,才提出变更,才是真正的需求变更。作为需求人员,应该把注意力放在业务上,业务是相对稳定的。通过对业务的分析,产生出软件系统的需求。如果客户提出,需要实现某个功能。需求人员,可以通过询问客户为什么要做这个?客户工作上的困惑是什么?把客户对功能的实现引导到实际业务,这时候真正的需求或许已经呈现。软件是为了解决问题,用户的目的不同,解决方式也会不同,完全存在有更好更合理的方式解决用户的问题。但不明确真正的问题,谈何解决问题的正确。

  业务分析通行的做法是,建立业务模型(推荐潘加宇老师的《软件方法》这本书)。如果需求人员没有开发背景,也没有需求分析的经验,或者就是商务人员,那就原原本本传递客户的业务,解决方案的最佳人员应该是设计和开发人员。需求分析完成后,由设计人员提供原型,客户来判断这个原型是否符合需求。需求文档中不应去描述页面的操作,而是以业务为中心分析业务,找到系统对业务的支撑点,寻找“需求”背后那个真正的需求。