需求的定义

需求是产品存在的基础,贯穿整个产品的整个生命周期。需求管理方法论概念包含了,需求调研和挖掘、需求分析、需求管理(输出需求文档)。需求工程也可以用一句话来说明,就是收集客户想要什么,最终确定实际做什么。本文会涉及到面试过程中问到的需求相关内容,可以先收藏后细品。

B端需求的分类

在我看来,B端需求主要分为,业务需求,用户需求和管理需求。业务需求,就是B端行业的业务流程过产生的需求,业务流程是行业知识体系的一部分。管理需求,在B端行业为实现业务目标而进行的决策、计划、控制等的过程产生的需求。用户需求,用户在系统使用过程中产生的其他需求。在下文总会用这三类需求进行详细说明。

需求的调研和挖掘,需求收集

1、调研的8大科学方法已经写过,这边介绍一下调研时的几个小技巧

1)用图形作为调研助手

用图形会引导大家的讨论方向一致,收敛,不易跑题。图形会引起参与者的视觉共鸣,从而加速、加深理解的程度。图形的逻辑清晰,可以避免讨论结果似是而非的现象,为后续需求变动提供证据(甩锅)。

2)找到调研的合适颗粒度

对于颗粒度的把握,是没有一个定数,但如果调研结束后,不需要再向客户进行咨询就可以进行设计工作了,那么这个调研就做到位了。第一次调研现场,颗粒度尽量越细越好,因为后续的调研会增加更多成本。

2、业务流程优化的一个方法-ESEIA方法

ESEIA流程优化方法是由五个首字母组成,包括E(Eliminate)清除、S(Simplify)简化、E(Establish)增加、I(Integrate)整合和A(Automate)自动化,用来减少流程中的非增值活动,增加流程中的增值活动,然后进行整合和自动化,如图所示。

产品经理方法论:常用产品方法论-夜科技
  • E:清除,找出并清除不增值的活动;
  • S:简化,清除不必要的活动后,对必要的活动进行简化;
  • E:增加,根据需要增加增值的活动;
  • I:整合,对简化后的活动进行整合,使流程连贯;
  • A:自动化,充分利用信息技术自动化功能,提高流程处理速度和质量。

案例:蓝湖SaaS,是一款针对产品设计到开发阶段的流程优化工具,从产品原型设计-原型上传-UI设计师打开-根据原型设计-设计稿切图-打包上传-程序员下载-打开设计稿并查找相应切图-开发时不定时查询,一系列流程中找到可清除的不增值的活动,简化相应活动,增加增值的活动(在线编辑和设计),整合后使流程连贯,数据上云,让整个上传下载自动化,提高流程处理速度和质量。

如何筛选与判断需求

1、摆正需求方的位置

需求的来源会有各种不同的渠道,有内部同事、领导、自己产生的需求。也有外部市场、用户、竞品分析、行业规范等产生的需求。我们需要先把他们产生的需求分类,摆正位置,才能对症下药。不管是哪个渠道来的需求,在上文有说到,可分为三类,业务需求、管理需求、用户需求。业务需求和管理需求分别来自于业务流程优化和管理流程方面,如图(房产营销部分业务流程)。

产品经理方法论:常用产品方法论-夜科技

1)业务需求,那需要从直接相关方和上下游的间接相关方来看,比如房产营销中的客户锁定期和解锁期,就会可能影响到销售、财务、采购、管理者等各个相关方,需要每个相关方都接触了解后才能设计。

2)管理需求,主要在上层管理的需求,一般只需要针对相关领导的需求就行,但需要知道需求方真实的需求,和该需求是否能够实现,由于管理流程是附加于业务流程之上的,所以如果业务流程没有能够产生这个管理需求的能力,那就需要从业务流程中去重新审视这个管理需求的真实性和可行性。

3)用户需求,这个就比较简单了,主要就是使用习惯,交互等事宜。可以从同一层级的直接相关方多了解后进行分析。

2、判断真实的需求

1)方法一:逻辑演绎

当产品经理不清楚客户的业务但又感到有问题时,可以用逻辑推演来判断,通过逻辑推演可判断客户的需求是不是合理的、正确的,例如:

为什么需要做这个功能?缺少这个功能会如何?

这个功能与其上游的工作流的关系,与下游的工作流的关系?

思考新需求对现有业务逻辑的影响,会不会影响现有业务功能,当然也同样要考虑到一些潜在的影响,这同样是你对需求评估的一个重要标准。

2)多维度观察

