一、概述

需求=问题+解决方案，产品经理是解决问题专家。提出求产品经理需要考虑如下四点：

• 1、客户的目的是什么？
• 2、这条需求是否隐含了解决方案？
• 3、客户的潜在目标是什么？
• 4、如何确定需求已得到满足？

二、需求合格评定标准

【举例】
比如：客户希望打开网站时会弹出一个需求手动关注的盖屏广告。该需求用户的目的是：“增加广告位、用户强制性看得到”。但提出的需求很不合理，产品经理需要和团队及时反馈（前端、设计、研发）理清方案。
修改需求为：打开网页时，弹出一个半遮屏的网页，1/4为遮屏其他为网站内容，出现五秒钟之后自动收回。好处1、用户看不到网站内容造成体验很差；2、无需用户手工关闭

需求合格评定标准

• 1、定义用户类型（移动用户打开客户端后）
• 2、动用（展示广告位）
• 3、时间需求（2秒后广告页逐渐消失）
• 4、显示客户端首页（定义结果）
• 5、能同时满意100万用户的访问（性能要求）

测试人员可根据相面的需求点，来判断是否能够验证该条需求。测试点包括“移动端用户”、“打开客户端”、“展示广告页"、“2秒”、“逐渐消失”、“显示内容”、“并发量100万”

三、产品SMART原则

该原则来自于目标管理，既然每一个需求都是一个独立的目标，那么借用该原则对需求进行管控是非常合适的。

• 1、S（Specific，明确性）
• 2、M（Measurable，可衡量）
• 3、A（Attainable，可实现）
• 4、R（Relevant，相关性）
• 5、T（Time-bound，时限性）

四、产品理论依据

马斯洛关于人类需求层次分为5个层次，分别是：生理需求、安全需求、社交需求、尊重需求和自我实现需求。如下图：

马斯洛理论与产品

• 生理
  呼吸、水、食物、睡眠、繁殖...等等所有维持你“活着”的基本物料需求。
  思考：如何进行产品中“依食住行”规划？产品的基础功能可以满足用户的基础需求么？

• 安全需求
  人身安全、健康保障、资源所有性、道德保障、家庭安全
  思考：“人肉“是一个可怕的词，你的产品是否能让用户放心使用？你又是通过什么方式让用户信赖你的产品的安全性、如何给用户带去安全感？

• 社交
  友情、爱情、性亲密
  思考：用户对你产品的情感、用户与用户之间的情感。情感上的需要比生理需要更直接，因为它是细腻的、暧昧的、多变的、充满希望的。“情感是人对客观事务是否满足自己需要而产生的态度体验“。为什么陌陌能生存下来？

• 尊重
  自我尊重、信心、成就感、对他人尊重、被他们尊重。
  思考：如何让用户在使用产品时获得成就感？想想那些被游戏的排名或者成就感的勋章，你的产品需要么？你尊重用户，用户才会尊重你，再而才会使用你的产品。让你的产品带给用户信心和礼貌、尊重与成就。

• 自我实现
  道德、自觉性、创造力、问题解决能力、公正度、接受现实的能力。
  思考：如何让用户在你的产品中做自己。还记得那年在等待游戏开局时，被“XX蓝钻会员踢出房间“的惨痛经历么？RPG类游就是很好的例子。在那里”杀人“，”救人”，每个玩家都实现了自己不同的主观面。

• 自我超越
  宗教、自我牺牲、奉献、超我
  思考：提供给用户一个自我奉献的平台。将用户助人为乐、乐善好施等正能量，通过你的产品、需求，正确的引导出来，部分用户不再是“为我”，而是“利他”。不能说“1024”是个好例子，但实际是确定超出了。

• X理论
  人比较懒惰，需要督促的。
  即用于绩效管理中，认为员工是懒惰的。在产品需求中，我们认为用户是懒惰的。

• Y理论
  Y认为人比较自觉，对应相对于自由、宽松的环境。人的层次较高。

• Z理论
  在自我实现价值上再次飞跃自我超越。

我们要根据产品定位与层次，选择不同的产品策略。

五、需求来源

1、内部需求

• 竞品分析
• 老板或领导
• 项目组
• 数据分析
• 交叉业务线

