编辑导语：需求管理对于项目来说十分重要，前两篇文章分别介绍了需求管理的基本定义、分类方式、重要意义和一些常见的项目失败原因。通过前文的介绍，想必大家对于需求管理的基础概念都已经有了新的认识。那么，让我们进入到最核心的部分，同时也是需求管理系列文章的最终篇：需求管理体系的搭建。
一、标准化的需求管理
需求管理通常包括以下阶段：
- 需求规划
- 需求处理
- 需求验证
- 需求变更管理
以上环节又可以拆分为：
规划需求、收集需求、定义需求、精炼需求、组织需求、记录需求、测试需求，验证产品是否满足需求以及跟踪和控制需求的变更情况等详细步骤和环节。
P1: 需求规划
需求规划包括需求管理计划的制订、评审和批准环节。需求管理计划必须经过所有利益相关方/干系人(包括客户、用户、研发/设计团队领导/经理) 的评审，并且经过项目发起人和关键干系人批准。
「凡事预则立，不预则废」，就需求管理而言，在需求的整个生命周期中，需求规划阶段充当着最核心的作用，可以说需求规划的完善程度几乎决定了后续项目的成果与否。
现在有很多种需求规划模型和方法可供选择，我个人比较喜欢 Google 的 GIST 管理方法：
GIST = Goals + Ideas + Steps + Tasks
基于 GIST 方法，我们需要完成以下四个环节：
- 管理层基于前景分析，竞争分析，战略分析等一系列商业和战略分析结果，制订业务目标
- 产品管理人员将业务目标初步分解为业务想法 (往往等价于产品需求) ，并分配给产品经理
- 产品经理将业务想法进一步拆分，依次得到需要设计和开发的业务环节 (等价于功能点)
- 项目经理、产品经理和相关人员基于具体的业务环节进行更进一步的分析和研究，依次得到各人员需要完成的具体任务，并相应进行分配。
P2: 需求处理
完成对于产品需求的整体规划之后，就应该进入需求处理阶段了。需求处理阶段可以细分为需求收集&需求探索、需求分析和需求定义环节。
结合 P1 所介绍的 GIST 方法，我们很容易发现需求的业务环节和任务分解过程和需求的收集、定义和分析过程是相关关联的。
换言之，需求的具体规划过程和需求处理过程往往是同步进行的。
Step1: 收集和探索
用户的某些需求可能被人熟知，而另外有一些需求可能无人知晓，但是前者不一定比后者更重要。
需求收集的目标是收集尽可能多的需求，最小化未知需求。需求收集的过程非常关键却又相当困难：尽管从用户反馈记录和相关文档中收集信息看起来毫不费力，但是获得准确无误而且组织有序的需求却并不容易。
这些信息可能通过多种方式 (例如，电子邮件，面对面访谈，电话留言，会议记录等) 收集，并以不同的形式 (例如，文本文档，电子表格或存储在数据库中) 呈现。对这些需求信息进行必要的梳理和组织，并确定需求优先级可能是一件相当耗时，繁琐到令人生畏的任务。
需求探索是基于已收集需求进行发散性的讨论，的目的是确认项目不同的利益相关方的需求和限制因素。该过程的结果是：最终在项目干系人间达成了对于用户所表达需求的共同认识。
Step2: 需求定义
需求定义是组织、记录、定义和优化需求的过程。需求定义文档 (Requirements Definition Documentation, RDD) 有时称为需求规约，也就是我们日常所指的产品需求文档。
经过批准的RDD ( 也称为需求基线) 是商定产品范围的文档。它被认为是业务用户 (有时由产品发起人代表) 和产品开发人员之间对于即将开发产品功能的具体规范。
与任何规范一样，RDD 必须记录详细，具体而微，并且必须由合适的项目干系人认可和一直遵守。尽管我们期望这些需求非常详细且被利益相关者充分理解，但这些需求必须仔细定义用户的实际需要，也就是用户预期产品拥有怎样的功能特性，而不是新产品将如何满足用户的现有需求。
开发人员需要充分地了解需求(用户的问题是什么) ，才可以设计出好的解决方案 (何修复用户的问题)
需求文档的标准模板需要充分定义功能型需求和非功能需求，功能约束和基本假设，这种模板是记录和报告需求的有力臂助。市场上有很多可商用的系统和软件可以用于需求的组织、优先级排序和报告。
工作分解结构 (Work Break-out Structure, WBS) 是标识所有产品可交付成果的常用工具。
WBS 对工作可交付成果的定义足够详细，便于轻松管理 (在成本、质量和进度方面) 可交付成果的每个部分。IEEE 标准 803-1998 软件需求规约的推荐实践(IEEE 1998) 有时也被用作软件项目中需求规约的模板。许多组织选择行业中常用的模板作为基准，并按照自身的实际需求对这些模板进行裁剪定制。
Step3：需求分析
需求分析与需求收集和需求探索紧密相关。需求分析的目的在于发现未知需求，然后将未知需求转化为已知需求。那些在需求收集和需求探索阶段，用户未提及的需求往往可以通过需求分析挖掘出来。如果在项目早期就可以找到这些未知或者遗失的用户需求，对项目大有裨益，这帮助项目将需求变更所产生的成本影响最小化。
需求收集和探索的常用方法包括：
客户体验地图、头脑风暴、商业折纸、脉络设计、卡诺分析等
P3：需求验证
需求验证是指确保所有已提及需求都被充分满足地过程。需求验证流程通常在项目的需求阶段执行，它包括对于在开发计划中如何满足需求的具体分析，以及用户验收测试 (User Acceptance Testing, UAT) 和有效性验证。
需求验证包括以下常用方法：
参与式行动研究（PAR）、时间感知研究、可用性报告、可用性测试、价值机会分析等
P4：需求变更管理
需求变更管理 (Requirement Changes Management, RCM) 包含需求变更控制系统的具体实施、与前者相一致的集成项目变更控制系统以及变更(被批准的变更请求) 的实际实施机制。
需求变更管理常常和需求处理和需求验证同步进行，是需求管理的必要组件。
该环节的输入信息是需求管理计划，同时必须仔细定义 RCM 系统的关键部分：
- 首先是需求变更管理系统；
- 其次是作为控制和决策的主体的变更管理委员会；他们需求要处理变更请求；
- RCM 流程的任何例外和限制；
- 以及任何可允许的其他偏差。
所有的变更请求，无论大小，不管由谁发起，都应当通过变更管委会。
二、各阶段的交付物
项目管理从业者惯于遵循那些拥有充分定义的输入信息和输出信息的业务流程。在将流程和模板实施到输出信息之前，他们倾向于寻找有效的输入信息和其他可以用于产出流程可交付物的工具和技术。流程的可交付成果应当得到充分的定义。
需求规划阶段的可交付成果是需求管理计划，由项目发起人和关键干系人评审和批准。
需求处理阶段的可交付成果是所有项目干系人对于需求的共识，RDD 是其共识的记录规范。
一份编写良好的 RDD 只有在它代表了关键项目干系人(包括项目发起人/用户和研发团队) 对于需求的共识时，才足够有效。而需求分析充当着极为关键的角色，要充分发挥需求分析的作用，需求分析师(或者产品经理) 必须精于收集信息，擅于探索需求，长于优先级排序和组织整理信息。
需求验证阶段的可交付成果是用户对于所有需求都得以满足的正式认可。
对于用户端场景，我们需要邀请具有代表性的用户参与测试和验证，并获取其使用反馈。
对于商业端场景，商业客户参与产品评审、测试和验证是需求验证成功的最佳保证。关键因素包括在需求流程中用户的尽早参与和充分协作。
需求变更管理的可交付成果是对所有人需求变更请求的妥善处理以及对于已批准需求的实施。
在项目一开始就识别出所有需求是相当罕见的，大多情况下都会存在需求变更请求。项目团队需要准备好处理突发的需求变更。一个广泛使用的变更控制系统和一个预先安排的拥有适当控制和决策权力的变更控制委员会对于有效的变更管理流程而言都是必要的。
三、高效的需求管理体系
如上所述，任何有效的需求管理流程必须包含四个必要环节：需求规划、需求处理、需求验证和需求变更管理。
其中任何一个环节都是必须的，需求管理系统帮助产品从业者确保相关项目干系人充分理解需求，在项目早期收集完整，在研发阶段得以处理，并在最终产品中得到满足。
我们前文已经列举了需求管理各阶段所涉及到的一些模型和方法，市场上有相当多的工具和技术可供选择：
- 用于组织和记录需求的系统/软件工具；
- 用于定义和梳理需求的模型和文档模板；
- 用户收集和探索需求的框架和模型；
- 用于需求测试和验证的方法和工具；
- 用于需求变更控制方法和工具；
对公司和组织而言，在构建标准化需求管理流程中，所使用的相关技术和工具，只要能满足相应阶段的需求管理目标，就可以视为高效需求管理体系的最佳实践。
如果没有采用标准化的需求管理体系，而仅仅其部分环节作为需求管理获得执行，同样有助于提升项目的效率，但是无助于充分解决项目中的所有需求问题。如上所述，需求管理体系的各环节是紧密关联的，如果缺失部分环节将会极大地影响其他环节的实际效果。
需求收集通常是一件极为耗时的活动，在很多项目中，需求收集往往占据 25% 的项目时间。然而，如果没有产出完整而准确的客户需求列表，前期的收集活动就变得徒劳无功。
即使如此，很多组织仍然只是将需求收集视为一项独立的活动，而非标准化的组织流程。为了提高效率，需求收集活动必须在有客户协助和与其他需要客户参与的需求活动，如需求探索和需求验证，相关联的背景下进行设计和执行。
综上所述，一个卓有成效的需求管理流程必须包含上述的四个需求管理环节，需求规划、需求处理、需求验证和需求变更管理，而且每个环节都需要关联具体的框架模型、工具方法、任务流和文档规范。
本系列至此完结，后续我会分享一些常见的需求管理框架和方法，感谢大家的关注
产品教练
若有收获，就点个赞吧
0 人点赞
