需求管理做不好，怎么能管好项目？（需求管理做不好,怎么能管好项目呢）
需求管理，说起来似乎也没那么难，但在各个项目中具体做起来时，往往会出现各式各样的问题，导致实际的需求管理效果并不理想。
那么，如何保障需求管理成功？与其罗列保障成功的诸多因素，不如找到最容易导致失败的几个关键问题，从而提前规避。
本文梳理了需求管理中最容易忽略的10大隐患问题，这些问题在项目开展过程中，大部分情况是“重要但没那么紧急的”，能否将项目管理的功夫花在平时，是保障项目需求管理成功的关键。
01
没有制定项目的整体管理计划
项目整体管理计划是要确定项目如何执行、监控和结束的方式、方法。定义项目开展过程中，有哪些规则、标准。比如哪些是必须做的、哪些是可以省略的，需要明确出来。
从落实层面上看，可能是平时沟通没到位，或者启动会上漏了几句提醒/声明；也可能是组织、团队在流程机制、管理方面的缺失。
具体而言，整体管理计划中，往往需要关注的有：范围管理计划、需求管理计划、进度管理计划、成本管理计划、沟通管理计划、变更管理计划、配置管理计划等。比如，沟通管理中，沟通的渠道/形式/频率，日报/每日例会、周报/周例会、阶段性报告等，有哪些规则必须遵守等等。
关于项目计划的可以查看以下文章：
- 图解项目经理必备目标拆分和制定计划步骤方法
- 2022项目计划进度管理表：文末可下载直接编辑使用的甘特图
- 还在为项目管理规划发愁吗？这是我见过的最高逼格的项目管理体系和落地计划
- 制定项目计划不是你想象中的那么容易
02
没有制定有效的范围和需求管理子计划
如何制定有效的范围和需求管理子计划呢，最关键的一点，最基本的流程和标准要清晰：
- 收集需求
- 范围定义
- 创建WBS
- 范围核实
- 范围控制
其中范围定义，要明确以下基本信息，输出项目范围说明书：
- 项目目标
- 产品范围描述
- 项目可交付物
- 项目边界
- 产品验收标准
- 项目的约束条件
- 项目的假设
关于如何创建WBS，可参见如下往期文章：
03
没有制定合理的整体变更流程和需求变更控制流程
变更基本流程可以参考以下几个方面：
- 提出与接受变更申请
- 项目干系人都可以提出变更，提出可以由不同的方式，口头、书面均可，但变更应及时以正式方式记录。
- 对变更的初审
- 这个环节主要是通过对变更申请文档的审核来实现。项目经理、项目关键相关方对变更施加影响，确认变更的必要性，确保变革是有价值的；
- 针对变更记录的格式、完整性做校验，确保变更评估所需的信息是准备充分的；
- 与干系人一起，就供评估的变更信息达成共识。
- 变更方案的论证
- 项目管理委员会审查
- 发出变更通知并组织实施
- 变更实施的监控
- 变更效果的评估
- 判断发生变更后的项目是否已纳入正常轨道
- 关于需求变更的可以查看以下文章：
- 如何应对项目需求变更？应对变更的流程步骤和方法
- 项目经理如何应对客户的需求变更？
- 如何在敏捷项目中管理范围变更？
- 如何应对频繁的需求变更？
04
对客户的需求获取不充分
对客户的需求获取不充分主要有两种情况：
- 对客户干系人的识别不完整
- 互联网软件项目，通常客户干系人除了用户之外，还是甲方的高层领导、IT、运维等部门；往往很多项目只关注用户需求的调研，而忽视了比如客户高层、IT、运维关键相关方的需求，导致在系统性能、质量、安全等非功能性需求被忽视，开发过程中不断变更，甚至无法通过验收。
- 对客户需求收集、调研不充分
- 通常客户也比较忙，这就需要在客户关系、需求收集的方法/技能上多下一些功夫。比如收集之前做好充分的准备，通过访谈、观察、原型、标杆对照、系统交互图、文件分析（方案文档、合作协议、招投标文件、业务流程图、数据模型、功能清单、用例文档等）技术方法提高需求收集的效率和质量。
05
需求分析工作不充分，缺乏需求定义环节
往往仅有初步的需求说明书，没有定义出详细的需求规格说明书。甚至存在一些公司或项目团队，不写需求说明书——这不仅不利于需求的管理，更是公司组织资产流失的一种隐患。
需求定义是收集到客户的需求之后，对需求的进一步确认。因为客户提出的往往是基于某一方面的需求意见，至于放在整个软件系统中，有无与其他需求的关联、影响、冲突、限制，有无明确具体的度量和验收标准等等，这些都需要结合需求完整性进行进一步的定义。
针对这一环节的综合建议是清晰定义需求分析工作的输出标准，规范需求说明书、需求规格说明书模板，并按要求严格执行。
06
缺乏需求验证环节
当“完成”需求收集时，不少人认为接下来就是要马上进行需求分析、产品设计，而忽略了什么才叫做“完成”。
当需求收集之后，只能算作是自认为的完成，实际上并没有得到客户的综合确认，因为通常情况下，需求的收集是来自于多个客户，多个相关方的，对于每个客户而言，他们并不一定清楚需求收集“完整”之后是怎么样的，对于客户A收集的需求是否与B的需求有冲突，有没有他们认为需要调整、补充的地方，都是待定的，因此，请客户代表一起进行需求评审，得到干系人对需求的一致理解，得到干系人对需求的承诺，这一步非常重要，是对需求验证的关键，是减少后续需求变更的重要保障。
关于需求管理的可以查看以下文章：
PMO项目集管理中客户需求挖掘的方法和步骤？【慕哲系列25】
项目管理的最重要的一环需求管理该如何做？
07
没有有效地管理需求变更控制
关于需求变更常犯的错误是，这个需求变更不大，直接做了吧，当一个个小的变更不断累计，造成里程碑目标不能按时达成时，才发现为时已晚。
关键问题在于：变更无记录，全凭感觉管理，这是不行的。正式的变更记录是基础（参见第3点变更流程）；其次是变更的控制，缺少变更控制的标准。需要提前达成共识，什么情况下可以由项目经理直接决定，什么情况下必须走变更控制委员会审批。
这里需要注意的一个点是：当变更走到变更委员会审批时，其宗旨不是为了一味地拒绝变更、减少变更，而是更加完整的评估变更的影响，从而保障必要的变更能够在合理的时间、资源、成本下得以实现。（往往重大的变更会带来资源、 成本、时间等方面的调整，多数情况是是增加的投入）
08
范围没有管好，导致不断地范围蔓延
这一环节强调的是在需求管理的基础上，综合时间、资源、成本等多方面因素，对范围的进一步确认、核实与控制。并且需要注意的是，这项工作不仅仅只在需求完成后进行，而是在整个项目开展过程中，需要持续地关注。
这一步往往没做好也是可能由于多方面因素造成的，但主要原因在于：
- 没有流程规范，工作环节遗漏，比如没有按照收集需求、范围定义、创建WBS、范围核实、范围控制的流程步骤开展工作
- 有流程规范，但往往造成不容易控制的关键在于前一步WBS工作不到位，导致评估出现偏差，不能够有效支撑范围的核实与确认
09
未做好需求与进度的管理
当需求范围变更时，没有充分评估对进度等其他方面的影响，导致进度延误。尤其在需求、进度被分配为项目团队中两个人分别负责又没能够有效统筹时，更容易被忽略。
10
项目生命周期模型选择不当
通常瀑布模型、敏捷迭代模型大家比较熟悉，此外，还有V模型、原型化模型、螺旋模型等。几种模型各有特点，尤其在目前互联网软件行业高速发展的阶段，结合不同的场景选择适当的模型，合理地规划项目里程碑计划，也是影响需求管理成败的一个不可忽略的因素之一。
以上需求管理相关的10大隐患，也是往往会被认为有必要参考但又往往容易被忽视的问题，总认为不用搞那么正式地执行，但至于要执行到什么程度，又没有一个清晰的标准和界限——这就是导致频频出问题的关键所在。
需求管理中，我们不能因为团队成员总有更紧急重要的事情要做，而忽略了更重要但没那么紧急的事情，偏离“规矩”，从而埋下一个个隐患；更不能想当然地认为大家可以结合时间、资源来自由发挥。
以上，供各项目经理们参考，谢谢~