2、外部需求

• 用户
• 客户
• 媒体
• 合作伙伴
• 竞争对手

3、创造需求

• 自发
  注：只要有抱怨的地方就有需求

六、需求项列表

• 业务目标：该需求要达到什么效果，为什么要做
• 功能性需求：如果该需求为功能性需求，进行具体描述
• 使用场景：用户在何种场景中会涉及到该需求
• 业务规则：该需求逻辑是什么，有没有前置条件或其他触发条件
• 接口需求：接口有没有相关需求，接口提供以及联调
• 数据要求：哪些字段需要返回数据，返回数据需要怎么样的抓取频率
• 质量属性：该需求经测试后需要满足哪些质量规范要求
• 约束：该需求的上线对现有业务运营是否有影响，对性能有没有影响
  ......

七、需求识别

需求分类

【举例：广告位的需求识别分析】
客户张总提出在首页增加广告位置，这种运营驱动的需求，前台样式需要新增，后台也需要改造为可自助上传图片的，图片格式、大小、尺寸等需求请设计师进行规范，这个功能性需求因为牵扯到收入，虽然对产品而言并不重要，但优先级要最高。这是客户真需求，用户的伪需求。

【十六字真言】
去伪存真、去粗取精、由此及彼、由表及里

【按软件标准分类】

• 功能性需求
  系统（产品）必须能够实现的能力或能够完成的工作
  系统（产品）能够提供给用户连接蓝牙并打印照片的能力
  能够作为一个逻辑时序进行组织实现
• 非功能性需求
  必须为系统满足或接纳的潜在的条件
  约束补充了系统的质量但不会作为一个功能存在
  "系统（产品）能够同时处理200万个在线用户的请求“
  非功能需求作为一个重要的规则或条件进行组织和实现

八、软 件内外部质量模式

软件内外部质量模式

九、UML统一建模语言

UML，帮助我们做需求分析与需求设计

十、PRD

PRD，全称：Product Requirement Document，产品需求文档，将“概念”转化为“图”+“文字“+”原型“。
【PRD重要性】
1、召集令。有了需求文档才有组织说话的权利
2、沟通的基础。产品需求文档的根本价值，是让他们都明白你想要什么
3、灯塔的作用。“按图索骥“，总比”无迹可寻“要好得多
4、一项重要凭证。遇到客户扯皮时，最好的自我保护方法
5、杜绝需求蔓延、频繁变更。需求文档规定了本次需求的范围，防止客户对需求的变卦

【PRD怎么写】
1、套话。如需求是什么，为什么要做这个需求，做了有什么好处？
2、罗列。如名词解释、功能清单等
3、叙述。功能具体描述。包括业务流程（UML<前置条件等>）、UI、交互、数据、使用场景等等，这一步最重要，出流程图、原型图并加以文字具体表述，要注意符合Smart原则。
4、备注。如财务、性能、交叉风险、资源安排等等。

PRD模板（待续）

【需求文档的标准】
1、完整充份。本期迭代的所有需求尽量在一个文档里完成，避免落下某些细节需求。
2、无冲突无冗余。确定文档里的需求不产生冲突，相互不重复。
3、关联+结构。文档的整体要有结构层次，相关联的内容要写在一起。
4、验证测试。尽可能把描述的内容颗粒度把握的细一点，方便测试人员测试需求。

【需求文档的避免问题】
1、避免凌乱，必须简洁。
2、不可用的词语。“一般”，“通常”，“正常情况下”，“可能”，“应该”，“或许"...
3、不要把话说全。“100%可靠”，“使所有用户满意”，“可针对未来所有情况升级”

【需求项管理】

需求项管理

十一、重要程度

1、最简单的方式：排序高、中、低
2、最直观的方式：从重要性和紧急性来分析
3、影响优先级的因素：来自市场上的竞争对手、客户需求、创新想法、公司战略、开发的约束条件等。

重要程度拆分

判断优先级时，需要综合风险定性分析（有没有价值、风险有多大）和风险定量分析（需要多少成本代价）的结果。

十二、需求管理常见问题

需求管理常见问题列表

十三、伪需求

image.png

十四、需求变更

需求变更