编辑导读：对于产品经理而言，需求的捕获以及分析能力是最为基本但也是最为重要的能力，这一过程需要耐心、需要技巧等尽可能达成需求调研的目标，这就好比一个奶爸独自带娃一样，需要从宝宝的表达中快速获知宝宝的需要，从而满足宝宝的需求。

一、需求调研到底调研分析的是什么

在开始之前我们先回答这个最简单的问题，可能会有产品经理会认为需求调研分析的任务是分析系统如何实现用户的需要。这答案不能说是错误的，但却是考虑得不全面的，这就比奶爸带宝宝时，似乎认为只要宝宝不哭就可以了，实际上作为奶爸，不仅是在宝宝哭时解决宝宝的需求，还要综合宝宝考虑的其他需求。

因此可能这是关于什么时需求调研分析的问题比较全面的回答，即需求调研分析实际上是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整的、内容清晰的框架，以知道后续的设计、开发工作。总结来说：需求分析就是先分解、再提炼，在这个过程中消除矛盾。

如果单纯认为客户要求就是软件需求，不注重对业务知识（业务事件、业务实体、业务规则）的捕获，从不主动问为什么，这样往往不仅达不到需求调研的目的，反而甚至会给后面的开发造成完全错误的方向影响。

二、需求调研需要具备的能力

奶爸不好当，产品经理同样面对很多难题，对于产品经理而言，想要做好需求调研一般会有哪方面的能力要求呢？

• 沟通能力：能够清晰表达自己的意思（善于打比方是提高专业沟通效果的好办法）
• 提问能力：好的提问其实很难，如何“一针见血”，问到点子上，聚焦问题是需要重点锻炼的
• 谈判能力：与客户争取筹码的能力，尽量争取主动权能够很好的帮助项目成功
• 理解能力：理解与沟通相辅相成，但良好的理解能力还需要专业的知识甚至心理学知识支撑
• 倾听能力：耳朵与嘴的比例，多听少说
• 共情能力：多理解客户的业务场景、客户感受甚至心理

三、需求调研需要具备的意识

1. 要有主动意识

产品经理要保持主动的态度和心态，要不怕麻烦，厚脸皮，别指望客户或需求方可以将需求整理妥当后送上门来。

2. 要有剖析冰山模型的意识

我们常说的“冰山模型”主要是指我们只看到表面而没看到根本，因此在需求调研中我们就要有破解冰山模型的意识，善于将三层用户需求都挖掘出来，即：

• 用户意识到的问题：用户通常遇到的困扰或者能够设想到的功能；
• 无意识的需求：充分理解用户的工作场景，具体的方法就是加强对业务知识的捕获；
• 未梦想的需求：需要需求分析人员充分理解业务并选择合适的技术方案，创造出用户未梦想到的功能

3. 要有聚焦重点意识

产品经理需要具备善于聚焦问题的意识，使得需求访谈重点明确，以主动发问的形式，基于目标把控访谈走向，不要轻易将“话筒”移交，否则极有可能会有“提到需求远超计划”的情况。聚焦重点的最简单方法就是产品经理的问题逻辑，比如：解决某某事情的时候一般如何处理？处理过程需要哪些支持？原来处理时存在什么困难或不便？还有哪些相关的问题是比较棘手的？

4. 要有破除“需求方”作怪心理的意识

与各色需求方打交道难免会遇到各种各样的人，因此遇到阻碍需求捕获的“人”的心里就不足为怪，不能受其影响。概括来说，作怪心理会分别有言过其实、越俎代庖、非正事心态、抗拒心理、推卸责任这五种。

1）言过其实

客户夸夸而谈，说出的流程都很理想化、规范化，但实施时却与实际大相径庭。通过观察用户的说法方式来发现，通常这种“言过其实”的表述都会以非常肯定的语气，并且讲述时十分流畅，没有什么打断，因为这个时候只需要创造，而不需要回忆。因此当我们遇到关键流程、有怀疑的流程时就需要不同用户代表访谈并整理结果，在开发前将差异展现给客户中高层管理人员，就如何解决达成共识。其次当在流程中，发现某个角色或人员过度参与时，就应该针对时间瓶颈、人员瓶颈进行分析，避免流程瓶颈导致系统无法顺利运转。

