产品经理的价值输出：需求分析.docVIP

产品经理的价值输出：需求分析 / 调研时，产品经理常常会看到一个两极分化的现象，对于没有软件基础的用户： 要么对软件有不切实际的想法，夸大软件能做的事，张口人工智能，闭口自动识别； 要么显得过于小心翼翼，不了解软件到底能解决自己的哪些日常工作，不敢说出合理需求。 那么用户提的需求，软件会做哪些呢？这是所有用户最关心的问题啦。 上一篇文章《 2B产品的需求调研，还真不是人人都是产品经理》，我们讲了如何做需求调研。这个环节最关键的成功要素是：深入理解客户和用户的真实需求。 今天进入产品设计的第三个环节：需求分析。 我们从产品经理的本职岗位，来聊聊用户需求是如何转化为产品需求的？ 这个环节的成功要素是：将需求调研的内容转化为可被开发与验证的产品雏形。 下面我们看看一个需求分析的大致步骤： 一、识别出有效的需求 在需求调研中，一般会出现3种情况： 用户没有说清楚需求 产品经理没有理解用户的需求 用户忽略了真正的需求，一直在谈自己的解决方案，把产品经理带沟里了 注意：第3种情况都特别常见，我每次和不同的用户沟通时，他们都喜欢教我怎么做产品（噼里啪啦讲一堆他希望软件有什么？）。我常听着听着，就忍不住打断他们，让他们停一下，先回答我下面3个问题： 你实际上遇到了什么问题？ 这个问题出现的频率怎么样？ 解决这个问题能为你带来了什么帮助/价值？ 俞军提醒产品经理：我们要听用户说，但不要完全按照用户说的去做。 那么如何识别出有效的需求呢？ 我们可以把用户需求转化成用户故事的常用句式：我是“某种用户类型”，我希望“做某件事情”，从而使我“得到某种期望的收益”。 举个栗子：我是一个HR，我希望系统每个月能自动计算出所有人员的薪资，从而使我提高薪资计算效率（PS:我们的薪资有明确的计算规则）。 注意看上面这段描述，没有任何关于如何计算薪资的细节描述，但讲清楚了用户是谁？要达到什么目的？做这件事有什么价值？ 当一个需求能用上面的用户故事句式来讲清楚后，我们再深入了解具体业务流程、业务规则、数据流等，这才有意义。 当产品经理开始关注每个需求的ROI（投入产品比）时，就会谨慎对待用户提出的每个需求。 二、用户需求转化为产品需求 1. 将业务流程图转化为产品功能流程图 在需求调研阶段，我们根据业务需求描述绘制了业务流程图，这便于我们直观地理解业务流。 现在产品经理需要把业务流程图再转化为功能流程图。PS:功能流程图指的是未来产品上一个个实际的功能。 以上面的用户故事为例：我是一个HR，我希望系统每个月能自动计算出所有人员的薪资，从而使我提高薪资计算效率。我们只考虑其中固定工资的计算，产品的功能流程图如下： 我们讲解下上面的功能流程图，是如何计算人员的固定工资： 首先要有人员基本信息（工号、姓名、身份证、手机号、职级等），职级对应工资表（每个职级对应的基本工资、交通补贴、通信补贴、住宿补贴等）、人员的出勤记录（每个人员本月的出勤天数）； 其次根据上述3个功能，我们可以获取计算每个人员固定工资的必备信息，比如：姓名张三，职级M2,基本工资5000，各类补贴合计1000，本月出勤天数20（满勤按22.5天）。工资计算，张三的本月固定薪资=基本工资5000*出勤天数20/满勤天数22.5+补贴合计1000。 最后有固定工资表用来存放工资计算后的数据结果，便于查询。 每一个用户故事，对应到软件产品，可能由多个功能（矩形代表功能，箭头代表功能操作顺序）来组成。 2. 将业务规则转化为二维表、状态图 需求调研阶段，用户向我们描述了一堆的管理规章制度，那么这些信息怎么样结构化地转化为更直观的需求分析呢？ 以运费计算为例：运费模板中包含包邮条件、默认地区运费规则、指定地区运费规则。 功能页面如下： 我特意制作了下面的二维表作为测试用例，辅助用户测试。 上面的二维表穷举了不同订单下（当收货地址、订单金额、重量不同时），运费的计算规则，避免用户测试时有遗漏。 再以一个订单状态为例：电商订单一般有待付款、待发货、待收货、已完成、退款中、已退款、已关闭这些状态。我们以一个简易的状态图来表示 上面的状态图，描述了不同状态之间是如何变化的？A状态（待付款）当遇到某个事件发生（买家付款成功）则变为B状态（待发货）。通过状态图来理解订单的不同状态，会让读者有种一图胜千言的感觉. 三、小结 上面我们煞费了一番苦工，终于把用户需求的调研内容，转化成了更便于软件方项目组成员理解的产品雏形。现在拿着这些设计半成品，产品经理就可以更好地进入下一步的原型设计了。 产品经理们看着上面一个个的图、表，应该有一番成就感。这些才是我们作为产品经理，提供的实实在在的产出物啊。 如果没有这上面一番的需求分析，直接进入页面级的原型设计，极易陷入拣了芝麻丢了西瓜的境地。小白们，切记切记~