需求管理，说起来似乎也没那么难，但在各个项目中具体做起来时，往往会出现各式各样的问题，导致实际的需求管理效果并不理想。

那么，如何保障需求管理成功？与其罗列保障成功的诸多因素，不如找到最容易导致失败的几个关键问题，从而提前规避。

从下文的10大隐患问题，你是不是也曾遇到过？

1.没有制定项目的整体管理计划

项目整体管理计划是要确定项目如何执行、监控和结束的方式、方法。定义项目开展过程中，有哪些规则、标准。比如哪些是必须做的、哪些是可以省略的，需要明确出来。

具体而言，整体管理计划中，往往需要关注的有：范围管理计划、需求管理计划、进度管理计划、成本管理计划、沟通管理计划、变更管理计划、配置管理计划等。比如，沟通管理中，沟通的渠道/形式/频率，日报/每日例会、周报/周例会、阶段性报告等，有哪些规则必须遵守等等。

关于项目计划，感兴趣的朋友可以去看看《PMBOK》指南这本书，或者考一个PMP，能学到系统的项目管理知识。

2.没有制定有效的范围和需求管理子计划

如何制定有效的范围和需求管理子计划呢，最关键的一点，最基本的流程和标准要清晰：

收集需求

范围定义

创建WBS

范围核实

范围控制

其中范围定义，要明确以下基本信息，输出项目范围说明书：

项目目标

产品范围描述

项目可交付物

项目边界

产品验收标准

项目的约束条件

项目的假设

如何创建WBS，项目管理的核心工具WBS工作分解结构，PM必备技能！

3.没有制定合理的整体变更流程和需求变更控制流程

变更基本流程可以参考以下几个方面：

1.提出与接受变更申请

2.对变更的初审

3.变更方案的论证

4.项目管理委员会审查

5.发出变更通知并组织实施

6.变更实施的监控

7.变更效果的评估

8.判断发生变更后的项目是否已纳入正常轨道

4.对客户的需求获取不充分

对客户的需求获取不充分主要有两种情况：

1.对客户干系人的识别不完整

2.对客户需求收集、调研不充分

5.需求分析工作不充分，缺乏需求定义环节

往往仅有初步的需求说明书，没有定义出详细的需求规格说明书。甚至存在一些公司或项目团队，不写需求说明书——这不仅不利于需求的管理，更是公司组织资产流失的一种隐患。

需求定义是收集到客户的需求之后，对需求的进一步确认。

针对这一环节的综合建议是清晰定义需求分析工作的输出标准，规范需求说明书、需求规格说明书模板，并按要求严格执行。

6.缺乏需求验证环节

当“完成”需求收集时，不少人认为接下来就是要马上进行需求分析、产品设计，而忽略了什么才叫做“完成”。

通常情况下，需求的收集是来自于多个客户，多个相关方的，对于每个客户而言，他们并不一定清楚需求收集“完整”之后是怎么样的。

请客户代表一起进行需求评审，得到干系人对需求的一致理解，得到干系人对需求的承诺，这一步非常重要，是对需求验证的关键，是减少后续需求变更的重要保障。

7.没有有效地管理需求变更控制

关于需求变更常犯的错误是，这个需求变更不大，直接做了吧，当一个个小的变更不断累计，造成里程碑目标不能按时达成时，才发现为时已晚。

需要注意的是：当变更走到变更委员会审批时，其宗旨不是为了一味地拒绝变更、减少变更，而是更加完整的评估变更的影响，从而保障必要的变更能够在合理的时间、资源、成本下得以实现。（往往重大的变更会带来资源、 成本、时间等方面的调整，多数情况是是增加的投入）

8.范围没有管好，导致不断地范围蔓延

这一步往往没做好也可能是由于多方面因素造成的，但主要原因在于：

没有流程规范，工作环节遗漏，比如没有按照收集需求、范围定义、创建WBS、范围核实、范围控制的流程步骤开展工作

有流程规范，但往往造成不容易控制的关键在于前一步WBS工作不到位，导致评估出现偏差，不能够有效支撑范围的核实与确认。

9.未做好需求与进度的管理

当需求范围变更时，没有充分评估对进度等其他方面的影响，导致进度延误。尤其在需求、进度被分配为项目团队中两个人分别负责又没能够有效统筹时，更容易被忽略。

10.项目生命周期模型选择不当

通常瀑布模型、敏捷迭代模型大家比较熟悉，此外，还有V模型、原型化模型、螺旋模型等。几种模型各有特点，尤其在目前互联网软件行业高速发展的阶段，结合不同的场景选择适当的模型，合理地规划项目里程碑计划，也是影响需求管理成败的一个不可忽略的因素之一。

以上需求管理相关的10大隐患，也是往往会被认为有必要参考但又往往容易被忽视的问题，总认为不用搞那么正式地执行，但至于要执行到什么程度，又没有一个清晰的标准和界限——这就是导致频频出问题的关键所在。

需求管理中，我们不能因为团队成员总有更紧急重要的事情要做，而忽略了更重要但没那么紧急的事情，偏离“规矩”，从而埋下一个个隐患；更不能想当然地认为大家可以结合时间、资源来自由发挥。