2）越俎代庖

这种情况主要发生在对业务不是很熟悉的客户身上，所以如何引起用户对系统建设的重视，认识到系统建设带来的价值是个难题。

这类型客户不管是不是自己负责或熟悉的业务，都喜欢侃侃而谈，并根据自己的理解和想象进行肯定的描述。解决这种问题，关键还是要识别并找到合适的被访谈者，也就是回答问题的最佳人选。

这里所说的“最佳”人选有两层含义：第一是问题的层次要正确，高层解决宏观问题、中层解决脉络（业务流程）问题，基层解决细节（活动）问题；第二是被访谈者是否合适，执行者往往就是最佳人选，所以有效识别该问题所针对的业务环境是由谁负责处理的。

3）非正事心态

被访谈者没有将访谈当作一件优先级很高的事情，有主观与客观两类因素：客观因素是访谈时在办公室等环境容易被打断，影响访谈效果；主观因素是非计划内的事情通常都会被认为是优先级低的事情。这种心理是由于客观与主观因素导致的，所以要解决这两个因素：提前做计划，与客户约好时间并明确主题；客观因素：尽量避开办公室类的环境，会议室最好。

4）抗拒心理

抗拒心理在基层比较常见，因为信息化系统对操作层而言效益并不那么明显，且经常使得工作量增加。这就使得操作层用户代表在需求捕获过程中会将对信息化系统的敌对转化为对产品经理的敌对。敌对状态下是无法有效沟通的。

5）推卸责任

在需求调研中会经常遇到“你找中层，中层让你找基层；找基层，基层说我们没需求，这事你要找领导”这种情况，中层回应体现了项目目标不够明确，操作层的回应则体现了推卸责任的心理系统化系统对基层的效益并不明显，所以就会有“事不关己高高挂起”的心理萌生。针对这种情况，首先考虑为什么项目目标不明确，是客户的原因还是产品经理前期在目标分析时存在问题；然后针对基层，最简单有效的策略让被访谈者介绍工作场景：先从工作场景开始，问客户从事哪些工作，工作是如何进行的？工作中存在什么障碍，有什么困难等。

5. 挖掘需求变更可能意识

要求关注变更可能的捕获意识，在需求捕获过程中要加强这么方面的意识，毕竟用户不会把所有的变更可能告诉你。

6. 需求协商意识

经常会遇到需要协商的情况，需要灵活应对各种场景，如何和客户谈判争取主动权？对于这一重要环节，产品经理可以从以下方面处理需求协商问题：

1）需求范围明确

从业务流程梳理业务场景时，客户代表常会提出将与业务流程相关、但超出业务目的的业务活动纳入范围，对于项目而言就需要和用户代表进行协商，根据“目标分析”中的目标来明确边界。造成这样的原因是因为业务流程捕获时，为避免在分析、设计阶段断章取义，并没有考虑系统边界。因此客户代表很容易从业务流程的“服务请求”开始要求实现，但“目标决定范围”，与目标无关或者无直接贡献的应移除。与客户代表协商时，以客户方高层领导“目标”划分即可。

2）拨开立场，寻找客户利益诉求

产品经理在需求调研中遇到的典型场景：客户提出的需求或变更会导致需求蔓延或较大幅度增加工作量。当我们与客户立场发生对立时，核心技巧在于问出客户的立场，当真正了解客户的利益诉求时，就可能找到很多折中的办法，而问出客户立场最简单的办法：多问为什么!

3）需求优先级的确定

当客户将所有需求都定义为高优先级或有意无意不指定优先级时，就会对项目计划造成影响甚至导致需求蔓延。

相对重要→相对次要：选择一个其上级领导提出的、他也知道的需求来比较，告诉他实现他提出的需求就会影响领导关心的需求。如果需求不是很紧急，一般他就会放弃。但如果他还坚持，就要重点审视需求的不可或缺性了。

7. 打比喻意识

由于信息的不对称，导致客户无法理解技术领域，这时候就适合利用对方熟悉领域的事物来解释深奥的问题。

1）敢于抛弃细节，不奢望一次成型的意识

