把伪需求扼制在摇篮里-B端产品需求方法论
需求的定义
需求是产品存在的基础，贯穿整个产品的整个生命周期。需求管理方法论概念包含了，需求调研和挖掘、需求分析、需求管理（输出需求文档）。需求工程也可以用一句话来说明，就是收集客户想要什么，最终确定实际做什么。本文会涉及到面试过程中问到的需求相关内容，可以先收藏后细品。
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）数据字典：不要出现这个数据在这是姓名，到另外一个页面成为了用户名这样的事情。
↘好文推荐：
所有人问「贴吧之父」俞军
产品经理的思考利器——UML
新晋管理者容易犯的3种管理错误
作为一个B端产品经理,日常工作中,"需求"一词,可能是我们听到过和说过频次相对比较高的词语了. 比如, 1.假设你刚进入一家做企业服务的Sass公司,领导告诉你,公司产品要解决的业 ... 老于笔记·01.04 你可以要求自己对人好,但不能期待人家对你好.你怎样对人,并不代表人家就会怎样对你,如果看不透这一点,你只会徒添不必要的烦恼. 正文 B端产品的需求来源于场景,产品经理通过满足客户 ... B端产品在需求搜集.分析.迭代上线的方法上与C端大同小异,但由于B端产品使用对象的角色多样性,跨部门协作的流程复杂性,B端产品的需求管理相比于C端"坑"更多. 作为一名B端产品运营 ... 在上一篇文章中我们讲了需求阶段的软件需求概述以及评审会议工作. 今天接着讲会议中的产品需求说明书.(这是一个非常重要的东西) 我们想要进行需求分析实战,以及要去理解需求,接下来我们要去测什么,都要通过 ... 前言:文章来自Worktile产品经理的产品需求管理经验分享. 作为B端产品经理,我接触过很多研发及产品团队,每个团队对产品需求的管理方法不尽相同,各有千秋.下面我来分享一下我司的产品团队是如何管理产 ... 更多精彩内容尽在www.pmcaff.com 这两天大家的朋友圈有木有被今年春晚吉祥物刷屏呢?以下是今年春晚吉祥物,康康!据说这是由国家一级美术师.北京奥运会吉祥物"福娃"的创作者 ... 阅读指南 受众人群:B端初级产品经理 阅读收获: B端产品需求挖掘的一些技巧: 了解用户标签/画像的一些业务知识. 手上负责一个和数据方面有关的B端系统,在日常的产品规划当中,没有关于"用户 ... 本文将以有赞零售产品为例,介绍需求全生命周期的管理实践,包括:商家的原始需求收集.产品设计与评审.研发的需求实现.上线后运营反馈.新一轮迭代优化,构成了需求全生命周期的反馈回路. 在整个过程中,我们是 ... PRD概念 PRM就是Product Requirements Document的简称,也就是产品需求模型.一般来说一个产品会伴随有市场需求文档(Market Requirements Documen ...把伪需求扼制在摇篮里-B端产品需求方法论相关推荐
最新文章
热门文章