有效需求管理

由于许多组织发现,利用项目管理过程有助于提高项目成功的概率,然而糟糕的需求管理过程(或缺乏需求管理过程)被认为是导致项目失败的主要原因。这就引出了一个问题:需求管理怎么样?需求管理过程如何解决项目延迟和失败的原因并促进项目成功?

摘自IT帮《BangBA公开课》讲义

需求

需求是什么?

需求是产品必须满足的能力,以满足用户解决问题的需要。用户的需求可以来自多个来源,包括对标准或法律法规的遵从性、业务需求、业务问题、市场需求、竞争等。

需求可以分为功能性需求和非功能性需求(Robertson 1999)。功能需求是产品必须满足特定用户需求的能力。它们是最基本的要求。功能需求有时被称为业务需求。它们描述了预期产品可以执行的功能,以使业务用户能够完成部分工作并继续其业务(运营)工作。

非功能性需求包括可用性、性能、可靠性和安全性需求。这些都是产品必须具备的品质。技术需求也属于非功能类别。非功能需求的重要性不亚于功能需求。在某些项目中,满足所有功能需求但仍有一个重要的非功能需求(如性能需求)未得到满足的已完成产品被视为项目失败。

摘自IT帮《BangBA公开课》讲义

需求与范围

产品需求是否等同于产品范围?不完全是。项目管理知识体系指南(PMBOK®指南)将产品范围定义为产品、服务或结果的特性和功能。根据产品需求衡量产品范围的完成情况。需求决定了任何项目的范围。虽然不建议在产品范围中包含超过规定需求的内容,但提供低于用户规定需求的内容并不符合用户期望。

需求管理

为什么需求管理很重要?

无效的需求管理过程(或者更常见的是,不采用任何需求过程)被认为是项目失败的主要原因。具体来说,范围蔓延或无法控制它们是项目成本超支或项目延误的常见原因。IBM rational项目经理调查(Visitacion,2003)表明,IBM项目经理认为控制范围扩展和需求质量是成功的最大预测因素。Wiegers(2002)确定了8个典型的需求问题,它们可能会破坏项目。他写道,成功的(软件)项目高度依赖于理解良好的需求,并提出了避免陷阱的方法,以有效地收集、记录或管理需求。

需求问题应该在项目生命周期的早期解决,因为基于较差需求的设计问题会导致在项目开发顺利进行之后(例如,进入项目执行阶段)更难解决且成本更高的设计问题。对从项目生命周期开始实施的需求过程的投资在项目结束时得到了回报。

美国国家航空航天局总部成本与经济分析处的项目成本统计表明,在需求过程中花费少于项目或项目总成本5%的项目会出现80%到200%的成本超支,而那些投资8%到14%的人的超额回报率不到60%(Young,2003)。美国航天局的研究得出结论,在需求过程中投资占项目总成本的8%到14%,项目结果的成本超支会大大降低。

质量差、工程失败、竣工晚或超预算的要求。其他项目成功完成的时间和预算交付的特点和功能没有使用。研究表明,只有45%的IT产品的特性和功能被使用。

项目失败原因

关于项目失败的研究(Standish Group,1995)确定了项目失败的以下原因:

  1. 不完整的需求
  2. 不涉及用户
  3. 资源/进度不足
  4. 不现实的期望
  5. 缺乏管理支持
  6. 不断变化的需求
  7. 计划不周
  8. 不再需要需求了

项目失败的最常见原因并不都与需求问题有关。然而,需求问题和项目问题需要在项目生命周期中尽早得到解决。当在项目开发生命周期的中期提出时,许多与需求无关的项目问题(例如,执行支持、项目管理技能)可以得到纠正,并且项目开发可以继续进行,而不会对项目结果造成重大损失。然而,解决需求问题通常需要项目团队从头开始定义/澄清需求,并且已经花费在项目上的大部分开发工作都是浪费的。