产品经理与客户在专业知识方面是不对等的,客户并不知道他提的需求将来再系统中会带来什么后果,产品经理也未必听懂了客户的真实需求,因此对客户提的“表面需求”要经过侧面的判断才能确定为“真实需求”。为了解决这个问题,可以参考使用5W1H分析法帮助做好判断工作:

对象(what):什么事情。

场所(where):什么地点&场景。

时间(when):什么时候、顺序。

人员(who):相关方、责任人。

为什么(why):原因。

方式(how):如何。

在需求调研中使用5W1H方法,首先要理解的是What、How,而作为判断的重要依据的是Why,其他Where、When、Who是附属信息,没有经验的产品经理只会从正面进行调研,即询问“做什么”“怎么做”,但是最为重要的“为什么做(Why)”却往往不问,这样就会失去多维度观察需求的机会,也同时失去了识别需求的虚实的机会。

3)价值判断

对于复杂的、规模较大的需求,用简单的、操作层面的能够做评估的依据难以确定是否是真实的需求,可以用“目的、价值和功能”三要素来分析和判断。目标,客户的需求目标是什么?价值,确认该目标达成后,客户可以获得什么价值?功能,做什么功能可支持该价值的实现?

如果针对某个需求的判断符合下述条件,那么它就可能不是真实的需求。

  • 确定不了这个需求的目标是什么?
  • 虽然知道目标,但是看不出目标达成后会给客户带来什么价值(回报)。
  • 提出的功能需求实现后,并不能给客户带来预期的价值等。

搭建需求池&需求的优先级

从各个渠道来的需求,经过上述的分析后,可以放入到需求池中。需求池里的需求主要有,

1)真实的需求,还未进行过价值评估

2)可能转化为需求的一些思考、想法、灵感。也可能是从竞品那分析所得。

过滤了一些伪需求,通过挖掘知道了用户的真实目的,确定了需求方意愿度,明确了需求价值点,根据需求价值来提供解决方案,整理出了需求池,接下来就是对需求的优先级排序

1)从需求分类的层级来排序,在B端产品中,因为业务需求是所有需求的底层,所有业务需求是第一位的,然后才是管理需求,最后才是用户需求。这就是为什么很多B端产品不讲究交互设计,而在业务流程上做了很大的投入。

2)可以从两个纬度四个象限进行划分,一个是紧急程度,一个是重要程度。按照优先级划分为重要紧急、不重要紧急、重要不紧急、不重要不紧急。如果产品再0-1阶段,那根据KANO模型的基本型需求>期望型需求>兴奋型需求来判断,如果产品在1-N的迭代期,根据,产品价值大实现成本低>产品价值大实现成本高>产品价值小实现成本低>产品价值小实现成本高来判断。(图来自网络)

产品经理方法论:常用产品方法论-夜科技

需求文档的输出

功能需求整理输出产品方案,做需求文档输出时,为了全面考虑产品方案的逻辑完整性和流程的完整性,可用以下三个点来自查自检:

1、功能触发的前提

1)前置条件:触发该流程的前提条件,如领取优惠券的前置条件为“注册且登录账号”,甚至还有其他比如是否是新用户等等;

2)数据来源:流程中数据来源,如审核功能中:审核人员审批审下级发起的审核单。审核人员的操作流程中,下部发起审核产生审批单就是审核人员的操作流程中的数据来源;数据来源通常是在发生数据流转的场景下需要进行说明。

3)角色及权限:即用户在系统中承担的作用的抽象,是否已经把功能抽象到权限中去,这样可针对权限的设置来分配某些角色可以用,某些角色不可以用。

2、操作流程

1)事件:主要是指功能的交互规则及逻辑判断。这个模块用来说明用户和系统之间发生的交互。交互规则是泛指的交互规则,包含功能的页面布局、触发功能的动作及触发后的交互效果;逻辑判断则是指当用户在前端发生行为,系统对用户行为进行识别、判断并返回相应的动作的过程。

2)触发反馈:指用户与系统完成交互后,用户和系统会得到什么样的反馈及产生什么样的数据和结果。

3)异常处理:是对主流程补充,我们尽可能全的罗列并写清楚异常流程时,可以有效避免在产品设计时的场景遗漏。异常流程的梳理建议是参考测试同事的正反例原则。

3、通用说明

1)数据埋点:埋点就不多进行赘述,但不管是采用第三方系统还是自己的埋点体系,都要做好数据分类,后续提取数据时能减少很多功夫。

2)数据需求:主要为业务方和产品经理在使用和运营提供决策依据,在设计产品方案时一定要规划相对的监控数据指标,以便于后续运营和迭代时有数据进行支撑。

3)数据字典:不要出现这个数据在这是姓名,到另外一个页面成为了用户名这样的事情。