实施中—需求分析阶段的总结

标签:沟通技术模式

访客:36593  发表于:2013-09-03 12:48:43

 

需求分析是项目开发的基础,基础打的牢不牢直接关系到后面所有的工作,是项目实施成败的关键

总体上说,我们的需求分析是做了,但是做得很不够,我们做的需求只解决了我们能做出这样的项目,但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况:

i. 客户本身说不清楚

我们的能力、我们能否真正站在客户角度去搜集和整理这些需求,就决定了这个需求的完整性和有效性。

ii. 需求自身经常变动

随着客户对这个项目越来越深刻的理解,那么可能他的需求也会随之改变,这些变化的可能性越大项目风险就会越大,我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求,哪些可能会是产生变动的需求,考虑到他的可变性,这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。

iii. 分析人员或客户理解有误

毕竟,不是每个分析人员都是专业而合格的,为避免这种情况的发生,需求分析必须要有审核制度,公司自己内部要审核一遍,客户再审一遍,提出意见,修改后双方共同评审签字,确认。

由此出现的问题:

a) 需求分析过于笼统,只关注到面上,没有关注到点上,开发出来的东西在具体的细节上和客户的理解有误差,并且无法严格界定是否属于需求变更。

b) 需求报告只求我们这方评审通过,不去关心客户的评审,认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任,但是不能保证使项目实施成功。

c) 需求分析中含有技术实施上有难度的功能,一味的求全和盲目按照客户的设想,受客户影响过大,毕竟,很多时候,客户的想法在实际实施过程中是不现实的,或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能,后台大批量邮件群发功能。

d) 对双方已经确定的需求,实现以后并不适合客户使用,需要按照变更手续执行的时候,客户可能会纠缠,提出你们是专业人士,你们应该事先能提醒我们可能会出现这种问题并以此来把责任推给我们,而我们又不好完全按照变更手续执行,因为可能激化双方的矛盾.

 e) 项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的,在成本有上限的前提下,项目的功能设计(软件的成熟度)方面必然受一定影响,毕竟功能越多越完善,相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。

f) 此项工作的反复造成思想上的倦怠,使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作,需要和客户之间不断的商讨、确认和反复。做为顾问,如专职做一个项目时,要全力投入,不要在关键需求阶段再投入其它项目中(特别是一个项目只有一个顾问时),这样给客户不好的印象,认为我方人员不专业,没有认真对待项目。

总结:

a)   前期和关键客户沟通,了解业务模式很重要,不要一开始就投入到具体的调查问卷过程中。

b)   调查问卷要全面有针对性,内部对于各个产品都应该形成一套规范的调研模板,顾问去现场时不需要花太多时间搜集调研问卷 ,节省时间和资源。

c)   交付客户的需求确认文档,在我司内部应该有一个审核制度。在内部通过后,再交付给客户审核,这样保证文档的质量。比如说实施顾问写好的文档,要交给做这个项目的售前顾问评审通过才行。

d)   交付的需求文档应该有一个统一的标准格式。而现实是我们顾问写出来的文档,客户在框架结构上有议异,最终按客户要求调来调去,耗时不少。我们内部有无一个统一的标准,跟客户达成一致,对外按我司统一的标准来操作,这样受客户影响会小些,使文档验收标准有章可循。

e)   实施人天没有考虑双方评审的时间。造成实施人天的透支。合同中如顾问只有5人天的文档编写时间。没有预留出双方需求评审的时间,实事上,最终因客户不满意我们的需求文档质量,双方调整文档结构和细节确认上耗时不少时间(有可能讨论几轮下来),内部和开发测试反复交流后,对需求文档细节的修改。这二方面的沟通的时间算下来,这个就是实施人天的增加,而往往无法确定最终会耗多少人天,客户不签收,反复很多次,造成实施人天的增加。

f)   实施时,在一开始时就需在引导客户,尽量放弃不实用的,工作量又特别大的功能。不要给客户过多的时间期待,时间一长,再打消客户的期望时变得沟通成本增加。(1)对产品改进无好处。(2)客户成本增加。


 

评论(1)

您可以在评论框内@您的好友一起参与讨论!

    1. 张嘉奕 感谢您的分享,文章已推送至e行网“热点精华”页面

      回复[0] 2013/09/04 14:38

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");