需求分析是整个软件工程的基石,对于一般的信息系统来说不但是贯穿于整个项目的始终,而且也是贯穿于系统涉及所有人员的一条主线。客户需求,要深刻理解客户需求,由资深实施工程师或者专门的需求分析师与客户沟通交流、汇总整理,然后以用户需求规格说明书的形式传递给开发经理,或者有的项目前期就有开发经理的参与,开发经理经过分析处理形成软件需求规格说明书再细分到开发部,不同的人各自负责一部分,最后会落实到代码上。形成适合客户应用的,满足客户需求的应用软件。经过软件发布、部署、上线、稳定运行、验收交付等一系列过程,走完软件项目的生命周期。这是一般开发意义上的理想化需求分析及软件流程。
一般信息系统的需求分析是以业务内容和业务流程为驱动的,比如我们现在所做的典型客户,他们的组织结构,人员规模,每个岗位每日业务流程、每个岗位每日每周每月每季每年的异常处理业务流程,每个岗位每日每周每月季每年的输入表格,每个岗位每日每周每月季每年的常用数据查询,每个岗位每日每周每月季每年的统计报表针对以上的了解,客户面对未来挑战和机遇,未来应该如何变更他们的岗位和职责和流程,尽量流程少,效率高,运转快?这是需求分析的总体思想,具体的业务内容更是要以客户实际的业务流程为依据,抽象出概念模型,形成系统蓝图,最终实现软件信息系统。
但BI项目的需求分析似乎更具有其特殊性,BI项目是以业务数据为基础,以深层次的业务需要为驱动,最终结果都是以展现分析为主,比如以什么样的数据为依托,要分析什么指标,分析的程度有多深,用什么样的方式展现,对展现的结果如何钻取到明细?这一系列的问题是BI项目的需求分析更为关注的。比如一般的财务或者财政系统BI系统,按照收支两条线整合数据对各项指标进行分析,首先、收入这条线整合收入的各个数据源,如果涉及到预测那么还需要整合预算收入数据;同样、支出这条线整合支出的各类数据源,对支出的预警分析也会整合到预算支出的数据。
以上所说的只是一些理论化的东西,而且BI项目的需求调研与分析都会是资深的实施顾问或者精通业务的内部外部专家来完成的。
可是对一些刚毕业一两年的初级实施工程师来说,BI的需求意味着什么呢?这些初级工程师对需求能做些什么呢?或者已有系统的需求对初级工程师有什么影响呢?这个话题不容易说明,我举一个自己亲身经历的例子。我第一次接触BI项目,是一个财政相关的,我上班的第一天就听到项目经理说:这段时间的主要任务是核对数据,大家要认真对待。接下来两三周的时间都是核对数据,具体工作是:BI系统中展现的同一个指标数据与业务系统中展现的数据不一样,或者与手工汇总的数据不一致。这就需要一个单位一个单位的按照指标顺序人工核对一遍,不一致的指标数据首先要报告现场负责人,负责人先查找系统的取数条件,确保正确无误后再查看运算勾稽关系,最后查看业务系统的业务逻辑最后断定是哪里的原因导致数据不正确。因为涉及到的单位有几十个,每个单位指标过百个,加上汇总指标也是一百多个,这样没完没有了的核对两个多周,而且加班也是经常有的事儿。当时心想:忙活了一阵子不知道自己在干什么呢,再说这些工作连一个初中不毕业的学生都能做,内心极为厌倦。
这就引出了一个新的问题,新进入项目员工的培训问题。前期的需求分析没有形成固定的需求分析说明书,或者项目中有这样的需求文档,但是由于项目紧任务重没有时间对新进入的员工进行系统的培训,导致新进入的员工对整个项目的BI系统没有一个概念,脑海中没有一个轮廓。工作了很久但是一直不知道自己在做什么,这样的情况对一个BI项目来说并不奇怪。当然后来也挺不少同事说起过这样的经历,在BI项目中忙碌了很久但不知道自己在做什么,不知道自己的工作有什么价值。
总结一下:新进入项目组员工的培训问题,根据一般的经验基本有集中培训和项目过程培训,但是大部分中小型公司都没有对员工进行集中培训。员工都是在项目过程中自己学习的积累的。通过自己的体会和别人的经验可以得出,不管采用什么样的培训方式,对于新进入BI项目的人员来说从需求开始整体培训是非常必要的。
说完了BI项目的需求对新进入人员的作用,那么在项目过程中实施工程师如何对新的需求进行控制也是一个更大的问题。由于BI系统的客户对象一般会涉及到业务统计人员、部门主管和单位领导等三个层级,不同的人员站到不同的立场对系统的需求也有不同的层次,一般的统计业务人员会认为BI系统是个大大的数据加工工厂,于是什么样的报表、什么样样的统计指标都想从系统中得到,于是新的需求便层出不穷。因此需求变更也是防不胜防。再者还有就是客户的需求总是理想化的,要求怎样做实现什么样的效果,有些时候对产品不熟悉或者对软件设计不了解的话,现场实施工程师根本不知道新的需求要做成什么样子。在一个方面就是,实施工程师在业务客户面前是个弱势群体,即使有不同的意见或者针对客户绝对理想化的需求也无法回绝。如此一来会造成设计出来的程序总达不到客户的满意效果。
最后学会了这样的技巧:
客户业务部门不能随便提需求。必须集中汇总到客户IT部门,由客户IT部门汇总过滤完,再集中报给软件公司客户IT部门的需求,必须客户方负责IT项目的老板签字才能生效,才能报给软件公司不能随时报,每3个月集中报一次不能口头报(即使在现场实施支持也不行),不能电话报,只能MAIL或传真来报必须按我们规定的格式报,要严格写清楚需要实现的功能的界面,输入数据或输出数据,输入输出数据的格式要求,谁操作,多长时间操作一次。
软件上线后只能免费修改3次。以后再有需求,就必须另签合同另收费,否则不予修改。
经过这么几招,客户也疲了。需求是不提了。但我们真的做好了么?难道客户真的满意了么?客户为什么要用我们的软件?难道仅仅是为了把他们现在手工做的,然后转到计算机去做。让计算机的查询统计计算速度代替人工?
客户为什么要提这样的需求?客户要根本解决什么问题?这些问题谁来想,谁来想解决办法?
这些问题是我想不通的,我只能归结到我们不懂业务这个大方向,但是懂了业务以后应该怎么做具体的操作,希望有经验的前辈多多分享一下自己的经验和方法。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞19
添加新评论18 条评论
2011-03-23 16:02
2010-12-10 20:24
2010-12-06 10:28
再者就是客户的需求频繁的变化,虽然说需求有变化很正常,但是频繁的变化从侧面也说明了两个问题:一个是客户自己想要什么东西还很模糊;另外一个就是我们做的东西客户不满意。
如何才能解决这样的现状,我觉得需要双方的沟通,互相理解,技术人员要了解业务,了解需求,而业务人员也要懂一些技术,这样两者才能有共同语言,才会产生共通点,才能做出双方都满意的东西。
2010-12-02 15:30
2010-12-01 19:14
2010-11-21 16:35
2010-07-29 16:41
~~~~同感~~
2010-07-29 10:07
2010-07-26 13:24
2010-07-26 11:36
2010-07-23 16:05
2010-07-20 14:28
2010-07-17 00:23
2010-07-15 14:36
当时迫切的感觉就是一定要懂业务!
2010-07-15 13:55
2010-07-15 13:47
2010-07-15 01:01
另外,在不同的阶段,不同客户也要区别对待,如果在BI实施阶段,客户对系统的认知/认可程度不高,可以在短时间内快速建立一套他们可以应用的平台,以后在进行改进,提高,不能因为谨慎而让客户长期等待。
客户的脾气也是培养出来的,所以UAT ,sign-off应该是必要的,有时候客户自己也不一定知道自己想要什么。朝令夕改,落在纸头上的协议比较好。
2010-07-14 10:34