在需求管理的当前状态下,尤其是在IT行业,项目经理在需求问题出现时提出并强调需求问题。他们试图使用需求过程来解决问题。如果所有的项目经理应用所学到的经验教训来防止需求问题的再次发生,那么许多需求问题可以在项目开发的早期阶段被发现和解决,或者在项目开发过程中被消除。

这并不是那么简单,因为许多需求过程需要客户的参与和参与,以及他们的合作和协作。一些需求过程提出了实现挑战。

然而,当项目管理团体和组织关注于解决项目失败的主要原因并采取措施解决这些需求问题时,项目经理发现组织需求过程的实施能够并且确实有助于项目的成功。

需求管理过程

需求管理包括以下过程:需求规划、需求开发、需求验证和需求变更管理。它包括计划、收集、定义、细化、组织、记录、测试需求、验证需求是否得到满足以及跟踪和控制需求变更的过程。

img

需求计划

需求计划是一个涉及需求管理计划的开发、评审和批准的过程。需求管理计划必须由所有适当的利益相关者(客户、用户、开发/设计团队领导/经理)审查,并由项目发起人和关键利益相关者批准。

摘自IT帮《BangBA公开课》讲义

需求开发

需求开发包括需求收集和获取、需求分析和需求定义。

收集与获取

需求可以是已知的,也可以是未知的。需求收集的目的是收集尽可能多的已知需求。需求收集过程既关键又困难(Phillips 2000)。虽然从用户那里收集需求、记录和记录信息似乎很简单,但通常很难获得准确和有组织的信息。信息可以以不同的形式提供(例如,通过电子邮件、一次面谈、电话留言、会议)和不同的格式(例如,文件、数据库或电子表格格式)。对信息进行澄清、组织和优先排序是一项非常耗时和艰巨的任务。

获取的目的是确定不同项目利益相关者的需求和限制(Wiegers 1999)。这个过程的结果是项目利益相关者对用户所表达的需求的共同理解。

摘自IT帮《BangBA公开课》讲义

需求定义

需求定义是组织、记录、定义和细化需求的过程。需求定义文档(RDD),有时被称为需求规范,是产品需求的文档。批准的RDD(也称为需求基线)是商定产品范围的文档。它被认为是业务用户(有时由产品赞助商代表)和产品开发人员之间要开发的产品的合同。

如果产品开发外包给外部团体或组织,需求定义是工作说明书(SOW)的一个组成部分(Kerzner,2003)。与任何合同一样,RDD必须详细记录,并且必须由适当的利益相关者签署。尽管所有利益相关者都希望需求非常详细和充分理解,但需求必须定义用户的需求-从产品中期望什么,而不是如何在产品中满足用户的需求。开发人员需要充分了解需求(用户的问题是什么)才能开发解决方案(如何解决问题)。通常的做法是在组织内使用SOW模板。

定义功能性和非功能性需求、约束和假设的标准模板是记录和报告需求的有用工具。许多系统/软件工具(Visitacion 2003)在商业上可用于组织、优先排序和报告需求。工作分解结构(WBS)是识别所有产品交付物的常用工具。WBS充分详细地定义了工作可交付成果,使得每个可交付成果的组成部分都可以很容易地管理(在成本、质量和进度方面)。IEEE标准803-1998软件需求规范推荐规程(IEEE 1998)有时被用作软件项目中需求规范的模板。许多组织从行业中常用的模板开始,并根据组织的需要定制模板。

摘自IT帮《BangBA公开课》讲义

需求分析

与需求收集和获取密切相关的是需求分析。需求分析的目的是发现未知需求,即将未知需求转化为已知需求。通过需求分析可以发现在需求收集和获取过程中没有表达的用户需求。如果在项目生命周期中尽早发现未知或遗漏的需求,对项目是有益的。这将使需求变更的成本影响最小化。

摘自IT帮《BangBA公开课》讲义

需求验证

需求验证是确保满足所有规定需求的过程。该过程在项目生命周期的需求阶段执行。它包括分析开发计划中如何处理需求,以及用户验收测试和验证。

摘自IT帮《BangBA公开课》讲义

需求变更管理