在业务流程的识别与分析过程中，第一是善于、敢于抛弃细节，不要过早地钻研到业务活动的具体步骤中，这样必然会导致流程图的规模被扩大了，也就破坏了此目标的达成。第二个是抛弃一次成型的思路，不要精雕细琢，而是出草稿、谈问题、修正草稿、再讨论、再修正……最终达成共识，这才是合理的过程。

2）需求改进意识

对于客户提出的需求，除了“线下到线上”的实现外，对原有业务流程的优化与改进至关重要。

四、需求调研中获取客户需求信息的方法及途径

需求调研获取客户需求信息的方法和途径有很多，但基本主要是以下六种，这六种未必需要全部使用得到，具体使用哪种方式还需根据实际的项目需求进行选择。

1. 用户访谈

1）确定用户访谈人群

面对人群及对应的目标，比如高层决策人员、中层管理人员、操作人员、技术团队等；

2）确定计划时间以及内容

根据访谈面对人群的不同，就他们关心的“话题中心、目标”准备问题。如果产品经理带着空白的纸张、空白的大脑展开需求捕获活动的，这样必将导致用户访谈效率低、针对性不强的结果，要解决这个问题，就必然在访谈展开之前先计划要访谈的内容，并且在有可能的情况下将其事先发给被访谈者，以便他在访谈前做好相关的准备工作。

3）访谈时间安排

心理学研究显示，一个成年人可以聚精会神地专注于某一件事的时间大约在50~70分钟，因此建议访谈时间控制在1小时以内。

4）访谈地点安排

尽可能选择会议室、洽谈室等封闭、不易被打扰的地方（参照“非正事心理”）。同时会议记录建议采用“做笔记+录音”的组合形式，且在访谈者每陈述完一段话后进行复述，以确保双方达成共识。

5）访谈的沟通技巧

访谈对沟通技能要求很高，要求访谈者善于倾听、善于表达（记住“两耳一嘴”的原则，表达能力强不代表要话多）。

以业务为中心：访谈过程中要注意谈话中心是“业务”而非“技术”。

多听少说：访谈的信息流是被访谈者→访谈者，因此要切记喧宾夺主，导致信息获取不足。“人说话和倾听的比例就是嘴巴个数与耳朵个数的比例”，访谈者说话的总时间应该控制在三分之一以内。

言简意赅：尽量使用短句（主谓宾结构），少用“定状补”；不使用“被动句、双重否定”等容易歧义的句式；不要采用过多修辞手法。

提问有层次感：将长问题尽量拆解问多个递进性的子问题，避免一次性提问

6）合理搭配问题类型

开放式问题（简答题），这种的优势在于被访谈者更自主，能反馈更丰富的信息，压迫感最低（被访谈者感到更自在）；劣势则是容易跑偏、产生太多不相关细节，导致访谈失控；信息量较大，需要花费较长时间才能获取有效信息；会使得访谈目标显的不那么明确。

半封闭式问题（选择题）/封闭式问题（判断题），这种优势在于节省时间、容易直击要点，可得到准确的数据，易对不同被访谈者回答进行比较；适合大范围访谈；劣势则是无法得到细节（还会诱导被访谈者），可能导致信息遗漏；压迫感较重，且访谈效果过分依赖产品经理人员水平。

尽量使用开放式问题；当访谈开场或出现僵局时使用封闭式/半封闭式缓解；在需要使用封闭式问题时，尽量转化为半封闭式（降低过强的诱导性）。

7）擅长使用模型

一图胜千言：擅长使用模型、草图表达，更容易达成一致

8）善于消除行业带来的隔阂

产品经理与客户常来自不同的行业或专业背景，所以交流过程中一定存在“术语”。在访谈过程中要勇于问客户的“术语”，尽量用通俗的语言表达技术术语，让双方在沟通时对“术语”的理解尽量一致。

2. 用户调查

能有效的消除“用户访谈”带来的信息片面性。优点在于调查面广，是对用户访谈技术的有效补充，能克服片面性，而缺点则是容易形而上学，不易深入。因此在需求捕获过程中，先访谈再调查是更合理的方式。

用户调查的调研方式最重要的在于问券的设计，那如何设计用户调查问卷？

