这周让我们一起学习需求管理，需求管理是产品经理的核心能力，很多初入行的产品经理认为需求管理就是把用户需求收集过来，按照优先级排序提交PRD给研发的过程，这个过程其实更像需求的搬运工，忽略了需求分析以及在产品生命周期发展扮演的角色和地位，本周我们全面学习下作为产品经理应该如何认识、管理需求
一 认识需求
1.1 什么是需求
通常需求从个体角度出发被认为是用户需求，比如我希望能通过一款时间管理APP去管理我的工作、学习时间，减少不必要时间浪费；如果从群体角度出发往往分为企业需求和市场需求，通常企业需求是为了满足市场需求而存在，比如特斯拉公司希望开发一款续航能力超过1000公里蓄电池满足市场对于电动汽车续航能力要求，说到这里大家可以看到市场需求和用户需求关系：用户需求组成了某一特定的群体的市场需求，特斯拉希望通过开发1000公里蓄电池希望解决的那些想买特斯拉但是又担心充电续航能力不足人群顾虑，那么对于始终想买燃油汽车的用户来说，特斯拉是否研发1000公里的蓄电池似乎没那么重要，那么可以看出不同用户需求组成了不同群体的市场需求，企业就是为了满足不同群体市场需求而存在或者说研发产品，这也说明为什么一个企业、一个产品定位有多么重要，因为企业及其产品往往聚焦在某一个特定用户人群身上，延伸下思维：大家想想用户人群可以从哪些方面分类
总结下，需求定义：解决某一类用户或者群体需要、问题，这种需求和问题可能是精神层面、有可能是实际生活、或者实际工作需要的
思考题：你负责的产品聚焦到哪一类用户？他们有什么特征？竞争对手是否也具备同样的能力？
1.2 详解用户需求
在《人人都是产品经理》这部书中，用户需求定义：用户自以为的需求，并且经常表达为用户的解决方案，大家想想用户需求和解决方案等同吗？举个例子：‘我希望下班出地铁口时候能少走路就能到家‘这是用户需求，’我可以通过打车或者拼顺风车到家‘这是解决方案，但是现实中往往把用户需求和解决方案混淆，用户需求要素：什么对象，什么时/环境，做什么，达到什么效果，没错这就是我们常说的场景，用户需求往往和场景关联：既什么样用户在什么时间在什么地方/环境向实现什么目标？用户需求更多是WHAT；为了解决下班出地铁口时候能少走了就能到家这个用户需求，可以乘坐公共汽车，但是需要花时间等，可以拼车，但是不一定有合适拼单，费用似乎也有点贵，这个时候共享单车出现了，共享单车成立之初就是为了解决最后一公里到家、到学校需求，只需要很少押金，每次骑行花费只有一元钱解决想快点回家又不想等公交、不想花费太多的用户需求，所以共享单车是一种解决方案，它更多是通过产品或者产品功能解决HOW，所以用户需求不是解决方案。
互联网产品本质就是解决用户各种场景化需求，在不同的场景战场上抢用户、拼效能、比体验。
作业题：你所负责的产品解决哪些场景下的用户需求，如何评价解决的好与坏？
1.3 真需求和伪需求
我之前在做数据产品经理的时候，公司没有BI分析平台，面对运营、产品经理、数据分析人员各种数据需求，有的要明细数据，有的要TOP排名数据，有的要统计占比数据，当时基本上一股脑的做掉了，可事后想想好像少了什么，对！少了对需求分析，初入产品经理面对需求时候除了上述提到混淆用户需求和解决方案，也常常被伪需求迷惑，举一个极端例子：用户提出我想乘坐飞船去火星需求，那么是不是产品经理就要开始调研往返火星的条件比如飞船的大小、火箭的动力、火星的生存条件等等，经过数月调研发现如果实现往返火星需求大致造价十亿美金，需要1000名工程师耗时十年以上，可是作为产品经理我们是不是首先鉴别下用户这个需求真伪，为什么用户会提出向乘坐宇宙飞船区火星，答案可能是用户希望体验完全不一样的旅行，乘坐不一样的交通工具，去往不一样的目的地，至于是否乘坐火箭飞船，是否前往火星其实没有那么重要，最后为了满足用户需求的解决方案可能是乘坐热气球横跨太平洋。
需求真伪直接影响产品设计及发展方向，我们在回顾下之前我在做数据产品经理时候面对的需求：
明细数据需求：用户希望能导入EXCEL，通过数据透视功能多维度分析用户支付情况
TOP排名：用户希望指导首页下载推荐位和广告位中哪些应用下载量最多
统计占比：用户希望看到每日支付类型占比多数？
最后数据产品方案如下：
明细数据需求：我们通过KYLIN定义用户需要的维度和指标，通过托拉拽方式实现维度和指标组合
TOP排名：我们给用户建立每日下载DATABORD，每日监测首页不同位置下载情况
统计占比：我们构建关于支付主题的报表，包括支付请求率、支付成功率、支付类型等主题分析
如何辨别需求真伪，通常可以从以下几个因素分析：
使用频率：用户是否会经常使用？想乘坐火箭飞船登录火星这种需求其实发生频率极低，比如音乐播放中单曲播放以及QQ用户分组就是高频率的需求
实现代价：乘坐火箭飞船登录火星代价是十亿美金，1000名工程师参与，最终用户可能只有几百名，即便最后实现了这样飞船，解决了火星生存条件，这样一张船票可能会是天价。通常需求实现代价需要考虑人力成本、技术预研（解决新的需求），开发成本（主要是时间）
可复用性：登录火星飞船使用火箭一次性，这种复用性就是0，产品经理需要考虑用户需求是否在其他在其他相似场景也会出现？
可持续性：登录火星需求很可能持续很短，因为愿意花费天价、并且往返时间可能超过一年用户少之又少，这样用户不太可能随着时间推移有较大规模的增长
实现效果：互联网产品实现效果其实本质就两个收益和用户量，实现某一个新的需求能带来多少用户增长，实现多少收益（或者提升收益转换）
作业题：从上述角度分析你现有产品需求真伪性
1.3 功能和需求关系
产品经理谈需求离不开功能，那么功能和需求是什么关系？功能是产品客观存在比如登录功能、手机支付功能，朋友圈转发功能，二维码扫描开锁功能，用户使用与否，功能都是客观存在的，但是功能通常为了解决用户需求而存在，所以离开用户需求功能大多无用功能，试想没有用户使用的功能有何意义呢？用户通常会把功能和需求混淆比如：我需要人脸识别功能，我需要多目标追踪和定位功能，产品经理对用户谈需求，设计产品谈功能，所以遇到类似用户这样诉求，按照需求定义试问：通过人脸识别解决什么？达到什么效果？用户回答是通过人脸识别实现手机安全验证，通过人脸识别实现自动化门锁解禁，通过人脸识别实现最烦快速匹配等等，在上述各种用户场景中使用技术以及产品功能可能有比较大差异，所以产品经理区分功能和需求，那么如何将产品需求转化为功能，我个人常用两种工具：
E-R图：
E-R图是对现实世界的抽象，通过E-R图实现对现实世界概念模型建立，包括实体，关系，属性
实体：用于描述现实世界的数据对象，用方括号表示，比如人、动物、车
属性：客观描述对象的属性，比如人属性有性别、年龄、身高、职业、爱好
关系：描述对象和对象之间的联系，用菱形表示，联系存在3种一般性约束：一对一约束、一对多约束和多对多约束
以下是一个用户购买商品并且产生订单ER示例图：
UML图：
鉴于UML较为复杂，单独开一章节写这个
二 管理需求
2.1 需求来源获取
用户访谈：基本没有用过，个人认为效率比较低下
问卷调查：采用问题方式，通过封闭的回答调研用户集中关注点
头脑风暴：用的比较少的方式，通过不同观点迸发一些不一样观点
竞争对手调研：用的比较多的方式，通常对竞争对手调研及功能学习，成为产品改进的重要途径
2.2 需求管理
需求获取以后，要对需求进行初步加工，这是将用户需求转化为产品需求第一步，EXCEL方式将需求以列表方式输出需求详情描述比如来自用户群体、实现的商业价值、优先级等，以下是我早些年做传统IT需求分类示例：
2.3 需求分析
需求收集以后，需要将需求进行分析，这是将需求转换为产品功能第二部，常见的需求分析方法如下：
黄金圈思维法则
黄金圈思维法则是一种底层的知识规律，也是我个人非常推崇的分析问题的方法，我单独写一个认知系列的文章提到如何发现底层知识规律，并且运用，黄金圈思维法则的核心遇到一个问题首先不是想这个问题解决策略还是考虑问题本质，就是WHY层面，为什么用户会有这个需求？产生这个用户核心需求的背景是什么？
我们看早些年诺基亚广告：科技以人为本，诺基亚通过这则广告语向用户传递诺基亚并非一个手机公司，而是一家科技公司，并且以用户为本，满足用户服务用户为宗旨，早些年诺基亚造出形状各异的手机，都会有人买单，因为对于消费者而言传递价值不只是手机功能而是诺基亚的科技服务理念，科技以人为本就是诺基亚制造、营销手机的WHY，但是很可惜诺基亚最终败给了自己。
现实中我们往往迷惑于WHAT层面--用户需要一个可以登录火星的飞船，可是用户WHY层面--猎奇体验，通过黄金圈法则更容易让产品经理认识用户需求产生的核心原因和背景，理解不同使用场景的用户诉求。产品经理构件产品战略的过程其实就是不断将WHY--WHAT--HOW的过程，本质是开放问题到封闭问题：反复的推演、求证。
KANO模型
KANO模型从满足和满意度两个维度把需求划分为基本型需求、期望型需求和兴奋型需求三大类:
基本型需求：顾客认为产品“必须有”的属性或功能。当其特性不充足时，顾客很不满意；当其特性充足时，对客户满意度没有多少影响，顾客充其量是满意。比如我们在电商购买商品时候，必须先注册后才能购买，注册功能就是满足基本型需求而存在，没有注册功能，严重影响用户购买
期望型需求：要求提供的产品或服务比较优秀，但并不是“必须”的产品属性，有些期望型需求连顾客都不太清楚，但是是他们却希望得到 的。顾客通常谈论的是期望型需求，期望型需求又叫做线性需求，这类需求越多越好。线性需求在产品中实现的越多，顾客就越满意，当没有满意这些需求时，顾客 就不满意。因此，产品的价格通常和线性特性相关。用户在电商平台选择购买商品时候不仅希望通过信用卡、借记卡、也希望通过支付宝、微信等第三方支付，额外的支付类型就是满足期望型存在。
兴奋型需求：提供给顾客一些完全出乎意料的产品属性，使顾客产生惊喜。兴奋点和惊喜点常常是一些未被用户了解的需求，客户在看到这 些功能之前并不知道自己需要它们。当其特性不充足时，并且是无关紧要的特性，则顾客无所谓，当产品提供了这类需求中的服务时，顾客就会对产品非常满意，从 而提高顾客的忠诚度。这类需求可以为产品增加额外价格。比如苹果的键盘、鼠标、Apple Pencil这些都是满足兴奋型需求存在
作业题：目前你负责的产品哪些功能是满足基本型需求、哪些满足期望型需求
由图可以看出，
右下方箭头：一旦实现了一定数量的必须功能，就无法再通过增加这类功能来提高客户的满意度了。无论增加多少必须功能，客户满意度都不会超过中点以上。
左上方箭头：只是实现一部分兴奋点就可以明显的提升客户满意度，这也是为什么企业把追求卓越作为企业的价值观之一
中间的箭头：期望型功能的增加和客户满意度呈线性增长，所以这类需求越多越好
通过以上分析，我们会对这三类需求分别对待：
对于必须完成的功能，在产品发布时需要完成，但并不是要求在第一次迭代时就开发完成。
完成尽可能多的线性需求
如果时间允许，至少应该确定少量的兴奋点优先级，把它们包含进发布计划
生命周期法
几年前，有一个来自优酷产品总监给我们培训时，列举了当时微信第一个版本所涉及功能比如：通过手机号注册、通过邮箱注册、支持文字形式发朋友圈，支持视频通话、支持通讯录导入、支持语音通话、支持文字对话、通过QQ关联登录等等，要求我们挑选出微信实际第一个版本开发的功能，当时印象中没有一个人准确或者接近正确答案，为什么没有人选中接近问题答案，后来我总结了两个重要原因：
产品经理倾向设计一个功能完善的产品思维
不清楚目前产品所处的生命周期位置
回到微信第一个版本如何选择功能问题上，微信第一个版本处于产品成长期，成长期运营特点需要大量获客，产品特点是需要1-2个核心的功能解决用户痛点，让用户认同，那么用户核心痛点是什么？微信最初定位建立熟悉朋友的社交平台，这里面有两个关键字一个是熟悉朋友，第二就是社交，微信第一个版本就是解决熟悉朋友联系，最便捷方式就是通讯录导入，通过熟人之间通讯录导入很快达到获客效果；社交最常用的就是文字对话和语音通话，考虑实现难度和代价，最终语音对话可能不是第一个版本必需功能，而选择文字录入、表情、图片等功能则能快速实现社交目标。
作业题：你负责产品目前处在哪个生命周期，对应核心功能有哪些？
2.4 PRD撰写
产品经理另外一项核心技能就是PRD撰写，这是用户需求转化为产品功能第三步,也是向研发同学交接最重要一个环节，PRD核心就是撰写开发同学可以理解并且参考的功能或者流程说明，PRD没有固定格式，详细PRD包括项目背景、项目目标、功能详情说明、非功能详情说明等
项目背景：描述开发产品或者项目必要性，可以从用户需求、市场需求、竞争对手等方面描述
项目目标：描述项目或者产品开发的意义以及实现目标，带来什么样收入以及用户增长
功能详情说明：描述产品实现业务逻辑以及参与系统各个角色职责、权限和前后置依赖关系等
非功能详情说明：产品性能说明、埋点说明、报表需求等
功能详情说明中通过用例对功能说明，而用例则是对需求可视化表示，之前提到ER、UML都是可视化建模语言，常用的UML有用例图、类图、状态图
以下对UML常见用例图进行说明：
用例图是UML建模的一部分，也是UML里面最基础的部分，最主要的功能就是用来表达系统的功能性需求或行为。用例图是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统，是尾部参与者所能观察到的系统功能模型图，该图呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模，用画图的方法来完成。用例图展示了用例之间以及用例与参与者之间是怎样相互联系的。
用例图包含留个元素：参与者、用例、关联关系、包含关系、扩展关系、泛化关系。
参与者（Actor）：系统外部的一个实体，参与用例执行过程，通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者的种类概括为三种：系统用户、与所建造的系统交互的其他系统以及一些可以运行的进程。注意：参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物；每个参与者需要一个具有业务一样的名字；一个人或事物在与系统交互时，可以同时或不同时扮演多个角色。
用例（Use Case）：用例是对一个活动者使用系统的一项功能是所进行的交互过程的一个文字描述序列，是系统、子系统或类和尾部参与者交互动作序列的说明，包括可选的动作徐磊嗯哼会出现异常的动作序列。用例是岱庙系统各种各个项目相关人员之间就系统的行为所达成的契约，软件开发过程是用例驱动的。用例粒度（规模大小）。
关联关系（Association）：表示参与者用例之间进行通信
包含关系（Include）：客户用例可以简单地包含提供者用例具有的行为，并把他所包含的用例行为作为自身行为的一部分。调用用例执行到包含点，然后执行传递给被调用用例，当被调用用例完成时，控制在次返回调用用例。
扩展关系（Extend）：扩展用例被定义为基础用例的增量扩展，扩展关系指的是一个用例可以增强另一个用例的行为，提供了一个离散的行为，可以将自己添加到基础用例作用，表示的箭头从扩展用例指向执行用例。使用扩展可以使我们在不改变基础用例的同事，根据需要自由的往系统中添加行为
泛化关系（Generalization）：代表一般与特殊的关系，与继承类似。在泛化关系中，子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或覆盖父用例中的行为和含义。
一个用例图示例：
用例说明
详细用例说明包括模块描述、功能描述、需求说明、优先级等：
以微信登录示例文档描述：
针对一个用例详细说明，通常需有UI图，以下是我之前做的一个H5流量积分领取的UI:
如果要对UI图进行说明，可以参考《人人都是产品经理》P133页面UC模板部分
产品功能往往实现功能是动态、可交互的，那么UI完整实现交互流程，可以通过墨刀工具实现动态交互，甚至可以下载APK包达到高保真效果。研发同学比较喜欢整体功能交互，如下图：
至此一个相对完整的PRD就告一段落，刚从业产品经理针对上述内容多加练习，参考微信、QQ或者其他的APP练习交互原型以及功能用例，我也期待你们上传分享自己的作品
2.6 需求评审
UI评审：技术同学、运营同学、BD同学会对整体UI进行评审，针对UI或者流程不合理地方进行修改和建议
需求评审：通常面向研发人员，经过探讨后会发现PRD中各种瑕疵或者缺陷，极有可能造成需求评审不通过返工结果，所以在正式需求评审前不妨和产品内部同事多交流，听听产品同学建议。
测试评审：测试同学参与，主要明确待测试功能用例或者性能要求以便更好完成测试，通常业务逻辑较为复杂时候产品经理需要和测试同学一起制定测试策略和方案
2.7 需求验收
需求评审通过后，会进入项目开发排期，开发完成后，会经过测试同学测试验证，不可避免发现BUG和需求设计不合理问题，产品经理保持时刻跟踪，bug在全部CLOSED后产品进入验收阶段。在正式上线之前，需要产品经理签收《产品发布确认单》，《产品发布确认单》包括：
研发意见：数据库环境/产品版本/数据准确性
产品意见：产品功能完整/产品性能达到要求/UI是否一致
运营意见：内容与功能满足运营需求
注：其他交付物：《产品测试清单》 《遗留问题》 《产品使用说明》
