|
但目前很多企业普遍存在的这样一种现象 [5] :项目的客户(使用者)一方面工作很忙,竞争压力很大,认为自己只要将问题提交给开发方,剩下的工作就与我无关了。甚至认为没有必要在项目的建设中与IT人员沟通,或者经常三言两语就把开发人员“打发”了。业务人员的笼统、感性的描述对开发人员就像是“雾里看花”。 IT项目开发人员受项目时间限制及无法取得“真经”就凭自己的理解来开发系统,最终等到系统交付时,一方面客户不满意, 另一方面IT人员一副吃力不讨好的哭相,往往会导致系统难以上线,或上线后使用困难。特别是在一些开发方没有经验的领域,这一矛盾尤为突出。项目经理博客
众所周知,如果需求有误或者需求分析不到位,整个IT项目的控制将变得没有任何意义。有统计表明,IT软件项目中40%~60%的问题都是在需求分析阶段埋下的“祸根”。所以说从某种意义来讲,IT项目的成功基于项目需求管理的成功,而IT项目的需求管理有别于其他项目管理的重要一点是,需求管理可能贯彻整个项目实施的始终。
3 案例分析及解决方案——某中小企业ERP系统开发项目管理者联盟
案例中的中小企业是一家实力雄厚的港资企业,现已发展成为一家专业从事毛织行业的大型公司。由于公司规模不断扩大,业务不断增长,现有管理信息系统不能满足当前各方面需要,因此委托笔者所在开发团队开发一套ERP系统。项目管理论坛
3.1 系统开发实施初期双方沟通存在的问题和困难项目管理者联盟
(1)在沟通过程中,开发方与需求方双方工作范围没有具体明确,急需双方共同确定职责范围。软件开发方、软件需求方双方在项目开展过程中负责什么样的具体工作,不应该负责哪些工作,互相之间没有明确,导致工作责任不明确,出现问题后互相推卸[6] 。项目管理者联盟
(2)软件开发方、软件需求方双方各类人员的职责权利关系需要互相申明。比如是否上下属关系或者其他关系以及相互调遣权限。项目经理博客
(3)存在的突出问题是:软件需求方部分需求不能完整确认。由于软件需求方管理层人员的变动和管理决策的变化而导致项目需求有经常性变化[7] 。软件需求方不同部门的管理不统一,导致软件需求在具体相关部门前期开发调研的内容和后期试用时得到的需求内容有较大差别,甚至产生冲突[8] 。转自项目管理者联盟
(4)软件开发方作为进驻的定制项目,开发方需要软件需求方的大力支持和帮助,所以在遇到困难时迫切需要寻求软件需求方相关人员的帮助,软件开发方、软件需求方双方沟通过程中,软件开发方人员强烈感觉到软件需求方内部人员结构复杂,部门间以及部门和领导间的关系有待理顺。项目管理者联盟
3.2 通常获取需求的方法项目管理者联盟
(1)获取需求的来源:需求主要来自客户、合作伙伴、最终用户以及该领域的专家等几个方面。而通常需要掌握如何准确判断需求应来源于哪方面,谁是最真实的需求者,如何接近这些来源并从中获取信息。项目管理者联盟
(2)获得需求的方式:主要有现场考察、访谈、集体讨论、电话询问、问卷调查或者阅读用户编制的相关文件等。service.mypm.net
(3)常规需求文档:其中每项工作都应该有相应的记录文档。如查阅了大量资料的内容与格式、各种应急防御措施、统计分析报表、系统规划书、旧系统业务状况、历史资料等,而其中在访谈过程中了解到的操作员的应用感受、技术交流与讨论以及其他各种形式的交互式讨论和分析等的记录报告,所有这些最终都需要体现在一份详尽的需求说明书中。项目管理者联盟
3.3 在项目开发中,逐步提出针对以上问题的解决方案项目管理者联盟
(1)本文认为,在初期常规的需求分析阶段,要求需求分析人员必须充分了解用户的目标与工作过程,设身处地替用户考虑问题,帮助用户将模糊的需求清晰化,将简略的需求明细化、完善化,将混乱的需求逻辑化、条理化。因此,本项目采取的比较有效的做法就是从团队中筛选一名经验丰富(包括深厚的业务和技术背景、善于沟通、能吃苦)的队员担任需求工程师,在前期分析阶段驻扎在客户公司,他的工作主要是界定项目的范围和需求变更管理,通过各类规范的模板文档来体现需求内容以及需求变更。其目的就是根据项目目标列表,在初步整理需求初稿的基础上,请业务部门专门进行分析提出修改需求意见,以及在最初阶段最终确认。由于软件需求方和软件开发方的背景不同,对同一问题的理解存在差异,这些差异如果不能在需求的最初阶段尽量弥合,那么必然导致需求增加与需求更改。项目管理者联盟
(2)任何项目都有需求变更与需求增加,这是IT项目中令人很头疼的问题。随着客户对需求可实现度的理解,IT项目客户的需求变更要比其他类型的项目变更多得多。所以,一方面我们必须将这种变更尽早完成在初期常规需求分析阶段,所使用较多的技术手段是模型法,让客户了解可能具有的功能。但另一方面,除了在需求收集阶段需要尽可能将需求细化、在后续阶段在不影响进度的前提下满足用户的变更需求外,还需要在适当的阶段尽量冻结一些不急需的需求,才不至于使项目陷入一种十分纠结的状态。当然,这还涉及后期需求增加的费用以及支付方式和客户达成共识的问题。项目管理者联盟
(3)整个项目下来,感觉到需求分析书不仅仅是初期常规需求阶段的一个成果,它更是整个开发阶段所需要的指南和备忘录。所以仅仅按照传统的需求说明书的固定格式和要求来写,按照常规的使用和管理方法来处理都是远远不够的。特别要提到以下两点:项目管理者联盟
1)需要按照几个要点来完成:需求分类、采用的技术与工具、约定以及技术限制甚至法律法规等全面考虑。需求必须要客户确认,无论在初期需求分析阶段还是在后期需求变更的时候,都需要客户的确认。比如数据字典、界面选型、技术线路、功能模块等,这样做的好处是防止需求把握不得当,缺少了用户必要的功能,同时保障不提供不必要的功能。而且必须要让项目各个环节的相关责任人员进行签字确认。项目管理者联盟
2)值得引起注意的是,需求说明书在整个项目实施阶段并非一成不变的。所以一定需要通过附加文档来跟踪用户新的需求和需求变更,随时跟踪需求。所以类似的文件是要必须考虑的,如《需求(或功能)变更申请书》、《需求(或功能)变更规格书》、《需求清单一览表》等。这样做的好处是对需求实时监控,保证项目的安排和进度变更有据可依,同时让用户知道变更是一件很严肃的事情,同时可以防止个别人提出无法界定的需求。因为很多时候,IT项目中的很多问题可能是其他系统的遗留而又超出本项目技术路线可以弥补范围的问题。同时针对一些暂时解决不了的需求,也一定要用专门的章节罗列出来,这样也利于在做实施计划的时候采取合适的措施来解决,比如采购其他设备、投入相关人力或其他办法等。项目管理者联盟
4、结 论项目管理者联盟
本文通过分析某中小企业ERP系统开发案例的需求管理中存在的问题,总结出如何较好地开展IT项目中的需求管理工作,尝试寻找一种可行的具体办法来解决某些实际问题。认识到需求管理是IT项目开发中存在的主要问题,做好需求管理工作,才能保证IT项目开发的正常进行。同时也深刻地体会到需求管理的优劣与项目的时间、成本有着十分重要的关系。项目管理论坛 项目管理者联盟
|
