【需求管理】讲一讲IPD研发模式下需求管理的核心要素

今天给大家分享一下IPD产品研发管理过程中关于需求管理的几个核心要点。

需求管理的几个基本阶段

我们一般把需求管理分成五个阶段，分别是：收集、分析、分发、实现、验证。其中

• 收集指需要收集内部及外部的高价值需求
• 分析则是需要将需求进行解释、过滤、分类、排序
• 分发是需要将需求拆分为SP/BP、charter、路标一集再研版本
• 实现是需要实现需求，并进行需求跟踪以及变更控制
• 验证则是需要验证需求的实现是否可以满足预期

关于需求管理的组织结构

• C-RMT:OR业务管理体系中最高决策团队，接受C-PMT的领导，代表C-PMT执行公司级的需求管理职能；

• PL-RMT:接受PL-PMT的领导，代表PL-PMT产品线级需求管理职能，协调跨产品线的需求管理；

• PL-RAT:按产品线下子产品或者台灯领域设定，负责具体的需求处理，分析，分发，跟踪，验证；

• PL-MQA：产品线需求质量监督，负责对需求管理活动质量进行度量和审计

   

需求争议如何处理？

当我们的需求在评审过程中遇到争议时，我们推荐3层决策通道，采用分层级决策机制

需求变更如何处理？

原则：

• 变更链上任何一处变更，都要知会变更链其他环节
• 需求变更处理机制与需求接纳机制一样，如果需求变更发起时间处于某个具体版本的PDCP之后，其决策过程按PCR进行

• PDCP：Plan Decision Checkpoint 计划决策评审点
• PCR：Project Change Request 项目变更申请

关于需求质量管理

• 需求验证是一个内部活动；

• 需求确认需要客户的参与；

• 与客户交流我司的解决方案，确保双方理解无遗漏，无偏差；

• 不是所有需求都需要确认；

• PDCP前至少要做一次需求确认。

   

销售项目的需求管理

三个必须

• 需求首先由总部RMT给出答复之后，一线对外才能承诺
• 需求必须记录备案
• 合同签署前对需求进行评审

四点注意

• 生成CCL清单（CCL: Customer Commitment Letter 客户承诺信）
• 一线不能擅自承诺
• PDT不能擅自接纳需求（PDT：Product development Team 产品开发团队）
• 以《可销售产品版本清单》为基础进行答复