我们怎样做需求(八)、需求捕获(下)

来源 :我们应当怎样做需求调                                                       作者:fangang  


另一种就是客户压根儿没有想到的需求。也许你会提出这样的疑问,客户压根儿没有想到的需求我们还提出来做什么?这种压根儿没有想到的,实际是在业务需求阶段压根儿没有想到的,并不代表最终都没有想到。很多开发人员总在埋怨,说客户需求总是在软件项目的后期改来改去,为什么?客户并不是软件研发领域的专业人员。在业务需求阶段,由于没有可以展示和操作的实物,客户总是在空对空的凭空想象今后的软件应当做成什么样子。这就注定了客户会有很多自己压根儿没有想到的需求。那么为什么他们会在软件研发的后期提出来呢?因为软件研发的后期,客户能拿到那些研发成果的实物,去操作,可以看到。这时候,很多他们起初没有想到的需求就会源源不断地被提出来。但这时候,我们作为研发人员会很伤,我们付出的代价会很大。所以,以被动的态度去完成需求分析工作,必然会给项目研发带来巨大的风险。

   如何解决这样的问题呢?首先,在需求分析阶段,虽然客户压根儿没有想到,但需求分析人员是软件研发领域的专业人员,他们应当在深入理解业务领域与需求的基础上,通过分析提前发现这些需求。作为需求分析人员,他们应当站在客户的角度去思考,我们的软件应当设计成什么样子,每个需求的真实意图是什么。站在这个基础上,再运用专业知识去整理、分析与设计。我前面谈到,客户描述的最原始的需求是编写在需求列表中的,而经过需求分析人员的整理、分析与设计,经过用例分析、领域建模,最终形成产品需求说明书(或称为产品规格说明书)。从需求列表到产品需求说明书,这之间要经过一段长长的路,这段路就是我们的分析与设计,而不是简单的记录与编写文档。只有经过这样的过程,最后得到的才是高质量的需求分析,才能有效地指导软件研发,避免项目的风险。所以说,好的需求分析人员就是软件项目的司命,掌握着项目的生死。

   我们再换一个角度来分析,客户之所以提不出需求,关键就在于他们没有可以展示和操作的实物,总是在空对空的凭空想象今后的软件应当做成什么样子。我们能否改变这样一种现状呢?于是,迭代式的需求分析与开发就出现了。我们先用最短的时间先做一个可以展示和操作的原型给客户看,让客户提一些意见。然后我们再在这个原型的基础上再多做一些,再给客户看。我们就这样一步一步推进,直到最终项目研发结束。采用这样的方式,最适合那些客户在项目初期提不出什么需求,也没用合适的参照物来进行需求分析的软件项目,特别是那些数据分析与决策类的软件项目。

   接下来,我们再回到那些从客户嘴里说出的需求。在需求分析人员中,比较普遍的一个看法就是,只要是从客户嘴里说出来的,就一定是对的,我们必须照着做的,这种看法是不正确的。因为客户在软件开发方面是非专业的,所以他们在提出需求的时候往往会考虑不够周全。有一次,客户在提出来一系列业务操作以后,最后提出了一个统计报表的功能。这个统计报表是从前面这一系统操作数据中统计出来的,因此我们就对这些业务操作及其结果数据进行了一个详细的分析,最后发现根据这些数据统计出来的数据存在很多的问题,甚至可能出现相互矛盾的地方。随后我们与客户就这些问题进行了深入地探讨,最终客户不得不承认,他当初在设计这个报表的时候考虑不周全。在提出问题的同时,我们又提出了我们的解决方案,这是非常关键的。当我们提出我们的合理化建议以后,客户欣然接受了。同时,客户对我们这种非常专业的分析与处理过程大加赞赏,无形中也提高了我们在客户心目中的威望。

   不仅如此,客户作为一个群体,客户与客户之前对同一问题也可能存在不同的看法,这特别突出地体现在那些多组织机构的管理系统中。因此,对于一些客户非正式的场合提出的需求我们要仔细甄别。一个比较可行的方法就是,先在一些非正式的场合单独跟客户聊,产生第一手资料,最后将这些需求在比较正式的场合,如各部门参加的业务讨论会、有用户代表参加的需求评审会、需求定稿签字确认会等等,以比较正式的形式讨论和确定下来。

   最后,我不得不说,企业信息化管理实质就是一次改革,是企业摒弃手工操作,向信息化建设迈进的一次改革。既然是改革,就必须要改变过去不合理的管理流程,向更加合理和高效的管理流程迈进。因此,我们的需求捕获最初是源于企业现有的操作流程,但当我们深入理解了客户现有的操作流程以后,应当有意识地发现那些不合理的部分,并最终提出更加合理、更适于信息化管理的流程。如果需求人员能上到这样一个高度,我们的需求分析就进入了一个更加崭新的层面(关于需求分析中的流程分析,我们还会在后面详细探讨)。