篇幅：问卷填写时间不超过20分钟或保持在1~3页以内

布局：问题尽量按照从易到难排列：先易后难至少保证用户以良好的心态回答更多的问题

逻辑性：尽量将逻辑相关的问题按照业务逻辑顺序排列，跳跃性太大会干扰到被调查人的思路

避免封闭式问题：封闭式问题尽量使用半封闭式问题代替

开放式跟随：尽量让开放式问题跟随在相关封闭式、半封闭式问题之后；因为这时用户在脑海中有一些答案，填写出来的可能性就会大大增加。

比如：你喜欢什么运动？（可多选） □足球 □篮球 □围棋 □器械 □其他（请写出）_______

保持简单：对于开放性问题留给用户回答的空间不宜太长，否则会使被调查者产生压力，不敢以简单的方式回答，最终导致干脆不回答的结果，因此通常建议只留1~2行的空间。

另外需特别注意问卷调查方式的误区，当我们辛辛苦苦地完成需求调查之后，如果不能够有效地对其进行分析的话，其效果也会大打折扣。但很多人只是简单地统计每个选项的结果，这实际上是不充分的。需求调查是用来克服用户访谈的片面性的。因此我们必须在分析调查结果时找到差异性，分析造成这些差异的具体原因。

3. 参考文档

参考文档的方式优点是能详细、直观的对数据流细节进行了解和分析。缺点则是文档数量比较大，有效信息提取不容易且容易被误导；文档是有滞后性的，所以信息很可能是过时的。

研究、分析、细化数据需求细节的时候。数据需求通常比较琐碎、趋于细节信息，因此不要期望用户能够将其记在脑子里，这些信息往往寄生于各种类型的文档中。

4. 用户界面原型

使用界面原型的优点在于直观生动，用户界面提供了早期评审，易于用户理解。缺点同样很明显，就是耗时。在业务很复杂或很重要的需求部分时（不建议全程使用，除非有专门的UE），与客户就需求甚至方案产生盲区，不易达成共识时。

使用该方式需注意，以业务场景展现页面交互，在讲解原型时，按照客户工作的业务活动说明某个业务场景下客户应该怎么做，把相关的页面交互串联起来，让用户带着业务线索来审视系统的操作过程，看看是否合理、是否满足需求。串联体现了原型的动态性、交互性，用户不仅仅关心用户界面的样子，更关心用户界面的流转过程、交互过程。

5. 现场学习

现场学习最大的优点在于百闻不如一见，能够对需求与业务流程建立直观的认识。但缺点则是耗时长，不宜安排，且由于“观摩”心理干扰，可能会失真。当客户无法详细解释他们在做什么或遇到问题说不清楚原因时。“人正在做一件事时，最能解释他在做什么、为什么要这么做”。

使用该方法需要注意，第一避免失真：现场观摩或学习时，不要“大张旗鼓”的进行，导致操作者受到“办公室文化”影响而呈现出理想化的状态（会遮盖问题）。第二切勿走马观花：现场观摩时要努力总结整个任务的步骤、找到主要的业务活动（脉络），切不可嘻嘻哈哈看完了事；第三尽量录像：在条件允许的情况下可以录像反复观看，降低对客户的影响且可以给其他人员在需要时观看。

6. 联合开发（驻场）

这种方式优点是客户、产品经理、开发齐聚一堂一起探讨，更容易完成用户需求到解决方案的转换过程。缺点则是成本高，且控制不当就会变成扯皮大会。

项目启动初期：刚开始对项目的目标与范围都很模糊，需要一起讨论使得目标更明确，范围更清晰，为需求、开发指明方向，。同时对于关键业务域、功能块：系统中核心的关键部分，保证需求的准确性。

五、需求分析分为三个阶段

一阶段主要针对中层管理，用于梳理清楚需求脉络，为需求捕获二阶段业务活动的捕获与分析做铺垫，我们将该阶段比作“画骨”。

二阶段主要针对操作层（基层），用于梳理清楚业务活动的业务步骤（细节），为之后的用例建模与数据建模做铺垫，我们将该阶段比作“填肉”。

三阶段针对质量要求与约束进行补充，我们将该比作“化妆”。

