关于产品经理:如何进行B端产品需求分析管理

需要治理过程

需要收集

1. 通过合成人, 事两大要害事项, 与关键人物沟通, 推动需要收集
2. 通过沟通和会议伎俩来会集需要

需要确认

1. 对曾经剖析实现的需要, 与需要发起人活着部门进行再次确认;
2. 再次确认分为 2 个局部, 别离是确认需要而的根源和确认需要在技术上最终出现的性能
3. 确认后的需要将进入下一个环节

需要评审

1. 与技术团队评审需要, 并输入整体大抵的开发周期, 投入资源;
2. 向需求方汇报需要的可行性, 开发周期的投入资源, 共事确认需要的业务逻辑是否合乎原始需要的初衷

需要跟踪

1. 对曾经确认完, 评审通过的需要时刻放弃跟进状态
2. 跟进需要在业务层面的变动和改良; 如业务产生了本质行变动
3. 跟进需要在技术执行落地层面上的变动; 如技术实现遇到了阻碍

变更管制

更变发动 -> 变更评估 -> 需要剖析 -> 技术评估 -> 需要确认 -> 跟边产品计划 -> 变更技术计划 -> 变更我的项目工夫和资源投入

 1. 当需要产生变更的时候, 必须要发动变更启动变更管制流程
 2. 变更发动后, 须要对变更进行评估, 以判断是否须要进行变更;
 3. 若进行变更则须要从新对需要进行剖析, 技术评估, 调整产品, 技术计划, 和我的项目工夫以及投入资源

需要库的利用 (EXCEL)

需要库外围操作

入库 ———————————–> 查问 ————————————> 更变

 规范模板;                       关键词查问;                   变更须要保留历史版本;
信息准确无误;                  工夫, 需要人, 需要部门查问;       变更须要减少变更工夫
信息全面;                      状态, 级别查问;                  和变更起因;

需要库搭建准则

1. 借助市面上现成的需要管理系统
2. 借助在线协调办公表格
3. 产品经理创立. 保护
4. 外部团队信息共享, 可协同工作
5. 信息安全高, 防止数据损坏或者失落

需要创立

1. 根据模板填写
2. 依据理论状况对模板进行变更
3. 需要要写分明需要类别, 需要形容
4. 定期向我的项目团队同步新增需要

需要保护 (保护准则)

1. 需要产生变更时
2. 业务产生变更时
3. 提出人产生变更时
4. 开发时遇到的技术瓶颈须要批改计划和周期时
5. 应需要产生变更, 业务产生变更以及技术瓶颈造成的计划变更;

数据报表

1. 用来在我的项目完结时做总结剖析
2. 通过对需要的不同状态进行剖析, 出现我的项目过程中需要的治理过程
3. 通过数据图标体系产品经理在需要阶段的外围价值

需要管理中心呈现的意外

需要终止

需要颠覆

需要级别的颠覆

如何应答需要歧义

需要治理困惑

需要治理变动