敏不敏捷都要做好需求管理

项目出现问题，往往根因在项目管理的宏观层面，而非具体实施的子过程，更与小团队的敏捷实践扯不上关系。对于产品研发团队，往往问题出在需求管理的失控。对于大规模项目来言，需求管理是第一要务。

根据DP哥的观察，互联网公司的项目失败率很高，经常会发生以下情况，令人痛心。

1）大量的研发工作量未能产生价值，上线的功能甚至从未被启用。

2）研发过程中出现大量的返工

3）因论证不严谨导致的返工，被以“试错”的名义给蒙混过去了

4）产生了大量的沉没成本，无人买单，不了了之

5）带给产品研发伙伴很大的挫败感

针对互联网的大规模研发项目，分享下DP哥的思路。从专业性上来说，毫不怀疑专业产品研发伙伴的纵向专业能力，但是大部分人没有经过项目管理的横向训练，在需求调研评估、干系人分析、对上沟通管理方面没能做到位，往往会导致需求质量比较差，从而导致大量返工和发布了伪需求。

需求工程通常会包括：

需求挖掘与引导、真伪与确定性评估、优先级评估、需求拆解与迭代计划、需求更新与变更、需求验证与反馈

常被忽视而影响巨大的问题：

1)缺乏业务专家、或者客户抽象不出合理的需求

2)需求来自于中间人，而非终端用户，导致需求变形

4)业务对接人不是决策人

5)项目团队承诺的过多，使业务方产生错觉，导致整体节奏混乱

6)项目投入很久才进行阶段性成果反馈

需求工程管理是个技术活，项目管理者的正确姿势：

1)务必具备引导能力，能引导业务方提供出靠谱的需求，并且实现理解一致

2)务必将业务专家引入项目

3)务必把能够解决立场冲突的决策者引入项目

4)务必提高交付速度、增加反馈频率，及时纠偏

5)务必营造“透明”的环境，形成统一节奏

6)采取敏捷的思路，避免采用大瀑布模型

敏捷实践中，“Review会”和“回顾会”能够验证一些需求的问题，但是绝对不能容忍将草率的需求强压给敏捷团队，而最终以“试错”的名义蒙混过关。