一、一阶段（画骨）

1）流程相关知识

什么业务流程？即由多人协作，并且需要一些有效的规则来控制，才能达到预期效果的过程。

业务流程的六大特性：

• 目标性：流程是针对目标进行设计的，是一个整体，或许从局部来说是低效的，但目标是整个流程的高效。
• 内在性：流程本身是一个高内聚的整体，是一个很好分离业务耦合点的线索。
• 整体性：通常流程是由多个业务活动组成的，分析的要点在于确定业务活动之间的关系。
• 动态性：流程是行为流，不是一个静态的快照，而是一个顺序的行为流。
• 层次性：组成流程的活动本身也可以是流程，这也经常困扰流程分析的BA人员。要点在于理清流程的层次，通过逐层嵌套的形式理清脉络。
• 结构性：流程之间的关系主要包括串联、并联和反馈三种。

业务流程的分类：

如果拿软件开发过程来说的话，需求分析、软件设计、软件编码、软件测试都是生产性流程；

项目管理、质量保证就属于管理性流程了；支持性流程包括配置、文档控制等。。

• 生产性流程：流程中最重要的部分，是企业/组织价值的核心体现，通常是最容易识别的一部分；
• 管理性流程：是对生产性流程的管控，通常是由管理层发现的，对一些质量、效率进行监督的控制性流程，是容易忽略的部分。
• 支持性流程：是对生产性流程的补充，通常是协作部门、本部门员工执行的工作，是最容易丢失的部分。

业务流程的设计原则：

• 以产出为中心：流程以产出为中心，而非任务为中心。流程是否合理，是否高效，关键是从整体上进行评价，仅对一个业务活动进行分析是片面的。不要听从操作层的一面之词，要更多从整体来看待合理性。
• 自食其力：让那些需要得到流程产出的人自己执行流程。
• 权力下放：就是管理层级的扁平化，将决策权下放到更低的管理职位上，这样就会得到更高的效率（在需求分析过程中，如果发现现有的流程将决策点放在较高的管理岗位上时，就应该注意它经常会带来流程执行上的瓶颈，也就会影响信息系统的运作）。

二、执行步骤

1）业务流程识别（确定子系统范围），

同时坚持先内后外，先业务后管理的原则。业务流程属于脉络信息，掌握在中层管理者手中，因此该部分需求获取与确认应该找中层管理层，一般是部门负责人（关键干系人）；梳理服务请求时，将诸如修改密码、数据备份之类的技术活动先放在一边，我们梳理的是业务事件，而不是系统事件。

2）任务执行指引

1、识别外部引发的主、变、支流程

• 识别外部客户：本业务子系统有哪些外部客户；
• 识别外部员工：哪些其他部门员工会提出服务请求；
• 识别主业务流程：外部客户/外部员工的服务请求是什么？端到端流程是什么（主业务流程）；
• 识别变体业务流：主服务请求，存在的无法整合到主业务流程的独立变体；
• 识别支撑业务流：为了更好服务外部客户/外部员工，需要哪些辅助业务流程支持；

2、识别内部引发的主、变、支流程

• 识别内部员工/时间/状态：特别注意哪些特定时间、状态引发的流程
• 识别主业务流程
• 识别变体业务流
• 识别支撑业务流

3、识别管理流程

• 业务上线类的审批控制；
• 人财物资源的管控
• 进度与异常的控制
• 判断业务流程优先级

业务流程是信息系统交付的最小单元，只有实现了一个完整的业务流程支持，才能对用户产生增量价值，所以建议以业务流程来制定迭代计划。

• 是否为主营业务：主营、非主营
• 发生的频率高低：高、低

3）输入产物—《业务流程列表》

• 类型：说明是主业务、变体业务、支撑业务流程，管理流程
• 流程名称：不要将服务请求名称写入，转化为合适的流程名称（只通过服务请求寻找流程）
• 简要说明：说明流程的起点终点及流程目标概述
• 优先级：关键、重要、有用、一般

4）业务流程分析与优化

任务指引：

