![]() |
您现在的位置: 新语文 >> 企业管理 >> 运作管理 >> 项目管理 >> 正文 |
|
|||||
探究需求管理的本质 | |||||
作者:佚名 人气:269 全球最全的财富中文资源平台 |
|||||
☆概要 系统优化: 任何设计都应以考虑用户需求为优先,用户需求的满足程度即成为衡量设计优劣的标准。在一个项目设计周期中,开发人员经常会面临选择,以提炼需求,决定开发的优先次序,并在不同的实施方案中作出选择。这些选择必须考虑到收益与付出地平衡比例,这种选择的重要性尤其在建立需求模型的后期凸现出来。基本需求在这时都已明确,而实施方案还未敲定,为了使用户的基本需求得到落实,一定程度的开销用于搭建不同构架的需求模式是合理的。假使我们已经有了一套翔实的需求分析,我们甚至不必将每一套方案都付诸实行,就可以成功地对系统设计进行优化。 面对不同的可行性而需要作出选择时,我们也必须参照收益与付出的比例关系。例如,在被要求提供计划书时(Request for Proposal),我们应当尽量做到每一份计划书的提供都物有所值。 方案设计: 明确需求后,开发人员就可以进行方案设计。通过对用户需求和设计方案之间所存在关联性进行分析比较,我们就能够对设计方案进行评估。 必要的修改: 方案的设计不可能是一成不变的,经常会有方案设计同需求相悖的情况。如果我们无法准确把握用户需求同方案设计之间的关系,我们就无法在需要对方案进行必要修改时正确判断。优秀的需求分析应当非常精确细致地对用户需求作出描述,同时也应该最大程度地给予方案设计者充分发挥的余地。 任务划分: 一个大的开发项目可能涉及20-30组不同的开发队伍,人员包括技术工程师、软件工程师以及具体项目主管等等,而每一个模块都有它自己的开发工具和开发语言。 主持一个大项目的开发并不是件容易的事,总体项目主管的首要任务是对开发项目进行任务划分,将整体开发任务细化为多个子模块,从而使这些子模块能够平行开发而无需太多的干预。总体项目主管可以将细化的不同模块的需求分析交给不同的开发队伍,对于开发进程的监控只需参照需求的解决情况,对于具体的开发细节则不必过问太多。 不同的开发队伍会使用不同的开发语言和开发工具,会使用不同的符号和标记。相反,作为总体项目主管所使用的语言、符号和标记等则必须简单易懂,以使所有的开发人员都等理解。换言之,总体项目主管应当使用自然语言,或只涉及少量的,简单的术语和专用词汇。 产品测试: 需求的满足情况是决定最终产品成败的判定基础,对最终产品的测试评估必须以产品所试图解决的需求为标准。下图标示了不同的开发阶段所对应的测试需求。 这里有一个需求、产品和测试系统之间的关系问题,确定需要进行的测试属于总体开发主管的工作范畴,虽然具体工作并非都要由开发主管来亲自完成。 重复开发: 对于总体开发主管而言,针对方案设计的修改是一项经常性的工作(因为修改而造成的影响则应当尽可能减小)。在进行项目开发时,随着开发进程的深入,各种修改的建议和问题的报告是屡见不鲜的,每解决一个问题,就是将产品同其需求性的结合又完善了一步。存在问题正是需求性尚未满足的表现。 方案设计的完善和需求性的满足是同步的,因此真正的用户对于产品的评价和建议尤其具有重要意义。在那些一步到位的产品设计中,真正用户无法左右开发进程;但在一个能够进行重复设计、重复开发的产品生命期中,开发人员应当及时搜集用户对于产品的反馈信息,并将这些信息结合到下一步的开发工作中去。如下图所示,用户反馈同产品开发是统一的。 项目管理的辅助: 在有些地方,需求管理被作为一个技术问题来处理,需求管理所针对的对象只是产品,而同项目管理所涉及的问题例如进程安排或资源分配等无关。实际上,项目管理涉及三方面问题:进程安排、资源分配和质量管理(同需求的统一)。 试想以下三种情况: ·一场高水准的音乐会,预算合理,演出时间却晚了两天。 ·质量优良的小轿车,交货及时,然而造价是市价的两倍。 ·一套系统,完全满足了用户需求,但在开发过程中使用非法劳工。 这三种情况虽然都满足了用户所需,然而缺乏实际意义,因此都以失败告终。 "我付了钱,但这不是我想要的",没有用户愿意这么说。要避免出现这种情况,在进行项目管理和财务预算时,也必须以需求管理为基础。仅仅完成了一件设计并不意味着工作的结束,只有这件设计充分解决了需求,它才具有里程碑般的意义。同样的,一件产品只有在测试和实际操作中完全满足了需求,已经完全准备好了投入到下一阶段的运营,才意味着这件产品在本阶段工作的结束。 开发进程中的每一块里程碑都意味着需求的解决又前进了一步,这样的每一块里程碑也都是委托商付款的重要参照,产品开发的整个进程都可以通过需求管理进行监控。 里程碑构造机制的基本方法之一就是进程管理,一项需求的满足就意味着一块里程碑的确立。我们应当对用户需求、针对需求而进行的模块设计以及每个子模块的开发进程之间的关联做到心中有数。 通过我们对需求管理实际应用的分析,几个关键因素凸现出来。首先,需求管理在开发周期中是自始至终存在的。注意:不要把它简单理解为"需求周期",需求管理必须始终保持更新,它构成了技术管理的基础。 其次,需求管理同项目管理是密不可分的。如果我们把每一个需求的解决看作一个里程碑,并以此出发对整个开发进程进行监控,我们就应该对整体开发工作进行精密细致的划分,从而将需求分析具体化。 ☆需求管理的概念化阐释 需求管理应当具有以下几个特征:能够在开发周期的初期就建立需求模型;建模的成本很低;易于以后的具体化和优化;本身能体现最终解决方案的特征。也许某些细节是抽象的,但需求管理模型本身必须是完整的。需求模型不应当具有诱导性或倾向性,必须为开发工作留有充分发挥和优化的空间。同时,我们能够通过需求模型对最终产品作出评估。但不幸的是,这些特征本身也不是彼此完全兼容的,很难在一个简单模型中做到面面俱到。 在开发初期针对需求而搭建产品模型(Early Models)是容易的,成本也不会太高,但是这样的模型是很抽象的,绝非等同于最终产品。随后的产品原型(Prototypes)或高级模型 (Qualification Models) 将更接近于最终产品,但搭建这样的模型会要求更高的成本,同时可供修改的余地也更少。 需求管理的多种模式: 需求管理所要搭建的不同模式是由系统工程所采用的标准决定的。传统上需求管理有两种模式:客户模式和系统需求模式。从这两种模式出发的方案应该分别进行设计,不幸的是我们常常将此二者混为一谈。 用户模式着重描述用户面临的问题或希望得到的结果。用户模式的语言组织很象使用场景的实地描述,指明时间,侧重结果。无论谁搭建用户模式,都必须从用户的角度出发。 系统需求模式实际是抽象化的解决方案。系统需求模式的语言组织经常运用功能描述或使用详解性的说明文字,事实上功能描述和使用详解正是系统需求模式语言组织的典型风格。 实际上设计方案应当是第三种模式,即具体化的解决方案。很明显这种模式已经非常接近于最终解决方案。很多不同的设计方案都能解决用户需求,而在用户需求既定的同时对设计方案作出修改也是切实可行的。在硬件系统设计中,最终进行规模生产的产品体现的往往是第四种模式。 其他设计模式: 搭建多种系统设计模式需要付出相当的工作量,因为每种设计都做到条理清晰并不是件容易的事。如果设计构架和最终方案是一致的,那么工作量可能会减少一些。有些设计方案从产品角度出发,认为不同设计模式最好采用相同构架。但在实际应用当中,设计模式必须采用不同构架,这是因为: ·有些设计中同功能无关的需求,放在其他条件下则可能引起变化; ·出于重复利用现存模块的考虑; ·出于对机构效率的考虑; ·不同设计方案涉及的步骤要求,我们并不是都要实现;以上每种因素都会导致设计方案同最初模式不尽相同。设计开发仅仅采用一种模式是很脆弱的。我们必须记住,一套完整的系统开发要求有不同侧重点的多种设计模式与之配合,例如:框架配置模式侧重于大致的工作方向,而工作细化模式则标明了需要完成的各种具体工作。各种模式之间并不是孤立的,在实际需求和各种设计模式之间存在着多种关系。这些关系表现在: ·关联性:不同模式下开发的产品应当具有一致性(系统需求和用户需求)。 ·应用性:非功能需求同功能需求之间的联系。 ·评估测试:需求管理同评测系统之间的联系(以及产品)。 ·设计开发:需求管理同设计模式或产品之间的联系,我们必须清楚每一部分工作同相应需求之间的对应关系。 何谓需求管理 以下段落将通过分析传统需求管理模式的特点,看看传统需求管理模式同"需求管理之需求"是如何发生关联的。 需求管理模型的特点: 顾名思义,需求管理是完整管理模式中的一环,同其他特性诸如一体性(completeness)、一致性(consistency)等不可分割,彼此相关而成一体。一套需求管理应当是已知系统需求的完整体现,每部分解决方案都是对总体需求一定比例的满足(甚至是充分满足),仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能是灾难性的,试想一架飞机的安全设计不过关将会带来什么样的后果。不同的需求组合起来,构成了一套完整的需求模型。用户需求决定了系统设计所要解决的问题,所要带来的结果。可以说,需求管理指明了系统开发所要做和必须做的每一件事,指明了所有设计应该提供的功能和必然受到的制约。 需求的特点: 需求的提出是进行切实可行的系统开发而存在的客观必然。需求性的描述可以是抽象的,也可以是具体的;它针对的可以是产品本身,也可以是产品开发的方式。 需求性的提出是建立在可验证的基础上的,就是说,我们能够根据需求而通过设定某种检验标准对最终产品进行评估,并给出或是或非的唯一回答。在测试中,我们永远不能说产品完全解决了需求,只能说它更加接近于满足需求。 存在的各种关联: 需求管理的一项重要工作就是在整个计划不同项目之间建立联系,这也许是在进行系统工程设计时自然而然得到的一种结果。如果我们对需求模式的阐释正确,并对需求与设计的统一性有了确证,那么我们就有了进行成功开发的坚实基础。在出色的系统设计中,系统各部分所存在的各种联系应当是清晰简明的。系统的相关性、可追溯性保证了从不同侧重点出发的系统设计能取得一致的结果。举例来说: ·系统需求满足于用户需求; ·设计方案满足于系统需求;关联性是客观存在的,对它的描述常被用于展示: ·非功能性需求同功能性需求适用性之间的关系; ·方案设计同需求性的满足关系; ·开发框架内部的关系(例如目标管理、进度安排、任务细分等); ·开发过程中各类信息的存档与交换; ·对每一需求的验证; ·对于核心需求的合理阐释。 需求管理的工具: 需求管理所用到的工具必须能够处理和应用于本文所提到的各种需求,应当有助于我们分析需求,确定相应开发和支持工具以处理相关信息,进而处理系统相应模块。系统工程师始终致力于用简单的工具将需求形象化的展现出来,常用的工具比如附有标注说明的系统发布工具以及相关数据库等。 需求管理涉及到一系列复杂的对象,其任务面向很广,关系到整个设计开发的方方面面。其使用的工具应当提供如图列举的一些功能: ☆总结:需求管理 本文论述围绕于需求管理工程。需求管理是开发工作有效进行的确证。很明显需求管理是一种很高层次的系统行为,涉及整个开发过程和产品本身。 需求管理首先要针对需求做出分析,随后应用于产品并提出方案。需求分析的模型正是产品的原型样本,优秀的需求管理提高了这样的可能性:它使最终产品更接近于解决需求,提高了用户对产品的满意度,从而使产品成为真正优质合格的产品。从这层意义上说,需求管理是产品质量的基础。 |
|||||
财富论今——新的理念 心的飞越 | |||||
| 设为首页 | 劳动创造一切,财富造就神话 | |
财富论今-http://cf.xinyuwen.com 苏ICP备05013302号 |