EDA365欢迎您登录！
您需要 登录 才可以下载或查看，没有帐号？注册
x
你有没有一种感觉， 当你在复盘一个失败的项目时， 会发现很多时候 在分析需求的时候就出现问题了， 而需求变更往往与开始的需求有关。 那么如何做好需求管理？ 项目经理如何做好需求管理和分析？ 需求管理最重要的一环应该怎么做？ 如果突然有了紧急需求，该如何处理？ 如何识别客户的真正需求？ 0 g/ J& F5 k2 m+ J' K
6 i+ A o! v' N
项目进行时，往往会出现各式各样的问题，导致效果不理想，那么如何保障需求管理成功？与其保障成功，不如提前规避导致失败的问题。环环整理了需求管理最重要的8个要点，也是能否保障项目需求管理成功的关键。 1 |7 G1 H: c& r* R. \7 }3 b1 Y/ V
1' _0 V1 D9 U( \% U9 m) }. f0 b
制定项目的整体管理计划
% W8 I0 x) Z6 @+ S& q$ M' s. m项目管理的整体计划需要明确项目如何执行、监控和结束的方式、方法。定义项目开展过程中有哪些是必须做的、哪些是可以省略的。( k' q0 [2 n; G4 n! ^: D/ `9 X
% V: r i. ]: q5 E
沟通不到位、启动会遗漏的声明、团队流程机制、管理等等方面都有可能造成项目需求管理的隐患问题。但需要注意：范围管理计划、需求管理计划、进度管理计划、成本管理计划、沟通管理计划、变更管理计划、配置管理计划等。
; ?' m4 m6 c9 N* Y比如沟通管理中，沟通的渠道、形式、频率；日报、每日例会；周报、周例会；阶段性报告等，有哪些规则必须遵守等等。
" ]4 {% W# Y4 R" d. [. A, i2
( J& s H5 `% U! Q6 x- o, F* h$ E5 r制定合理的整体需求变更控制流程变更基本流程可以参考以下两个方面：
. d1 s# s. G/ u9 X 1.提出与接受变更申请 项目干系人都可以提出变更，提出可以由不同的方式，口头、书面均可，但变更应及时以正式方式记录。
1 {0 g$ f7 B& V' m8 x& @2.对变更的初审 这个环节主要是通过对变更申请文档的审核来实现。项目经理、项目关键相关方对变更施加影响，确认变更的必要性，确保变革是有价值的；针对变更记录的格式、完整性做校验，确保变更评估所需的信息是准备充分的；与干系人一起，就供评估的变更信息达成共识。
. a2 ^3 K8 ^: N; z2 o% G8 x, Z0 w8 J0 o
3
3 n, N! E* P- C完善需求管理的定义环节
7 E& B' g& V4 [" n# o& c通常只有一个初步的需求说明，没有定义详细的需求说明。甚至有一些公司或项目团队不编写需求规格说明书——这不仅不利于需求的管理，更是企业组织资产流失的隐患。
, B4 \, `" s W需求的定义是在收集了客户的需求后，对需求的进一步确认。因为客户往往是根据某一方面的需求提出意见的，至于整个软件系统，不存在与其他需求的关联、影响、冲突、限制，也没有明确的具体度量标准和验收标准等等。
& f" T2 p+ K) R" B0 a' x5 x5 d这些需要结合需求完整性进一步定义。对这一环节的综合建议是，明确界定需求分析的输出标准，规范需求规范和需求规范模板，并根据需求严格执行。 t- ]2 f" C8 m
6 H. X" k8 y; H3 U9 o/ F4. c9 l X0 I) ?
完善需求验证环节当“完成”需求收集时，很多人认为下一步就是立即进行需求分析、产品设计，而忽略了什么叫做“完成”。
& _1 q# V9 y; s9 g, _* c" h+ g8 S 需求收集时，只能算作自认为的完成，而实际上，并没有得到客户的确认，因为通常情况下，需求的收集是来自多个客户和多个相关方的。 3 c1 M6 P. o: [' x& R9 S
对于每个客户来说，他们不一定知道什么是“完整”的需求集合。客户A收集到的需求是否与客户B的需求相冲突，是否认为有调整和补充的必要，都是悬而未决的问题。
" n& j5 P' v1 k" Z: p- A* y' J! U因此，要求客户代表一起进行需求评审，得到相关方对需求的一致理解，并获得利益相关人对要求的承诺，是非常重要的。这一步是需求验证的关键，是减少后续需求变更的重要保障。 + I+ g' E6 k; w; N3 ?; _
* X& x8 q; S. T& }0 j5 r: u
5
% m5 ~$ G, P2 S9 h有效地控制管理需求变更关于需求变更的常见错误是，需求变更不大，直接做就可以了，而当一个小小的变更不断累积，导致最后无法按时、按计划实现，就已经来不及了。0 \0 H; j# b* k% B" U
/ P; J$ N- q2 I$ x4 n
关键的问题是：变化没有被记录下来，靠感觉管理。正式的变更记录是基础。然后是变更控制，没有一个变更控制标准。需要提前达成共识，确定何时可以由项目经理直接决定，何时必须由变更控制委员会批准。 ! q& F7 n/ C Z% @/ e6 `2 b$ W6 j
这里需要注意的一点是，当变更提交到变更委员会审批时，其目的并不是盲目地拒绝变更、减少变更，而是更充分地评估变更所带来的影响，从而确保在合理的时间、资源、成本下，能够实现必要的变更。 % W" X3 @+ S4 _+ I7 V+ @: t6 T
7 d' T0 J }- q; F& |& t6
6 f1 }' s# z3 a: L需求范围的确定、核实与控制
3 ~' y5 k, i2 ?; o在需求管理上要注意的是，整合时间、资源、成本等因素，进一步对范围进行确认、查核与管制。需要注意的是，这项工作并不只是在需求完成后才进行，而是需要在整个项目过程中不断地关注。 # J6 f2 Y# i9 a, ^/ T& K+ X. R% M
这一步往往没做好也是可能由于多方面因素造成的，但主要原因在于： • 没有流程规范，工作环节遗漏，比如没有按照收集需求、范围定义、创建WBS、范围核实、范围控制的流程步骤开展工作 • 有流程规范，但往往造成不容易控制的关键在于前一步WBS工作不到位，导致评估出现偏差，不能够有效支撑范围的核实与确认8做好需求与进度的管理。 7 ?" E: x. z$ M" r- l8 P
7 T" [* F8 H' a* u3 d7 ^( r71 E& W4 m4 Q$ K& \8 E6 l
做好需求与进度的管理
5 x6 i0 G1 b! E* v) m) x0 Q当需求范围变更时，没有充分评估对进度等其他方面的影响，导致进度延误。尤其是当需求和进度被分配给项目组中分别负责项目的两个人，不能有效协调时，更容易被忽视。6 t/ h$ }! N$ g" a
! z( n9 |% W% z! `) x
) W9 ]1 g- b# S# @! G3 k8
; T5 @3 _7 g7 Z9 J( @项目生命周期模型选择妥当* E% I2 k, }' _
通常瀑布模型、敏捷迭代模型我们比较熟悉，此外，还有V型模型、原型模型、螺旋模型等。几种模式各有特点，特别是在互联网软件行业高速发展的现阶段，结合不同的场景选择合适的模式，合理规划项目的里程碑计划，也是影响需求管理成败不可忽视的因素。
6 ^+ q2 |# b8 u 3 G1 R! i& X1 k* P6 G
; z& I+ b6 H- L& d5 d! A- D做好以上8点，把容易被忽视的问题重视起来，理清一个标准和界限，就能减少频繁出现问题。不要因为团队成员有紧急、重要的事情要做，而忽略了更重要但没那么紧急的事情，偏离“规矩”，从而埋下一个个隐患；更不能想当然地认为大家可以结合时间、资源来自由发挥。
: o$ n r* w6 ^ | 
/1 
发表于 2022-11-8 09:03
收藏
淘帖
支持！
反对！