• 选择流程图描述方式：根据读者、流程类型选择合适的流程图来描述流程分析的结果。其中包括：
• 跨职能流程图/活动图：强调每个角色执行的活动；
• 顺序图（序列图）：强调各角色之间的协作、交互（经常用于表达系统间的业务流程，强调数据交换过程）；
• 数据流图：强调数据流通、加工和处理过程；
• 勾勒流程主体：厘清业务流程中的五大基本要素，搭出流程主体框架。五大基本要素是指：
• 分工：从提出服务请求到服务请求被满足的端到端过程，涉及哪些角色；
• 活动：每个角色将负责完成哪些独立的业务活动；
• 协作：这些业务活动如何协作的，是串行或并行或异步；
• 分支：针对不同情况如何处理；
• 产物：协作过程中会传递哪些文档。

补充事中管控点：厘清业务流程最终的三大管理要素：

• 审批：在流程中应加入那些审核项，以便控制风险。在分析流程时，应该识别出审批内容、审批意图才是真正的分析到位（禁止使用“岗位+审批”的格式命名审批，例：总经理审批，但这并不能表明审批内容、审批意图，之后如果换个人干这事，流程实际上并没有发生本质变化）；
• 规则：在流程各活动有什么规则；
• 异常：完全无法按照流程执行时，如何应对（流程执行中总会出现一些意外、异常，实现需要制定一些备案，以备应急之需。若处理应急过程比较复杂，可以另外绘制一张异常处理流程图）

分析流程执行过程的监管需求：从管理者的角度对流程进度、异常等进行管控识别、补充辅助相关需求。

• 管理者如何监控流程执行的进度、效率；
• 管理者关心哪些异常？如何监控；
• 管理者对监控还有哪些要求；

流程图绘制：

绘制要点：

• 分工平级：保证在同一水平线，要么全岗位，要么全部门，不要混用。且如果全部门，尽量保证部门都是平级部门；
• 活动命名采取动宾结构：活动是一个工作任务，因此不能够使用名词或名词短语，例：申请体检（正确命名）；
• 不考虑系统边界：画流程图时先不考虑系统边界，不是只画与系统相关的部分，以免在分析、设计阶段断章取义；
• 从服务请求者开始：流程起点从服务请求发起者开始，保证流程的完整；
• 主从活动只留一个：流程中很多时间存在主动活动，比如消费者缴费→收费人员收费，按照流程图读者角度保留一个即可；

方法/步骤：

• 一听：请业务专家或客户代表讲述过程，在纸上或其他形式快速画出流程脉络，这时只需要明确分工、活动及基本的协作关系。过程中做到“不打断、不陷入细节”。
• 二问：沿着流程发问

看看是否存在分支的情况，边问边修正；

问问各协作之间的产物关系，将其补充出来和业务专家、客户代表就“异常”进行交流，思考“是否存在完全不能当前描述业务流程执行的情况？如果发生了，应该怎么处理？”

沿着流程思考是否需要设置一些规则，比如协作间规则：用于控制流程协作，例：满足什么条件，流程如何流转。活动执行规则：执行每个步骤时需遵循的规则，例：当前活动只能干什么，不能干什么；数据规则：针对产物格式、内容进行限制，例：金额需要精确到小数点后两位。针对业务流程的“执行进度、效率、异常执行、风险”等管控需求进行询问排查

三读：产品经理讲一遍流程，确保与客户代表/业务专家达成一致

流程优化：

思路：

要想“解决问题，首先要发现问题”，要优化流程同理。那如何发现流程中值的优化的地方？

建议以“同理心”转换到客户角度，通过“穿越流程”的方法识别问题。通俗的讲，就是将自己想象为当前“执行人”执行流程时，让你自己去做一件事时，思考流程中有哪些繁琐、可以简化或优化的地方，识别出来。

策略：

• E（清除无效）：找到流程中不产生效能的、浪费的、低效的环节，想办法清除
• S（简化高频）：对流程中频率最高的环节进行优化，提升流程效率
• I（整合依赖）：将相互依赖的环节整合在一起，提升效率，例：开单和收费就可以在“同一窗口”处理
• A（自动化繁琐）：将人做起来麻烦的事情让电脑干，提升效率比，例：复杂的计算只需要人提供输入，由计算机按照预设规则运算，输出结果

本文由 @渣渣 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议