需求管理做不好,怎么能管好项目?(如何做好需求管理)

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

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

本文梳理了需求管理中最容易忽略的10大隐患问题,这些问题在项目开展过程中,大部分情况是“重要但没那么紧急的”,能否将项目管理的功夫花在平时,是保障项目需求管理成功的关键。

01

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

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

从落实层面上看,可能是平时沟通没到位,或者启动会上漏了几句提醒/声明;也可能是组织、团队在流程机制、管理方面的缺失。

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

关于项目计划的可以查看以下文章:

02

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

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

  1. 收集需求
  2. 范围定义
  3. 创建WBS
  4. 范围核实
  5. 范围控制

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

  1. 项目目标
  2. 产品范围描述
  3. 项目可交付物
  4. 项目边界
  5. 产品验收标准
  6. 项目的约束条件
  7. 项目的假设

关于如何创建WBS,可参见如下往期文章:

03

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

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

  1. 提出与接受变更申请
  2. 项目干系人都可以提出变更,提出可以由不同的方式,口头、书面均可,但变更应及时以正式方式记录
  3. 对变更的初审
  4. 这个环节主要是通过对变更申请文档的审核来实现。项目经理、项目关键相关方对变更施加影响,确认变更的必要性,确保变革是有价值的
  5. 针对变更记录的格式、完整性做校验,确保变更评估所需的信息是准备充分的
  6. 与干系人一起,就供评估的变更信息达成共识
  7. 变更方案的论证
  8. 项目管理委员会审查
  9. 发出变更通知并组织实施
  10. 变更实施的监控
  11. 变更效果的评估
  12. 判断发生变更后的项目是否已纳入正常轨道
  13. 关于需求变更的可以查看以下文章:
  14. 如何应对项目需求变更?应对变更的流程步骤和方法
  15. 项目经理如何应对客户的需求变更?
  16. 如何在敏捷项目中管理范围变更?
  17. 如何应对频繁的需求变更?

04

对客户的需求获取不充分

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

  1. 对客户干系人的识别不完整
  2. 互联网软件项目,通常客户干系人除了用户之外,还是甲方的高层领导、IT、运维等部门;往往很多项目只关注用户需求的调研,而忽视了比如客户高层、IT、运维关键相关方的需求,导致在系统性能、质量、安全等非功能性需求被忽视,开发过程中不断变更,甚至无法通过验收。
  3. 对客户需求收集、调研不充分
  4. 通常客户也比较忙,这就需要在客户关系、需求收集的方法/技能上多下一些功夫。比如收集之前做好充分的准备,通过访谈、观察、原型、标杆对照、系统交互图、文件分析(方案文档、合作协议、招投标文件、业务流程图、数据模型、功能清单、用例文档等)技术方法提高需求收集的效率和质量。

05

需求分析工作不充分,缺乏需求定义环节

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

需求定义是收集到客户的需求之后,对需求的进一步确认。因为客户提出的往往是基于某一方面的需求意见,至于放在整个软件系统中,有无与其他需求的关联、影响、冲突、限制,有无明确具体的度量和验收标准等等,这些都需要结合需求完整性进行进一步的定义。

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

06

缺乏需求验证环节

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

当需求收集之后,只能算作是自认为的完成,实际上并没有得到客户的综合确认,因为通常情况下,需求的收集是来自于多个客户,多个相关方的,对于每个客户而言,他们并不一定清楚需求收集“完整”之后是怎么样的,对于客户A收集的需求是否与B的需求有冲突,有没有他们认为需要调整、补充的地方,都是待定的,因此,请客户代表一起进行需求评审,得到干系人对需求的一致理解,得到干系人对需求的承诺,这一步非常重要,是对需求验证的关键,是减少后续需求变更的重要保障。

关于需求管理的可以查看以下文章:

如何应对项目需求变更?应对变更的流程步骤和方法

PMO项目集管理中客户需求挖掘的方法和步骤?【慕哲系列25】

项目管理的最重要的一环需求管理该如何做?

项目经理如何应对客户的需求变更?

07

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

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

关键问题在于:变更无记录,全凭感觉管理,这是不行的。正式的变更记录是基础(参见第3点变更流程);其次是变更的控制,缺少变更控制的标准。需要提前达成共识,什么情况下可以由项目经理直接决定,什么情况下必须走变更控制委员会审批。

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

需求管理做不好,怎么能管好项目?(如何做好需求管理)

08

范围没有管好,导致不断地范围蔓延

这一环节强调的是在需求管理的基础上,综合时间、资源、成本等多方面因素,对范围的进一步确认、核实与控制。并且需要注意的是,这项工作不仅仅只在需求完成后进行,而是在整个项目开展过程中,需要持续地关注。

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

  • 没有流程规范,工作环节遗漏,比如没有按照收集需求、范围定义、创建WBS、范围核实、范围控制的流程步骤开展工作
  • 有流程规范,但往往造成不容易控制的关键在于前一步WBS工作不到位,导致评估出现偏差,不能够有效支撑范围的核实与确认

09

未做好需求与进度的管理

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

10

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

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

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

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

以上,供各项目经理们参考,谢谢~

需求管理做不好,怎么能管好项目?

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2022年8月31日 上午8:40
下一篇 2022年8月31日 上午8:42

相关推荐