————– 生存情境 ——————

如何去提出问题？

明确价值

需要是什么？

需要剖析：了解客户、转化为产品需要、评估需要价值的过程

需要治理的过程

需要类型

需要起源（4 大角度）

客户：

• 访谈
• 问卷调查
• 问题反馈
• 销售转述

• 投标文件

  老板：

• 随口说
• 散会布置任务

• 来自某一篇文章报道

  竞品：

• 竞品调研

• 行业扫描

  数据 & 剖析：

• 异样数据
• 问题揣测

• 逻辑揣测

  需要收集

  ——– 需要收集办法 ————
  

需要收集规范 (价值判断)

需要收集节奏

需要收集阻碍

寻找要害角色

确定需要优先级

ICE 办法

影响范畴

自信水平

估算办法

实现难度

表格统计：

需要剖析

拿到需要做什么呢？（四个思考）

1. 收到的需要都是正当的吗？
2. 客户说的需要是实在的吗？
3. 竞品做得性能是先进的吗？

4. 老板说的是对的吗？

   需要了解（需要四因素）

   需要了解：客户（三种身份）

   需要了解：场景

   针对特定的场景下，问题能力有意义（具体产生问题的工夫地点人物）

   需要分析方法

   背景与冀望

   需要剖析产出物

   
   

需要确认

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

需要评审

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

需要评审通常被问到的六个问题

1. 感觉这个性能没什么用啊，咱们为什么要做？
2. 你这个方案设计得不合理，应该这样这样设计。
3. 你设计的时候有没有思考过 XXX 的状况？
4. 你的需要不够残缺，缺了很多货色。
5. 这个需要改变太大了，真的要改吗？
6. 你这个需要又改回去了，那你们过后为什么要改呢？
   针对评审问题：http://www.woshipm.com/pmd/51…
   如何不把评审开成讨论会：http://www.woshipm.com/pmd/74…

需要跟踪

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

变更管制

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

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

需要库的利用 (EXCEL)

需要库外围操作

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

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

需要库搭建准则

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

需要创立

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

需要保护 (保护准则)

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

数据报表

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

需要管理中心呈现的意外

需要终止

需要颠覆

需要级别的颠覆

如何应答需要歧义

需要治理困惑

需要治理变动