盯住产品目标,做好需求分析的5个阶段

发表于:2018-1-30 13:39

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Hsm_Henry    来源:人人都是产品经理

分享:
  对于产品经理来说,需求来源可以分为两种,被动和主动。被动需求来自于不同用户角色,可能来自于公司的业务部门、产品、测试、公司老板、直属上司,和产品的使用者(Key_User)。在被动接收的需求里,有时候用户提出的需求很荒谬;有时候提出的需求很具体,具体到做一个什么样的界面,加一个什么功能按钮,实现什么逻辑;有时候却很模糊,用户完全无法表达清楚自己面对的困难在哪里,自己想要什么。主动需求则来自于产品经理通过自身对产品的理解、竞品分析、市场分析、产品运营报告等途径整理的需求。
  面对如此杂乱的需求,如何有逻辑、有顺序、完整性的梳理出需求?
  1. 需求梳理
  1.1 搭建自己的需求框架
  将杂乱无章的需求,作为一个个待解决的问题点,解决需求的过程实际上就是解决用户面临的问题。
  需求框架可以是产品最初的概念模型,可以是调研提纲,也可以是一段思路。作用是为了有次序、有逻辑、有条理的将所有需求串联起来。
  (1)需求分类
  搭建需求框架的第一步是要对收集的需求列表进行分类,我把产品经理收集的用户需求分为两类:业务需求、功能需求。
  · 业务需求:由业务提供方或者开展方(产品的使用者)提出的需求,需求点与业务流程、实际操作过程相关。
  · 功能需求:由用户提出需要一个什么样的功能,实现什么样的业务逻辑和计算逻辑;或者有用户期望有一个功能,能够完成一件事情,需求点与功能直接相关。
  (2)连接需求
  按照场景以及作业流程将分类后的需求连接起来。如下图表达的类似结构:
  当然,也可以通过思维导图来实现。连接需求时不一定要非常细,可能只是一个需求大类或者大方向,但是最好按照业务的发生顺序进行依次排列。
  2. 需求调研
  需求框架梳理结束后,产品经理需要深入到需求调研活动中去,重点是了解现状情况。了解有哪些人即哪些角色参与到现有的业务流程中,业务现状是怎样的,哪些线上做,哪些线下做,线上线下是如何衔接的,什么情况什么节点有哪些凭证,哪些业务单据,每一个单一的业务场景对应的操作子流程是怎样的,这些都是需求调研阶段需要了解的内容。
  常用的调研方法有以下几种:
  (1)问卷调查
  笔者认为问卷调查法在信息收集类的调研活动中是最能发挥优势的,可以免去跑现场、找用户等环节,就可以获取大量用户的有效信息。但一般在业务调研活动中,很少用到。
  (2)用户访谈
  与用户面对面交流,这种交流比较随意轻松,尤其对终端用户的心理压力小,可以简单直接的获取到用户的第一手需求。甚至有些用户会提出作业过程中真正的痛点和问题所在。交流内容会相对比较丰富,也是最耗时的。这种通过交流的调研方式,最主要的是要找到业务相关的关键用户(不一定是某个负责人、主管,但一定是现场的协调和操作者)。
  (3)参观
  工作中常常会遇到某个领导来莅临指导,某个同行来参观等等。参观也是调研活动中的一种。通过对管理方式、操作流程、作业效率等方面的观察和参观过程中与个别用户的简单交流,熟悉优与劣(参观一定是有参照物的)。
  (4)专题会
  专题会一般会在遇到重大问题或者方向、范围发生偏移或者不确定的时候,预先安排好会议时间、会议地点、通知所有参会人员参加专题讨论。
  2.1 前期调研
  第一阶段的调研会集中于对产品的目标、定位、范围的确定,该阶段多以专题会的形式展开调研,最终需要出具概要方案,信息流、资金流、物流之间的层次关系,系统内在活动关系等,每一阶段的产出物整理也属于需求梳理、不断完善需求框架的一部分。
  2.2 深度调研
  经过第一轮的调研,需求框架里无论是前期用户提出的需求(问题点)还是产品经理希望通过调研了解到的部分内容应该已经有了答案。接下来需要对需求进行分解,比如第一阶段需求调研中分析出了采购、销售、物流与库存之间的关系。那么采购有多少种类型,分为多少种情况就需要进行二次调研,将需求从大类划分出若干小类,从业务主流程划分出若干操作子流程。
  分解的过程即深度调研的过程,在调研过程中,每一个需求大类中有哪些子流程,流程中参与到哪些角色,每个角色是如何操作的,前置条件是什么都需要在此阶段了解清楚。在需求分解时,最好能够通过用户访谈和专题会结合的方式,讨论后每一次产出物的迭代更新也是需求逐渐清晰、正确的说明。
  调研过程中需要遵循一定的次序和逻辑,以免被调研用户发生业务交叉混乱导致调研结果出错的情况(可以再次体会下需求框架的作用)。深度调研结束后可能采集了很多录音、纸上记录了很多内容、脑子里全是调研的问题、用户的回答。将调研的所有素材整理成有用的信息,一共有多少业务流程,对应哪些操作子流程,流程中每一个节点由哪个用户角色操作,在系统操作还是线下操作,在什么系统操作,会生成什么单据,单据怎么流转,最终构建一张完整的需求网络。
  3. 需求分析
  3.1 优化
  B端产品在需求优化环节最难的点是应不应该优化,甚至在产品需求分析工作中完全就没有需求优化环节。从一个咨询顾问的身份去考虑,业务的现状和有序执行并不能说明现有的业务流程就是正确的,不臃肿的。但是优化可能就会涉及到流程改造,业务重组,这时候企业管理的需求是如何进行优化需要考虑的重要因素。
  常见的简易优化点:
  · 单纯数据处理:特点是工作量大、耗时、易出错、操作单一、可替代性强,像这样的情况线上数据标准化处理的意义非常大。
  · 出错高频点:特点是易出错、换人也避免不了。可以通过条码扫描(字符复杂、录入难度大)、自动计算(人工计算,单位换算之类)、智能匹配(限制性强、人工识别困难)等方法。
  还有一部分是涉及到操作问题的优化,如操作异常点、操作流程冗余、单据冗余等等问题。
  优化以后,涉及到的业务操作需要和对应角色、业务节点负责人进行评审确认。
  3.2 重组
  经过需求优化后的子流程之间会有共通点、差异点,通过场景、用户角色、操作现状、产品目标四个方面对需求重新整合、最终交付产品操作流程。
  比如原材料采购入库和配件采购入库的操作流程一致,操作用户和入库计算逻辑可能不一致,那么在需求重组时,可以合并为一个流程。
  4. 边界定义
  在产品目标、人力资源条件、行业约束等客观条件下,需求便会有了边界。如:
  · 行业边界:由行业规则、法规约束的边界。如财税系统。
  · 结构边界:一个产品由若干个子系统组成,每个子系统承担什么角色,完成什么任务,会有一个相应的活动范围。所以产品的结构边界必须要清晰,否则产品结构就会发生混乱,如交易系统与企业人事数据混在一起。
  · 功能边界:制定一个原则,一个功能是为解决同一类业务或者同一种问题产生的。同时需要考虑到人力资源、系统资源等问题。
  5. 需求转化
  需求转化即是从用户需求到产品需求的过程,需要做的工作较多,如优先级的定义、产品版本的切分、产品设计等。
  这部分可以利用马斯洛需求层次理论、Kano模型等结合产品目标、需求优先级完成产品版本的切分和产品设计。
  最后经过产品核心体系的设计,产品流程、产品框架的设计,最终输出PRD。
  以上描述的需求分析的5个阶段,每一个阶段在实际应用中都是一个不断反复的过程,其实,需求分析过程是产品经理对自己的认知不断验证、推翻再验证的过程。

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号