项目的开始起于需求,有的客户是希望自己的管理思想融入软件系统中而产生的需求,有的客户是借助于软件先进的管理思想来提高自己的管理水平,也有的客户仅仅是想解决工作中的实际问题而借助于信息化的工具,还有的客户是因为软件厂商做了扎实的关系,做通的了客户高层领导的工作被迫产生的需求。不论如何,我们面对各种虚的,实的,主动的,被迫的需求,最终交付给用户的系统必须是实实在在能运行的,并且让用户真正使用起来的系统,只有这样,我们的项目才具备验收的先决条件,才谈的上回款。
刚进入it这行,接触第一个项目的时候,就被告知需求的重要性与掌控需求的难度。一个项目,在客户环境比较好的情况下,能获取80%的需求,而这80%的需求在设计,编码的过程中能实现其80%已是相当不错的结果,折算下来,我们的软件系统与客户的需求达到70%的吻合度已是相当不易,那么如何才能获取这80%的需求呢,让项目从开始就不要偏离目标太远。这个我承认不太容易。其原因我总结了有如下几点:
1、参与需求调研的双方在业务技能与软件技能上不处在同一层面。客户从业务层面上去描述自己的需求,也许仅仅只是一个表象。我们的识别的能力有限,导致系统开发后产生巨多的变更。另外,我们更多的是从技术的层面去评估客户的需求能否实现,这就往往让客户无法理解由于技术实现上的难度而对某些需求的拒绝。
我记得我参与的第一个大项目,由于没有业务经验的积累,在加上时间紧张,来不及了解客户行业的知识,就到现场开展需求调研。结果,客户满怀热情的张我们描述他的构想,我们却云里雾的听了半天连几个专业术语都没弄清楚。再接下来,客户开始有了敷衍我们的意思了,言语间也透露着不信任,不愿意花费时间在需求调研上,只要我们按照他的想法先做,做完后在讨论。至于是什么想法,我们了解的很模糊,无奈之下做出来的东西可想而知。幸亏公司的客户关系做的不错,才有了我们后期修正的机会。否则,这个项目一开始就奔着失败的路上去了。
2、国内的信息化处于比较浮躁的状态,导致需求调研时间短,获取的需求信息不充分。一个单子接到手后,合同规约定的时间只有两三个月,包括需求,设计,编码,实施的项目全过程。国内的行业应用软件厂商大都会把时间花在后面的编码与现场实施中,留给需求与设计的时间反而很短,有的甚至将这两个阶段合并。在这一点上,国外的软件厂商恰恰与我们相反,我有部分的同学和以前的同事在外包公司做事,多少了解一些国外厂商的做法,他们可以为了需求调研把自己完全的融入到客户的环境中,跟着客户上班,观察客户的工作方式和工作流程,同时又能站在信息化的角度上去分析和挖掘客户需求。而这个过程很可能会占到整个项目周期40%的时间。再回头看看我们所面临的现状:周期短,时间紧,项目金额小。1—2个人员到现场,花1个星期时间,每天工作2—3个小时,收集用户的表单,了解一下工作流程,做得好的还会拿出曾经在别的厂家实施成功得系统让客户参照着提出自己的需求。接着进入实际开发阶段。等到系统开发完毕后,到现场那么一演示,发现不是那么回事儿。原来看似简单的表单涉及到复杂的公式或是接口取值。看似简单的工作流程却涉及到异常情况下的分支处理,看似普通的增删查改的操作背后有着特殊的权限要求,一切的一切都和原来的不一样了。实际上,事实还是事实,只不过是和我们原来的想法〔预估〕不一样了。这就是我们面临的现状。这不是我们想要的结果,但大的环境如此,我们无法改变只能去适应,在适应的过程中寻求改进。
3、客户不太配合导致需求调研无法顺利的开展。我相信只要做行业应用系统的朋友都遇到过通过上层关系强压下来的项目。客户中层和基层的关系没有做,再加上项目本身的建设方案写得比较虚,需求调研人员硬着头皮来到现场。找到业务相关部门,客户对咱们不待见,爱理不理的。调研人员又找不到需求的切入点,提的问题要么太封闭,让客户只能回答是或否,要么就问的过于开放,让用户感觉不知从何说起。双方往往沟通不到十分钟,都觉得没话说,冷了场。更有客户直接借口工作忙间接下了逐客令的,还有的就是甩给咱们一堆报表的,让咱们研究研究先,弄得调研人员只有干着急的份儿。公司领导还以为自己上层关系都做通了,下面就是照章办事,根本无法理解下面的重重阻力,更别谈派个销售人员到现场来把实际用户的关系打通〔客户不等同与用户〕。项目做糟了,领导把责任全摊到开发头上,压力山大啊!
这同样是现状,也不是我们能改变的。试想一下,这样的单子能不接么,它也是公司生存、发展的一部分呀。再说,换做咱是老板,上层关系付出代价打通后,单子都签回来了,还愿意继续投钱做下面的关系么,那可是成本呀,况且合同的金额本身就不大。我面临的情况有不少就是这样,去扭转老板的想法放弃这类单子或继续投入资源搞定客户中下层,那不现实。逼着客户配合我们做需求调研,这也超出我的能力范围。事情就这样陷入了僵局。
4、前面谈到3个难以获取需求的原因会导致我们偏离项目目标。那么第4点,我认为过于泛滥的需求同样也会让我们迷失方向,达到了项目建设目变却离项目的盈利目标相去甚远。
我曾经遇到的一个项目,没有走任何的客户关系,完全凭自身产品的特点和价格的优势,半路入围、一举中标。之后紧接着进入需求调研阶段〔虽然是产品,但还是要客户化定制〕。调研人员一到现场,客户表现非常积极,工作也相当配合。不料想到后来,需求向潮水般的涌来,挡都没法挡。本来我们的产品是一套成熟的产品,针对每个客户仅需少量的修改就可上线投运。原计划两天的需求调研延长到5天,1人月的开发延长到3人月,1个人月的现场实施也拖成了2人月。项目成本翻倍,进度延后1倍。最后项目利润核算下来比预计少了3/5,士气遭受严重打击。这件事给我很深刻的教训。如果我们自身积累丰富的行业经验,手上有成熟的产品、成功的案例,在需求调研的过程中,如何引导客户的需求,控制需求的边界在合同的范围内,甚至是在现有产品功能的范围内,这个问题同样需要寻求解决的办法。
715

被折叠的 条评论
为什么被折叠?



