需求分析（工作场景）

--------------生活情境------------------

如何去提出问题？

明确价值

--------------需求是什么？---------------

需求分析：理解客户、转化为产品需求、评估需求价值的过程

需求管理的过程

需求类型

需求来源（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. 通过数据图标体系产品经理在需求阶段的核心价值

需求管理中心出现的意外

需求终止

需求推翻

需求级别的推翻

如何应对需求歧义

需求管理困惑

需求管理变化