【2010-11-18】推荐阅读：浅析IT项目中的需求管理

海的主人

标题：浅析IT项目中的需求管理
来源：http://bbs.doocai.com/thread-19965-1-2.html
摘要：很多情况下, IT项目完全成功的比例较小,而其中需求问题是IT项目开发失败的主要原因之一。如何分析IT项目需求中存在的问题,做好需求管理,是本文讨论的主要内容。本文以笔者亲身实践项目为例,探讨IT项目开发中普遍存在的问题,尝试研究如何利用所获得的信息需求来实施有效需求管理,以提高开发项目的成功率
推荐：阳光

请大家认真阅读，可跟帖写下自己的看法（获取体力）。

浅析IT项目中的需求管理

____________________________________

作者：许菱 吴文雅　来源：阳光收集整理　　

　　[摘 要] 很多情况下, IT项目完全成功的比例较小,而其中需求问题是IT项目开发失败的主要原因之一。如何分析IT项目需求中存在的问题,做好需求管理,是本文讨论的主要内容。本文以笔者亲身实践项目为例,探讨IT项目开发中普遍存在的问题,尝试研究如何利用所获得的信息需求来实施有效需求管理,以提高开发项目的成功率。

　　[关键词] IT项目;需求获取;需求管理

　　伴随着信息时代的到来,我国IT行业得到了飞速的发展。IT项目投资已经位居全国各个行业的前列,但从整体上看,国内IT行业项目管理的水平普遍偏低。据了解,我国IT行业真正实现或者基本实现项目目标的投资项目所占比例很小,彻底失败的占到了不少的部分。究其原因,大多数失败的案例可以主要归结为与没有做好IT项目管理密切相关。

　　1 关于IT项目管理

　　通常给出项目管理的定义是:在一个连续的过程中为达到项目目标,对项目所有方面所进行的规划、组织、监测和控制。而项目管理一般都具有创新性、普遍性、目的性、集成性等特点[1] 。

　　实际上,IT项目管理在现代项目管理中是最重要、也是技术运用最好的一个领域。由于信息技术行业的特点,使得它的项目管理在“知识、技能、方法和工具”等方面远远领先于其他行业。近年来,项目管理的工具也被广泛运用到IT项目管理中,比如常用的有MS Project、Visual SourceSafe等。

　　IT项目的定义是:为解决信息化需求而产生的软件、硬件、网络系统、信息系统、信息服务等一系列与信息技术相关的项目[2] 。而按照PMBOK(项目管理知识体系指南, ProjectManagementBodyofKnowledge)的定义,项目管理则包括以下主要内容:

　　(1)整体管理。主要包括在项目生命周期中协调所有其他项目管理知识领域所涉及的过程。它确保项目所有的组成要素在正确的时间结合在一起,以成功地完成项目。
　　(2)范围管理。范围是指产生项目产品所包括的所有工作及产生这些产品的过程,而项目范围管理是指对项目包括什么和不包括什么的定义与控制过程。转自项目管理者联盟
　　(3)时间管理。项目的时间管理是项目管理的核心。包括活动定义、活动排序、活动历时估计、进度计划的制订以及项目进度的控制。
　　(4)成本管理。包括项目的资源计划、成本估计、成本预算以及成本控制。
　　(5)质量管理。包括项目的质量计划编制、质量保证和质量控制过程。
　　(6)人力资源管理。是指如何通过角色分配、任务指派、团队建设,从而有效地发挥每个参与项目人员作用的过程。
　　(7)沟通管理。是指如何及时而适当地创建、收集、发送、存储和处理项目的信息。
　　(8)风险管理。项目风险管理是指为了最好地达到项目的目标,识别、分配、应对项目生命周期内风险的方法。
　　(9)采购管理。包括如何通过采购、购买或从外部的供方获取产品或服务。

　　IT项目管理在具有以上项目管理普遍特性外,它的行业特性还使它具有自己的特性[2] :

　　(1)抽象性。一般工程项目大多是有形的砂石泥料等的堆砌,实体性很强;而IT项目则是人的智力劳动的凝结,工作成果形象性差。特别是软件开发,生产的是无形的产品,只有程序代码和技术文件,并没有其他的物质结果。对于工程“量”和“质”的考核,难度较大。

　　(2)信息沟通的及时性。现代通信技术和计算机网络的应用在IT项目开发中充当着重要的角色,项目周报、日报以及项目各种信息的正确传递尤显重要。由于行业特色,项目参与人可以实时传送信息,保证了信息沟通的及时性和准确性。

　　(3)不确定性。IT项目的不确定性是指IT项目往往不能完全在规定的时间内、按规定的预算由规定的人员完成。IT项目中各项活动往往受到人为因素的影响,而难以精确预测。IT项目中人员流动性大,这很大程度上影响了开发的进度。人员分工不明确也导致项目存在不确定性,另外,在项目开发过程中还会遇到各种始料未及的“风险”,使得项目不能按原有的计划来运行。以上种种因素直接导致IT项目的计划和预算在项目执行过程中与实际情况往往会有很大偏差。

　　因此,针对以上IT项目中的特殊性,我们认为IT项目管理不同于一般工程项目管理。最显著的差别是,IT项目中还必须从范围管理中特别提出一个需求管理的概念,而且IT项目中的需求管理是做好一切IT项目管理的基础。建立在优秀的需求分析基础上,适合客户需要,真正了解使用者真实需求是一个优秀软件诞生的基础,更是一个IT项目成功完成的最基本保证。

　　2 IT项目中的需求管理及其存在的问题

　　一个完整的IT项目需求管理一般包括业务需求、用户需求、功能需求、非功能性需求和需求分析报告等5个主要内容[3] 。

