![]() |
项目管理者联盟 | 中国工程管理网 | 中国研发管理网 | ![]() |
会员中心 | ![]() |
资料库 | ![]() |
论坛 | ![]() |
博客 |
![]() |
|
![]() |
|
|
标题:IT项目需求分析的注意事项
楼主
|
|
![]() 感度 PMB:4760 省份:北京市 行业:综合应用 注册:2006/5/31 |
研究发现,在需求开发阶段发现的一个错误,平均仅需要花30分钟修复,若在系统测试时发现则需要5到17个小时来修复。实践证明,要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个错误要多付出大约100倍的成本。因此,我们不难发现,需求分析在IT项目中具有十分重要的作用。所谓需求分析是指通过对问题域的研究,获得对该领域特性及存在于其中(需要解决)的问题特性的透彻理解并有文档的说明。本文结合作者在实际项目管理工作中的经验,就IT项目中需求分析时应注意的主要问题进行了研究分析。 1、与用户进行充分沟通 通常,与用户沟通前的准备时间要远远大于正式会面沟通的时间。一般情况下,用户在和你连续交谈两个小时之后,就会失去热情和耐心,这是大部分人的共同特点。所以充分的准备工作至关重要。 准备工作包括对项目整体环境熟悉的准备工作和对具体业务进行调研前的准备工作。项目整体环境的熟悉工作需要了解:项目的背景、项目的目的、项目的利益相关方等信息,以便对当前项目的鹰钵情况有一定了解。 对具体业务调研前的准备工作包括:需求调研问题的准备、需求调研模板的设计、需求调研时间安排等内容。要充分珍视用户的时间,尽量避免由于准备工作不足而反复约见用户,给用户造成效率低下的印象。一旦发生这样的错误,以后可能就会很难约见到用户。 2、主动积极了解客户业务和相关知识 在计算机技术方面我们可能非常专业,但对于具体的用户业务可能并不十分清楚。这个项目对用户是否有帮助、某一系统功能是否有用、某一流程处理是否合理,在不了解用户业务的情况下,我们将很难做出判断。 因此只有在了解业务的基础上,我们才和用户有共同的沟通语言和业务理解,才能真正理解系统应具有哪些功能。笔者曾在经销商管理系统调研过程中,由于财务方面的知识有限,使得在对经销商财务部门的调研中对部分问题不是特别的理解。 当时,笔者向用户虚心进行请教,并在调研结束后及时对自己的财务知识进行了补充。应用领域的知识是无边无际的,在各种项目的调研过程中,肯定会出现由于需求分析者缺乏某一领域的知识而影响需求分析工作的准确、顺利进行。遇到此类问题时,需求分析者应虚心向用户请教,同时应及时补充应用领域的知识。最好能够在调研前做好充分的准备。 3、引导用户,使用户充分表达自己的想法 在与用户交谈中,如何引导用户说出他们的需求是非常关键的。恰当的提问,会使用户滔滔不绝,充分发表自己的意见和建议。而不恰当的提问,可能会导致用户无法回答或敷衍了事地进行回答。提问可分为封闭式提问和开放式提问。 封闭式提问目的明确。如:现在你们的送货单是手工填写还是电脑打印?但过多使用封闭式提问,会导致谈话枯燥,让用户感觉自己好像在接受审问。开放式提问是请对方对某一事物做进一步的解释,可使谈话达到一定的深度和广度。 如:你认为目前的工作中存在哪些可以改进的地方?开放式提问缺点是容易使谈话内容偏离主题。因此在谈话过程中,应采用封闭式和开放式提问相结合的方式。以简单问题开始、从用户熟悉的内容开始。每次只提一个问题、集中一个重点,宁问勿猜。并尽量避免使用IT相关的一些术语,以便用户能够很好地理解我们的表达。 4、对用户进行正确分类 组织中的用户在很多方面存在差异,例如:使用系统的频度和程度、计算机系统知识、所进行的业 务过程以及个人的素质和喜好等。根据用户的特点,可对用户进行一定的分类。将用户分类并归纳各自特点,详细描述他们的个性特点及任务状况,将有助于需求的获取和分析。 不同的问题需要询问不同的人,对于操作细节的问题,要和实际负责操作的用户进行沟通,而对于关乎全局的问题,则要和相应的管理层用户进行沟通。如通过组织架构图得知仓库部门有三种角色:仓库主管、发货理货员、系统操作员。 我们发现仓库主管是对全盘业务相当熟悉的人,他负责协调本部门的全局事务;而发货理货员是部门的主要业务执行人;系统操作员则是仓库管理系统的直接操作者。若我们调研的目的是搞清该部门的整体性流程,我们会很自然地选择仓库主管作为访谈的对象。 5、应实地了解用户工作流程 实地观察用户执行业务任务的过程。了解用户什么时候获得什么数据,并怎样使用这些数据,业务处理过程中需要处理哪些单据,需要和哪些角色的用户发生关联等。这都将有助于明确产品的功能需求。 经验证明,与人们面谈关于他们如何完成任务时会有许多限制和不准确性,而这是任务观察可以直接解决的。特别是对于某些组织中普遍接受的规则和方法,用户认为你也应理所当然知道,而不曾提起时。 近年来,由于人机交互的复杂性惊人地增加,人机交互的观察和记录已引起人们的广泛注意。观察是一个主观的领域,很大程度上依赖于需求分析者的经验。在经销商管理系统的需求分析中,通过观察发现:某些客户要求送货单中的商品价格为含税价格,而有些客户则要求送货单上的商品价格为不含税价格;有些商品的税率为13%,而有的商品税率为17%; 有些客户要求送货单上的金额小数点后保留四位,有的客户又要求送货单上必须提供自己公司的商品编码等。而这些都是在调研中,用户不曾提起的内容。 6、分析需求可行性 柳传志曾说:“没钱赚的事我们不干;有钱赚但投不起钱的事不干;有钱赚也投得起钱但没有可靠的人选,这样的事也不干。” 柳传志为联想集团的决策确立了上述准则,同时也为可以行性分析指明了重点。可行性分析主要是针对某一需求决定是做还是不做。一般可行性主要考虑两个方面的因素:技术和人。技术方面主要是分析在给定的时间段内是否可实现所需的功能并满足产品的质量要求等相关指标。 很多时候,用户的想法在实际实施过程中是不现实的。若一味地求全和盲目遵从用户的设想,将为项目的后续工作带来很大的风险。因此应尽量避免在需求分析中包含技术实施上有难度的功能。如在笔者曾经负责的一个项目中,用户要求新的管理系统应实现和用友、金蝶等管理系统的数据接口,以方便这些系统中的数据导人新的管理系统。 许诺提供与用友、金蝶等系统的数据接口,将为新系统的成功实施带来很大的风险。因为熟悉这些系统需要时间,开发与它们的接口也需要时间,而且用友、金蝶等这些系统存在多个不同的版本。因此与外部系统接口的可行性定义为:不可行。 人的方面主要考虑目标用户是否具有相应的素质和能力。在实际项目中,笔者曾对快速消费品行业经销商批次管理的可行性进行了分析。首先,批次管理将涉及到所有产品的出入库操作,并存在一个产品有多个批次的情况,因此批次管理对操作人员的能力和素质要求比较高。 其次,快速消费品行业的特点决定了产品的出入库操作极为频繁,因此,操作人员的工作强度比较大。再次,大部分经销商的仓库所在地都距离城镇比较远,因此工作人员的文化水平普遍不高。在 综合考虑后,将批次管理的可行性定义为低。 对于复杂的项目,还应从经济方面和环境方面进行考虑。经济方面主要从投入、收益、短期、长远利益等方面进行分析。环境方面主要考虑市场环境和政策因素。 |
回复 | 引用 发表时间:2014/11/10 16:49:18 |
! 您尚未登录,不能回复主题。 现在 登录 注册 |
|