产品管理-互联网产品（2）：需求管理

一、概述

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

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%可靠”，“使所有用户满意”，“可针对未来所有情况升级”

【需求项管理】

需求项管理