分析报告指出，多达76%的项目失败是因为差劲的需求管理，这个是项目失败的最主要原因，比技术、进度失控或者混乱的变更管理还要关键。
很多PMO和PM却没有把需求管理重视起来，甚至认为这只是产品经理的事情，自己只做交付即可，俗话说：好的开始是成功的一半，一开始就没有管理好，注定为后续埋下了很多坑。
项目的全生命周期绝对不是到了需求给你才是项目管理的开始，越往前参与越深，你的价值就越大。
项目管理的最终目的是在各种约束下实现项目目标。必须对项目全周期端到端进行管理，你不知道需求是如何来的，也不知道如何进行需求管理，何谈促进项目成功，给组织创造价值？
咱们本周二前沿圆桌会议邀请了吴炳彬老师为大家分享《项目管理从需求管理开始》给大家带来不一样的启发和收获，需要查看分享视频的可以在B站上搜PMO前沿即可，每周二前沿圆桌为大家整理放到上面了。
另：咱们以前也分享过需求管理的文章，供大家参考：
项目经理如何做好需求管理和分析？
一图掌握如何做好需求管理和需求评审？
项目经理如何更好的理清和管理项目需求？
PMO和项目经理如何建立需求管理方案？
为什么聚焦需求开始进行项目管理？
项目/需求分类：
1.互联网项目：
大需求-中需求-小需求
重点落地场景：战役
2.TOB交付项目：
项目集-大项目-子项目-交付需求/产研需求
重点落地场景：大项目集/战略项目
3.日常：
小需求，日常迭代\bugfix
交付项目/大需求立项：
1.需求立项
-在互联网项目，大需求即大项目，大需求可能会成长为技术域 or 产品模块 or 产品：
管理过程：BRD-MRD-PRD-设计稿-开发特性-交付发布-运维/运营
-在toB交付项目，为合同交付，有更加规范的项目
管理过程：甲方立项-合同前立项-乙方售前-乙方招投标-签订合同-乙方项目立项-发布项目章程-项目过程管理-项目交付验收-项目运维运营。
归总==>圈资源(人力资源、成本资源、采购资源)、确认里程碑、确认范围、确认验收标准；过程补充沟通管理、风险管理、变更管理。。。。and so on。
小需求管理
2.互联网 or 内部产研场景 or 交付项目转产研交付，需求不一定立项（小需求、临时代码变更）。此时技术中心或中台承接各业务方需求，业务形态不一，管理工具和管理方法、对接习惯都不一样？出现什么问题？
解决办法：
--代码发布收口，有需求才能发变更，就如有项目编号后才能挂出差报销
--简化抽象需求环节，抓大放小，抓承接人、排期人，模糊开发&测试节点，保最终上线时间（但会提供建议指标，开发团队内部自洽管理）
--主子需求关联，需求打标。
需求过程抽象
第一次初始化：
原始需求提交前：业务论证、BRD、MRD一个不少==>承接就是点击承接==>分解需求PRD==>技术方案拆解、评审，测试共同参与==>开发代码、开发mock自测通过、发布测试环境、单测通过、集成联调测试通过、发布预发环境、预发环境集成联调测试通过==>发布灰度、正式环境灰度100%==>业务确认需求验收==>转技术支持运维及业务运营；
需求过程抽象-变更需求补充
需求变更与项目过程双轨运行
业务判断过程
TOB交付内容，走需求变更流程：
PD/销售/PM确认是否合同内/是否项目章程包含==>是否新增补签合同==>是否有需求置换 or 其他利益交换==>PM调整项目各类计划，PD原始需求新增子需求，标签为变更需求。
产研需求变更，走内部需求变更流程：
PM/PD/TM内部自洽，评估对业务/客户影响，盘点风险/交付周期/质量，工具也走原始需求新增子需求，标签为变更需求。
需求创建
需求承接
需求分解
技术方案/开发排期
开发
发布
需求数->承接数->交付数->需求平均交付时长->收益&基础能力建设->影响力。
大盘指标：
需求平均交付时长、参与需求总人数、需求平均每日开发人员参与数量、完成进度、累计天数、机器成本投入费用。
需求指标：
子需求列表&需求交付时长明细（状态、当前节点、每日开发参与数量、参与需求总人数、累计天数）。
环境指标：
发布前置时间、系统构建速度、代码入库前检查通过率、SIT环境部署时间、部署失败最久时长、上线成功率。
质量指标：
自动化数据累计（总用例数、接口用例数、链路用例数）、bug标签分布（域、团队、人、严重程度、优先级）、缺陷趋势、缺陷修复时长分布（域、团队、人、严重程度、优先级）。
团队指标：
对个人：缺陷数（原始、reopen、轻缺陷）、需求数、平均需求交付时长、自动化发现bug占比、提测成功率；
对团队：交付吞吐率；
组织大盘：
预算成本、预算收入、预算损益、实际成本、实际收入、实际损益、重点需求投入人力占比、技术域投入分布。
满意度调研（咱们分享过相关的文章项目客户满意度调查问卷实例【附项目管理价值度量十大指标】）
对客户和团队做调研满意度
1.研发工程
2.研发效能
3.需求交付满意度