需求变更管理(RCM)涉及实施与集成项目变更控制系统一致的(需求)变更控制系统,并管理变更的实际实施(批准的变更请求)。RCM与需求开发和需求验证齐头并进。它是需求管理的重要组成部分。需求管理计划是该过程的一个输入,必须定义RCM的关键组成部分,包括变更控制系统、变更控制委员会作为处理变更请求的控制和决定机构、过程的任何例外/限制以及任何允许的偏差。

有效的需求管理

一个有效的需求管理过程必须包括上面定义的所有四个需求过程:需求计划、需求开发、需求验证和需求变更管理。这四个过程中没有一个是可选的,以确保所有的需求都被很好地理解,在项目生命周期中足够早地被了解,在开发计划中得到解决,并在最终产品中得到满足。

摘自IT帮《BangBA公开课》讲义

有许多工具和技术可用于这些需求过程,包括用于组织和记录需求的系统/软件工具、用于定义和报告需求的模板、收集和获取技术、测试和验证工具以及变更控制系统工具。最有用的工具是包含上述所有过程的工具,以及当需求过程作为正式的标准化过程实施时使用的工具,这些过程具有定义的输入、工具和技术以及输出。

将其中一些过程作为需求活动执行,而不是作为正式的标准组织过程执行,确实有助于改进项目开发结果,但并不能解决项目中的所有需求问题。

例如,需求收集是一项非常耗时的活动。在一些项目中,需求收集可能占据项目生命周期的25%。然而,如果不能提供一套完整而准确的客户需求,这种活动可能是徒劳的。许多组织继续将需求收集视为一种活动,而不是一种标准化的组织过程。为了有效,需求收集必须结构化,并且必须与客户协作,并与涉及客户的其他需求活动(如需求获取和需求确认)相关联。

项目管理实践者习惯于遵循有明确输入和输出的过程。他们倾向于在实现过程之前寻找可用的输入,为输出和其他工具/技术寻找模板,以用于生产过程可交付成果。过程可交付成果应明确定义。

需求规划的可交付成果是由项目发起人和关键利益相关者审查和批准的需求管理计划。

需求开发的可交付成果是对需求的共同理解。一个写得好的RDD只有在它代表了关键项目利益相关者(项目发起人/用户和开发团队之间)对需求的共同理解时才是有效的。需求分析师的角色是非常关键的。为了有效地扮演这个角色,需求分析员必须熟练地收集信息,机智地引出需求,并且分析优先顺序和组织请求的信息。

需求验证的可交付成果是用户对所有需求都已满足的正式接受。用户验收必须记录在案并得到批准。业务用户参与产品的评审、测试和验证是需求验证成功的最佳保证。关键的促成因素包括早期和充分的用户参与需求过程。

需求变更管理的可交付成果是正确处理所有需求变更请求和实施(批准的)变更。在项目生命周期的一开始,很少知道所有的需求。将会有需求变更请求。项目组必须准备好处理这些问题。一个商定的变更控制系统和一个预先安排的变更控制委员会,以及适当的控制和决策权限,是有效的需求变更管理过程的必要条件。所有的变更请求 – 无论大小,不管是谁发起的请求 – 都必须通过变更控制委员会。

总而言之,一个有效的需求管理过程必须包括上面定义的所有四个需求管理过程:需求规划、需求开发、需求验证和需求变更管理,以及每个过程的相关正式标准组织实施。

转:Effective requirements management

更多文章

业务架构学习群资料

D10.1 标准化业务架构

1. 太多未对齐的业务架构视图导致混乱和合理性挑战
2. 工具厂商解决方案与标准映射方法不完全一致,导致团队混乱,部署速度减慢
3.管理人员感觉还没有为业务架构做好准备,因为没有一致的部署方法
4. ……

阅读更多»
星球资料

Shingo模型手册

Shingo模型有十项指导原则,这些原则管理着卓越运营的创建,同时将其组织为四个维度。该模型还包括所谓的转型过程(称为菱形)。该菱形代表了系统、原则、成果和工具之间的关键关系。

阅读更多»