　　其中业务需求来源于业务发展的需要,它主要针对不同行业的业务特点,有前瞻性地提出行业的业务发展目标,通常在项目定义与范围文档中予以说明;用户需求来源于用户的实际工作的要求,描述用户使用产品必须要完成的任务,应在使用实例或方案脚本中予以说明;功能需求来源于业务部门管理的流程及思路,描述了系统展现给用户的行为和执行的操作等,它包括产品必须遵从的标准、规范和约束,操作界面的具体细节和构造上的限制等;非功能性需求来源于用户的使用习惯及爱好;需求分析报告是在项目IT分析人员结合前述的内容进行汇总、分析及提炼,描述软件系统所应具有的外部行为,在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用[4] 。

　　可见IT项目建设的需求源头来自于系统的使用者,即系统用户,项目建设应按照系统使用者的要求来建设。需要开发方与客户方引起足够的重视,投入足够的人力来完成各阶段的工作,提交满足要求的需求分析报告。

　　但目前很多企业普遍存在的这样一种现象 [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)获得需求的方式:主要有现场考察、访谈、集体讨论、电话询问、问卷调查或者阅读用户编制的相关文件等。

　　(3)常规需求文档:其中每项工作都应该有相应的记录文档。如查阅了大量资料的内容与格式、各种应急防御措施、统计分析报表、系统规划书、旧系统业务状况、历史资料等,而其中在访谈过程中了解到的操作员的应用感受、技术交流与讨论以及其他各种形式的交互式讨论和分析等的记录报告,所有这些最终都需要体现在一份详尽的需求说明书中。

　　3.3 在项目开发中,逐步提出针对以上问题的解决方案

　　(1)本文认为,在初期常规的需求分析阶段,要求需求分析人员必须充分了解用户的目标与工作过程,设身处地替用户考虑问题,帮助用户将模糊的需求清晰化,将简略的需求明细化、完善化,将混乱的需求逻辑化、条理化。因此,本项目采取的比较有效的做法就是从团队中筛选一名经验丰富(包括深厚的业务和技术背景、善于沟通、能吃苦)的队员担任需求工程师,在前期分析阶段驻扎在客户公司,他的工作主要是界定项目的范围和需求变更管理,通过各类规范的模板文档来体现需求内容以及需求变更。其目的就是根据项目目标列表,在初步整理需求初稿的基础上,请业务部门专门进行分析提出修改需求意见,以及在最初阶段最终确认。由于软件需求方和软件开发方的背景不同,对同一问题的理解存在差异,这些差异如果不能在需求的最初阶段尽量弥合,那么必然导致需求增加与需求更改。

　　(2)任何项目都有需求变更与需求增加,这是IT项目中令人很头疼的问题。随着客户对需求可实现度的理解,IT项目客户的需求变更要比其他类型的项目变更多得多。所以,一方面我们必须将这种变更尽早完成在初期常规需求分析阶段,所使用较多的技术手段是模型法,让客户了解可能具有的功能。但另一方面,除了在需求收集阶段需要尽可能将需求细化、在后续阶段在不影响进度的前提下满足用户的变更需求外,还需要在适当的阶段尽量冻结一些不急需的需求,才不至于使项目陷入一种十分纠结的状态。当然,这还涉及后期需求增加的费用以及支付方式和客户达成共识的问题。

　　(3)整个项目下来,感觉到需求分析书不仅仅是初期常规需求阶段的一个成果,它更是整个开发阶段所需要的指南和备忘录。所以仅仅按照传统的需求说明书的固定格式和要求来写,按照常规的使用和管理方法来处理都是远远不够的。特别要提到以下两点:

　　1)需要按照几个要点来完成:需求分类、采用的技术与工具、约定以及技术限制甚至法律法规等全面考虑。需求必须要客户确认,无论在初期需求分析阶段还是在后期需求变更的时候,都需要客户的确认。比如数据字典、界面选型、技术线路、功能模块等,这样做的好处是防止需求把握不得当,缺少了用户必要的功能,同时保障不提供不必要的功能。而且必须要让项目各个环节的相关责任人员进行签字确认。

　　2)值得引起注意的是,需求说明书在整个项目实施阶段并非一成不变的。所以一定需要通过附加文档来跟踪用户新的需求和需求变更,随时跟踪需求。所以类似的文件是要必须考虑的,如《需求(或功能)变更申请书》、《需求(或功能)变更规格书》、《需求清单一览表》等。这样做的好处是对需求实时监控,保证项目的安排和进度变更有据可依,同时让用户知道变更是一件很严肃的事情,同时可以防止个别人提出无法界定的需求。因为很多时候,IT项目中的很多问题可能是其他系统的遗留而又超出本项目技术路线可以弥补范围的问题。同时针对一些暂时解决不了的需求,也一定要用专门的章节罗列出来,这样也利于在做实施计划的时候采取合适的措施来解决,比如采购其他设备、投入相关人力或其他办法等。

　　4、结 论

　　本文通过分析某中小企业ERP系统开发案例的需求管理中存在的问题,总结出如何较好地开展IT项目中的需求管理工作,尝试寻找一种可行的具体办法来解决某些实际问题。认识到需求管理是IT项目开发中存在的主要问题,做好需求管理工作,才能保证IT项目开发的正常进行。同时也深刻地体会到需求管理的优劣与项目的时间、成本有着十分重要的关系。

请大家认真阅读，可跟帖写下自己的看法（获取体力）。

从不知

不错啊! 一个字牛啊!  

facekiss

应该加分  

蜗牛

晕死也不加点分  

facekiss

ding   支持  

titmc

不错哦，顶起  

bestquality

天啊.  

土豆

帮你项项吧  

蜗牛

长时间没来看了 ～～  

ctdsb2011

呵呵,明白了