以软件需求确认书为例,浅谈项目管理之需求管理实践

发表于:2021-2-23 09:11  作者:佚名   来源:CSDN

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 需求管理 软件测试管理

  什么是项目需求管理呢?需求管理有哪些方法和成果?需求管理为何会在项目管理中有着如此重要的意义?实际项目管理实践中,需求管理有哪些难点,该如何避免呢?我们接下来将一一叙述,与大家做个简单的分享。
  项目需求管理
  需求管理官方的定义:需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法,可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性,以及与其他需求和其他项目工作之间的可追踪性。
  项目需求管理,从字面意思来理解,就是项目中的用户需求、业务需求和项目需求的管理,包含了需求本身和需求的范围。
  任何一个项目,都有着较为明确的项目范围,而这个项目中的任何需求都必须在项目范围内,否则就是项目范围外的需求,而这种现象就是“项目范围蔓延”。这里就属于项目管理中的项目范围管理,本文不做深入的叙述,针对项目范围和项目需求做一个简单的对比。
  需求管理不是范围管理,这一点,大家应该能够有比较一致的认识。
  需求管理和范围管理之间的区别从它们的定义、工作内容和在项目中所承担的职责就可以知道:
  项目的范围一般是执行项目商务合同和技术需求确认书上所规定的。范围管理是项目管理中项目内容、规划等一系列子过程的统称,是为了确保项目能够在确定的范围、确定的内容、确定的时间、确定的标准、确定的质量要求等一系列的约束下圆满完工交付的保障。项目范围管理是包含且只包含达到项目成功所必须完成的工作,范围管理主要关注项目内容的定义和控制,即包括什么,不包括什么。
  而需求管理是在项目范围规定之内确保项目关联各方对具体项目实现、业务需求、管理需求等需求的一致理解,管理和控制需求的变更,以及需求的跟踪。
  所以需求开发和管理的目的是通过调查与分析,获取用户需求并定义产品需求,还要确保项目关联各方对需求的一致理解,管理和控制需求变更,需求的双向跟踪。
  而项目范围管理的目的是确保项目包含且仅仅只包含项目所必须完成的工作。
  需求管理是对已批准的项目需求进行全生命周期的管理,过程包括需求管理定义、需求管理流程、制订需求管理计划、管理需求和实施建议等,其主要的工作就是需求调研、需求分析以及需求的变更管理和需求实现的跟踪。
  范围管理过程包括范围计划编制、范围定义、创建工作分解结构、范围确认和范围控制。
  需求管理和范围管理之间的联系:首先通过需求开发来获取项目的需求,再次基础上确定项目的范围、进行项目范围管理,其次需求的变更会引起项目范围的变更,这是一个辩证循环的过程。
  需求管理的方法
  需求管理的主要内容包含需求的确定、需求的控制、需求的跟踪。
  1.需求的确定
  项目需求的确定,是为了解决客户实际的生产管理问题,就问题本身和解决问题的思路、具体实现形式和逻辑与客户达成理解一致的情况,就是单个需求的确认。
  在大多数实际的项目中,项目的客户分为计算机专业技术的客户和实际业务使用的业务客户两个群体,他们在项目中所承担的职责和诉求有着非常大的差距,在确定需求的时候一定要区分对待,避免需求冲突,在这个过程中项目管理者和执行者要起到协调、沟通的纽带作用,促成对需求的理解达成一致。
  那么在需求确定阶段,主要的工作内容是收集需求、分析需求、确认需求。
  那么,有哪些方式和手段可以来帮助我们完成这些工作呢?
  · 面对面访谈:需求调研员和分析师通过与客户面对面的沟通,就项目范围内的项目内容逐一的进行需求沟通和确认,完成需求的收集和确认工作;这种方式适用于具体需求的沟通和确认,或者是甲方领导及业务负责人等人员的需求收集。
  · 需求调研表:需求调研员和分析师通过对行业和客户的理解,制作好具有较强针对性的客户需求调研表发放到客户所有可能是项目使用者的手中进行需求收集的一种手段;这种方式适用于项目前期的需求收集。
  · 需求调研会:通过组织会议的方式,对项目中的建设内容与客户进行需求沟通和收集的一种方式;这种方式需要需求调研员和分析师在对该项目有一定的了解的情况下进行,因为客户人员组成复杂,非充分准备的情况下容易影响在客户这里的形象和专业水平。
  · 参与式观察:通过带有明确的目的深入参与客户的日常实际生产管理流程,去体验客户所提出的问题和判断解决方法的可行性。
  在完成了需求的收集、整理、确认之后,我们要做的就是需求的分析,需求分析是一个相对专业性强一些的工作,需要对行业的发展、应用、技术有一定的积累,同时能够运用专业的需求分析工具让需求形象化、具体化,变得更容易理解和达成一致。
  在做需求分析的时候,一定要对需求和问题的关系有深刻的认识。问题只是需求的表现,并不是真正的需求本身,问题分析聚焦是需求分析必不可少的步骤。
  那么需求分析需要怎么做呢?
  · 绘制需求关联图:用于定义系统与系统外部实体间的界限和接口的简单模型,同时也明确通过接口的信息流。
  · 分析可行性:在允许的成本、性能要求下,分析每项需求实施的可行性,明确与每项需求实现相联系的风险。
  · 确定需求优先级:应用分析方法确定使用实例、产品特性和单项需求实现的优先级。
  · 建立需求模型:图形分析模型是对软件需求规格说明的极好的补充说明。
  · 编写需求说明文档(PRD):软件需求文档包括用户需求和详细的系统需求描述,是对软件系统要求的正式陈述。软件需求必须具有综合性,谨慎变更。
  在完成了需求的分析后,我们需要组织项目干系人(包含但不限于建设单位、承建单位、监理单位、供应商等)进行需求确认。
  需求确认分析需求规格说明的正确性和可行性,检验需求能否反映客户的意愿。需求确认关心的是需求文档,而需求分析关心的是不完整的需求。
  在构造设计开始之前,通过需求确认基于需求的测试计划和原型测试来验证需求的正确性及其质量,能大大减少项目后期的返工现象。
  需求确认的目标:
  · 审查需求文档;
  · 依据需求编写测试用例
  · 编写用户手册;
  · 确定合格的标准。
  需求确认的内容:
  有效性确认:对于每项需求,首先必须证明它是正确有效的,确实能解决用户面对的问题。
  一致性确认:在需求文档中,需求不应该冲突,即对同一系统功能不应出现不同的描述或相互矛盾的约束。当两条需求不能同时满足时,则定义二者是不一致的。采用形式化的需求规格说明可以用软件工具验证需求的一致性。
  完整性确认:需求文档应包括所有系统用户想要的功能和约束。如果所有可能的状态、状态变化、转入、产品和约束都在需求中作了描述,则说明这个需求集合是完备的。需求的完备性必须由用户来检验,可以通过原型系统来实现。
  可行性确认:需求文档应包括所有系统用户想要的功能和约束。如果所有可能的状态、状态变化、转入、产品和约束都在需求中作了描述,则说明这个需求集合是完备的。需求的完备性必须由用户来检验,可以通过原型系统来实现。
  可检验性确认:指描述的需求能够实际测试。为减少在客户和开发商之间可能的争议,描述的系统需求应该总是可以检验的。这意味着能设计出一组检查方法来验证交付的系统是否满足需求。
  可跟踪性确认:指需求的出处被清晰的记录,每一系统功能都能被跟踪到要求它的需求集合,每一项需求都能追溯到特定用户的要求,它能为评估需求变更对系统其他部分的影响提供帮助。
  可调节性确认:指需求变更能够不对系统的其他部分带来大规模的影响。
  项目需求管理的意义
  信息化项目中需求管理对于项目的成败和盈利能力有着决定性的作用。
  项目需求管理是协调解决客户实际的生产管理问题和对应的信息化解决方案的一个过程,针对任何一个项目建立规范化的项目需求管理体系是确保项目需求的最佳方式。
  · 项目需求管理能够控制项目的范围;
  · 项目需求管理能够控制项目需求的变更;
  · 项目需求管理能够更加清晰的明确项目管理中的里程碑节点和标准;
  · 项目需求管理能够更加深入的挖掘客户的深层次管理、业务、生产需求;
  · 项目需求管理能够最少可能的产生项目设计开发过程中的需求变更;
  · 需求管理能够尽可能的减少项目的不确定性因素;
  · 项目需求管理能够为项目的设计开发协调市场需求和开发计划;
  项目需求管理的常见问题
  1.客户需求来源零散且不全面
  需求的收集和分析需要具有较强的逻辑思维能力和对行业应用有较为深刻的理解。而大多数我们在做需求收集的时候,所面对的用户在整个项目中所处的角色关系复杂,涉及到业务、管理、技术和习惯等等原因,在大多时候,用户并不能准确的描述问题所在,而仅仅是描述一个现象或单点的诉求,并不能全面的反映整个问题所在,导致需求不准确、不全面。
  2.需求沟通不彻底
  在实际的项目实践当中,需求沟通不彻底是非常常见的,需求调研、分析人员没能够深入的了解客户的生产管理问题,未能挖掘深层次的诉求,导致需求不准确、不能完整甚至是需求理解偏差。
  3.需求分析不成体系,没有针对性
  需求收集整理完成后会进行需求的汇总、梳理、分析,这是一个庞大而专业的工作,面对海量、繁杂、专业的用户需求,需要专业的行业应用领域的人才和技术人才进行需求的梳理、过滤、分析,这个过程在很多项目实践中,都存在或多或少的把关不严、需求遗漏、需求理解偏差等等问题。
  4.需求传递失真
  这个问题,在任何一个项目实践中,都存在,100%。项目沟通问题、沟通效果问题、沟通机制问题永远是项目管理中的核心问题,也是最常见的问题。
  5.未能有效的控制需求范围和进行需求冻结
  相信,有过实际项目经验的项目经理看到这个问题,心都会莫名的一痛,太有感触了。甲方项目经理的职业素养和供应商的的专业程度,是这个问题的核心因素。
  “甲方粑粑,求放过!!!”
  6.未能有效的落实需求跟踪
  需求分析、需求评审、需求变更评审完成后,要进行有效的需求跟踪,包括用户方和产品研发,都要实时的跟踪项目中每一个需求的情况,很多项目经理会忽视这一条,开完评审会,将PRD文档扔给研发就完事了,研发不反馈就不跟踪,然后,交付的时候很可能一地鸡毛,项目经理永远是最了解客户、最熟悉现场、对需求理解最深刻的角色,作为项目质量管控的最终负责人,需要对任何一个需求的落地和可行性负责。
  7.需求管理流于表面
  这是个管理问题,不是需求和技术问题。
  项目管理中的需求管理有如此多可能存在风险的地方,那么如何去防范呢?有哪些针对性的措施呢?
  1)建立有效的、规范的项目沟通机制,成立项目组。
  2)明确项目的建设范围和内容范围,确定需求范围。
  3)专业、规范的需求管理输出成果材料:《需求调研报告》《需求规格说明书》等。
  4)建立需求管理体系和机制;
  5)落实并执行需求管理规章制度;
  6)明确项目里程碑节点和需求冻结时间;
  7)项目需求相关文档、资料编写要客观、客观、客观,不要犯经验错误,不要无故扩大需求;
  8)进行有效的需求评审和需求确认,需求确认要甲方/业主方项目经理签字(不管有没有用,一定要签);
  9)建立和谐良好的项目组氛围,平衡、协调各方面的项目诉求。
  以上是笔者个人在这些年的项目管理过程中总结出来的一些情况,可能会有遗漏,个人境遇不一样,可能会有些偏差,望各位读者理解。

     上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海信义律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2021, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道