项目的需求调研？

如何做好新项目的需求调研？（一）

对于很多从事外包项目的公司来说，一个新项目，往往只有2~3个月的交付周期，而往往给予到需求调研的时间，很多时候只有短短的几天，如何能在几天的时间里面，把一个新项目的需求调研清楚，确实是令产品人员很头疼的一个问题，本文试图从需求调研的几个关键维度出发，把调研中的关键点梳理出来，让产品人员在实施调研过程中有据可依，有章可循。

早上刚到公司，Boss拿着手机就赶到我座位边，一边扒拉着手机，一边对我说：“有个新项目，是客户需要做一个基于微信预约管理的“访客系统”，我已经拉了个群，这里面XXX是项目负责人，我把你拉进来，你赶紧和对方联系一下，把需求沟通清楚；”

Boss丢完这句话就走了，留下一脸懵逼的我，嘴里还在嚼着刚买的早餐。

这个场景是不是很熟悉，很多公司都是这样，领导惜字如金，丢下一两句话，你就赶紧开工吧。

好吧，咱也来不及多想，抡起袖子就开干了。

首先，在百度里面搜索一下，啥叫“访客管理系统”，还好，大部分我们想找的东西，百科都已经收录了，百科里面的内容可能不全，但至少让你知道了：这访客系统是个什么东西，有啥用； ——-先帮你把基本概念建立起来；
然后，我们继续搜索，看看是否已经有别人做好的现成的“访客系统”，很幸运，很多时候你也能搜到一大堆类似的软件，虽然只是简单的介绍，但至少让你知道了这么一个访客系统的大致包含了什么功能；——你可以理解为这是一个简单的竞品分析的过程；
再然后，我们还要看看，一般都什么样的企业会去建设这种系统，这个该怎么了解了，其实你通过搜集的竞品企业，去看这个企业的成功案例，往往就能发现他的产品应用到了哪些企业，以及应用的大致情况如何；通过这种侧面的了解，就能让你知道，大致那些客户群存在类似的需求；——-客户群的了解

上面这个过程，我们每个人，拿到类似需求后，都会这么去做，这个不需要什么高深的知识和能力，会搜集信息就好，虽然是这么个简单的过程，其实它至少从三个方面帮你建立起了对这个项目基本认识：

概念层面：何谓访客管理系统；
产品层面：访客管理系统通常有啥功能；
客户层面：什么样的目标客户会产生这种需求；

需求调研四个维度

那么，了解了这些基本信息后，我们就可以开展需求调研了吗？显然是不够的，对于一个项目型的需求，我们要关注项目的建设目标，我们要梳理出客户需求点和关注点，我们要了解客户企业的对应业务是如何开展的，我们要知道都会有哪些人使用到该系统，我们还要知道这个系统和其他外部系统之家的关系等等？

基于此，把我们关注的点进行归纳，抽象出需求调研的四个维度：

有了这四个维度，该如何对每个维度开展具体的调研了，我们来逐一分解：

1. 项目背景的调研

项目背景，是了解用户建设该项目的动机和背后存在的痛点的关键环节，基于不同的动机，客户对系统的要求也是很大差别的；

现实中，对于项目背景的调研，往往是我们产品人员容易忽略的，忽略的一个最大的风险是：我们不能很清晰准确的把握客户的期望值和建设目标，从而给项目交付带来风险；

针对项目背景的调研，我们梳理的提纲如下：（事实上，每个项目的背景调研，都可以从下面梳理的问题点出发）

项目背景的调研，首先要找准对象，一定要想办法和对方项目发起人，主管领导进行短暂的沟通，即使只是半个小时的沟通都行，了解清楚项目建设的动机、对项目的期望值，要达成的目标，非常的关键和重要；

当然，因为面对的很可能是客户的大领导，有时候会比较敏感，需要我们有一些沟通的技巧和问问题的策略，这个方面我们留待下节来说明；

2. 项目业务的调研

业务的调研是整个需求调研的核心，也是最需要花时间的，对于很多项目所要承载的业务，我们不是简单的把线下的业务流程梳理清楚就OK，而是要通过当前线下业务流程的梳理，找到线下业务存在痛点，然后在形成系统的线上业务流程时候，如何来更好的优化和调整；

对于项目业务的调研，我们梳理的提纲如下：

项目业务的调研，需注意的是，仅仅听是不够的，还要收集资料，还要进行实际观摩，要知道，客户讲的和实际做的，往往会出现疏漏和差异；

3. 项目角色的调研

角色的调研往往和具体的业务相关，核心点是关注每个角色在业务中的任务，所在业务节点，输入和输出都有什么，然后才是该角色对于系统操作使用上的期望；

梳理的调研提纲如下：

项目型的需求，各个代表角色其实就是最后的产品使用者，需求注意的是，让角色用户提自己的需求和期望时，如果是偏离业务目标的需求，是不能接收的，这种情况现实调研中很常见，需要我们格外注意；

4. 系统接口的调研

系统接口是我们调研的最后一个维度，这个维度相对比较简单，搞清楚我们系统和其他系统有什么关系，需要建立怎样的接口就好，要点是把握好可能影响到项目进度的点；

调研提纲如下：

有了这四个维度的调研提纲，我们就可以据此形成调研计划，而如何把每个维度调研清楚，还需要我们在问题问法、沟通的策略方面下功夫。

需求调研篇｜业务调研开展的五步骤（二）

从零开始学运营，10年经验运营总监亲授，2天线下集训+1年在线学习，做个有竞争力的运营人。了解详情

在上一篇《如何做好新项目的需求调研？》的需求调研维度分析里面，最核心的调研维度是项目业务的调研。本篇就从这个维度，来把项目业务调研的开展做详细讲述。

谈到业务调研，其核心自然是围绕着“流程、角色、任务”三个要素来开展的，但要从哪些方面来开展具体的调研，我们举一个“食材配送B2B商城”的案例来进行说明。

这几年食材配送平台很火，比较有名的如“美菜”、“链农”、”小农女”等，当然倒下的也不少，我们且不谈这个商业模式，只讲这块的业务调研是如何开展的。

项目的大致背景：需求方依托于附近的省一级农贸批发市场，开展食材配送服务，主要针对企事业单位食堂，中小学食堂的配菜业务，特点是单一订单价高、食材种类多，客户群稳定，20~30个客户，年流水在3000万以上；拟上线一个B2B食材配送平台，把业务搬到线上。

调研的第一步，梳理业务流程，大致的业务流程如下：

接单——>拆单——>聚单——>分单——>采购———>分拣——>配送——>签收——>对账

这里我们不对整个业务流程来讲解，实际工作中，业务流程会比这个更复杂，我们本节的核心是对流程中某个具体业务节点来进行梳理；

基于此，我们以“接单”这个业务节点来看看业务调研是如何开展的：

第一步：要把接单节点工作包含的具体内容了解清楚

很自然，我们调研问题会围绕：

谁来做接单的工作，他/她对应的岗位是什么，归属的部门等；
接单这个工作，具体要处理的内容是什么，查看订单、核实订单内容、以及反馈什么东西；
以何种方式来接单，具体的操作步骤是怎样的？
相关的输入、输出的表单信息；
下一环节是什么，传递给谁等。

这个很容易想到，我们要了解一个业务，肯定首先从这个业务具体做什么、怎么做来了解；

第二步：我们需要了解接单这个工作的业务量的大小

了解的业务量，是为我们来评估系统的处理性能来做准备的，针对这个案例，需要了解的基本信息有：

目前接单这个工作有多少人在处理；、
每天什么时间段为接单处理时间；
每一单的处理时限是多久，平静值，最大、最小值等；
那个时间点为高峰期，高峰期的业务量是多少？

还有更多的细节需要去挖掘，但要点就是围绕着上面来开展的；

第三步：节点的工作标准和规则

很多的节点工作有依托的行业标准，同时有相应的处理规则、或者是固定的公式，这些梳理出来，就是我们程序中涉及的算法相关的内容，

它需要我们了解的基本信息包括：

接单操作是按照某个规则自动接单，还是手动的人工接单；
接单处理过程中需要遵循的业务规则；
多个接单员之间，订单分配规则是怎样的，按地域、按时间，忙闲程度等。

这个方面调研的关键，是把处理规则和标准梳理出来，当然、线下处理规则当变成程序算法时，需要更加严谨，以及必需的优化处理；

第四步：节点业务的异常情况处理

前面了解的都是正常的业务情况下的处理，那么存在哪些可能出现的异常，对应的异常该如何进行处理，这个在调研中往往容易忽略，却可能给开发工作留下很多的坑；

针对这个案例，需了解的异常信息包括：

接单工作中是否存在超时、改单、退单、补单等情况；
当出现异常时，涉及处理的部门和人员都有哪些？
每一个异常情况下，处理的步骤是怎样的？

这些细节的了解，对于把业务流程中异常了解清楚非常关键；

第五步：节点的业务场景特征细节

前面从业务节点的基本内容、规则、业务量、异常情况都了解清楚后，还需要针对节点的业务场景细节进行调研，恰恰是这些业务场景下的关键细节特征，决定了你在产品功能和交互细节设计时，是否很好满足了用户的需求；

针对这个案例，场景的业务细节需调研的有：

客户订购的特征：比如一些食堂，每周一、三、五的食谱基本是一致的；——那么如果有常购、订单再次购买等设计，对于用户的操作使用就非常方便；
比如某些客户习惯一次订购一周，或者一个月的；——那么支持便捷的周期性订制可能就是有需要的；
比如某些客户是有餐标的；——那么是不是需要考虑根据餐标来直接给出食材
比如中小学食堂对于某些食材，虽没有明文规定不能采购，但实质执行中是有区分的；

当然，业务场景的细节并不是每个都需要满足，梳理出来，是让我们更好的了解用户的使用特征，并帮助我们在需求分析时，对各场景下用户的关注点来进行识别，并结合其使用频次、对核心功能的支撑作用来决定功能的优先级。

以上，只是以一个“接单”节来梳理的业务调研内容，并不能涵盖所有的细节，但只要从这5个方面出发，逐一进行细化，以访谈、观摩，资料收集、会议讨论等多种方式来开展调研，是能有效确保我们的业务调研不走偏，并带回充分有效的信息；

汇总以上的五个方面调研内容如下：（这个导图可以直接在调研时作为参考）

这一节的内容就是这些，希望能对大家的调研工作开展有所帮助，也期待大家持续关注我们的连载内容。

需求分析篇｜从实例分析中理解业务需求、用户需求、功能需求的转化

从零开始学运营，10年经验运营总监亲授，2天线下集训+1年在线学习，做个有竞争力的运营人。了解详情

本节试图从一个简单的“用户自助寄件”案例出发，分析业务需求、用户需求、功能需求之间的关系和差异，以及如何进行需求的分析和转化。

在产品的需求里面，经常有这三个概念：业务需求、用户需求、功能需求，但往往，我们很容易搞混，不清楚他们之间的关系和差异，我们先引用一下比较官方的解释：

业务需求（ Business requirement ）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。

用户需求（ user requirement ）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

功能需求（ functional requirement ）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求

这个解释其实还是蛮明确的，其实理解这三者的关键点，是要先认清楚每个需求针对的对象不一样：

业务需求———对应的是组织或者客户，实质就是业务的建设方；你也可以类比房地产市场的开发商；
用户需求———对应的是使用产品的用户；你也可以类比买房的人；
功能需求———对应的是产品，即产品要具备怎样的功能，才能满足相应的业务需求和用户需求；类比房地产市场，那就是房子本身。

类比成房地产三个角色后，你发现，开发商通常的诉求是想多赚钱，买房的人诉求是买到物有所值，甚至物超所值的房子；但不管二者怎么想，最终都是需要通过房子来实现，必须建设的房子的属性达到某个标准才能满足二者的诉求；

所以，这么一看，你就明白了，其实这三者之间的关系是：

即，业务需求和用户需求，只有经过需求分析的转化，变成产品的功能需求后，才能得到实现。

需求实例

接下来，我们用一个简单的实例来进行说明：

案例：用户自助寄件的需求

业务建设方：某快递公司

需求描述：目前很多城市的小区都已经有了快递柜，但快递柜主要是用于送件使用，而对于快递公司收件，用得比较少，某快递公司，就希望利用快递柜，来实现用户自助寄件的需求。

首先，我们来分析其业务需求

这个案例的业务建设方是：快递公司，其业务需求也很明确，就是：用户自助寄件。

业务方之所以要建设这个需求，其目的是：希望利用快递柜，实现更高效的收件服务，减少人工上门收件的等待、低效、人力投入成本高等问题。

其次，我们来看用户需求

这个案例的用户，就是每一个要寄快递的人，那么他们的需求是什么了？

他们的需求，其实就是在进行“自助寄件”的过程中，你尽量让我简单、易用，高效、快捷。

接下来，我们进行需求分析的转化

需求分析的转化，核心是两个点，一是对这个业务的场景进行充分的理解和认知，二是想明白业务场景中需求点，要通过何种方式来满足它。

业务需求是“用户自助寄件”，这个业务要实现，我们结合寄快递的实际场景，其实还是蛮容易就能想到，有3个关键环节：

用户要填写单据：即填写收发件人的相关信息；
用户要能找到周边的快递柜，并且能打开它；
还需要进行计量、支付快递费的问题

这三个环节，基本把这个业务的三个关键阶段说明出来了，它就是：填单——>找柜子放件——>支付。

然后，逐一对三个阶段进行具体的分析：

填单阶段：

业务方需求：必须收件人、联系电话、寄件人信息清楚、明确等等。
用户需求：能选的就选，能简单填写的就简单填。

转化为功能需求，你发现，无非是通过表单形式让用户把相关信息填上来，而为了满足用户需求，你肯定需要设计对收件人的记忆功能，让用户填写一次，后续每次只需要选择而已（相关的细节还很多，这里只做举例）。

找柜子放件阶段：

业务需求：把最方便最合适的柜子告诉用户，并确保用户能安全、准确的找到快递柜、放入快递件；
用户需求：我就想知道我要把快递件放到哪里，别让我多走；

这个业务需求和用户需求说起来简单，转化成功能需求时，其实里面还蛮多细节的：

位置服务肯定需要，一是为满足发现柜子的需求，二是也有导航的需求；
如何打开柜子呢？从我们的产品经验或者竞品参考来看，可以有扫描开启、验证码等方式；
如何保证用户去到快递柜，一定就有其空的柜子可以给他放了，这里面就涉及一个快递柜忙闲资源的管理；

所以，这里转化为功能需求时，你发现：有位置服务功能、扫描开启/验证码开启功能，柜子资源分配管理功能等；

支付阶段：

业务需求：根据收费标准，准确无误、及时收到用户快递费。
用户需求：支付方便。
功能需求：

如何来计量，由于是自助寄件，称重显然不合适，那么按体积是一种较简便的方式，而如何按体积了，其实根据可快递柜的柜子；
如何支付，这个还简单，可以使用比较常用的几种支付方式就好；

以上，都只是简单的需求分析和转化的过程，实际的需求过程中，我们经常讲需要结合业务场景、用户场景把一些关键细节挖掘出来，并能在产品设计时考虑进去，以给用户一个良好的体验。

业务场景细节的挖掘

比如：在上面的开启柜子的方式中，到底用扫描开启还是验证码的方式呢？

其实用“验证码开启”会更合适，因为会存在很多这样的场景，某个寄快递的人，刚好家里有人下楼，或者认识的邻居下楼，而快递柜就在小区门口，那么找人代劳一下放件是一种很正常的事情，那么这时候，使用验证码就是一种最合适、简便的方式。

又比如：某用户希望自己的快递能更快的被寄出去。

那么，如果在给用户呈现周边分布的快递柜的同时，还告诉用户，该快递柜的收件时间，目前快递员的分布位置，是不是能让用户更好的去选择呢。

这样的细节还很多，需要在实际分析中，更好的去理解用户场景、挖掘细节，并逐步的完善。

通过上面的分析，我们发现，只要你充分认清楚业务需求方的诉求、用户在执行具体任务时的诉求，并对产品的常规实现方式有了解的话，需求分析并不是一个多复杂的过程，就是这么一步步去推理、去转化的过程。

而要把每个细节做透，就必须在实际中多去磨练，在生活中多体验，学会场景化的思维方式。

需求分析篇｜从生活体验中理解用户场景及其关键4要素

产品经理就业培训班，12周特训，测、练、实战，22位导师全程带班，200+名企内推，保障就业了解详情

在产品需求分析工作中，理解用户场景是非常关键的环节，没有对用户场景的深入理解，是很难设计出让用户满意的交互体验出来的；本文试图从具体的生活体验出发，将分析用户场景的关键要素提炼出来，方便我们的需求分析工作。

用户场景

生活中，我们司空见惯的很多日常生活产品，其实在用户使用场景的考虑上，是有蛮多讲究的，产品经理学会从日常生活体验中去发现、理解产品的用户场景，对提升我们的需求分析和设计能力，是蛮有帮助的。

闲话少说，举个栗子先：

如上图，最近家里添置了一些的新的碗，如上图左边的“直口碗”，在选购的时候，觉得这种碗蛮好的，一是看着蛮美观的，二是不像原来的“敞口碗”（如上图的右边所示），看着挺大，其实并装不了多少饭，因为虽然碗口看着大，其实碗很浅，下面很小。

想着新添了一些饭碗，吃饭时开始美滋滋的拿着用，可是一用这个新饭碗，突然就发现问题了：

什么问题了，就是吃饭时要想扒干净碗底的饭，很费事，那是怎么回事呢？

原来啊，这种直口碗，碗口和下面一样大，再加上碗还比较深，而我们中国人都是用筷子吃饭的，刚开始装满饭时还挺好，可是当饭只剩到1/4、 1/5的时候，你发现要从碗底，用筷子扒饭出来就比较困难的，直口碗逼迫你用垂直于碗底抓筷子的姿势来操作；

相反，如果是敞口碗，碗底很小，碗口和碗底不是垂直，而是斜着的，用筷子斜着来操作就很自然和简单了，对比示意如下：

好吧，这还不算玩，吃完饭，把碗洗好后，按照中国人的传统，碗是堆叠者放的，当你是直口碗的时候，碗底和碗口一样大，这又悲剧了，无法堆叠，而敞口碗可轻松的进行堆叠；如下图：

从这个简单的例子我们可以看到，碗这个产品的设计，有两个关键的场景要考虑到：

吃饭使用的场景，结合使用筷子的特征，必须是敞口的设计，才能方便操作和使用；
存放的场景，结合原来中国人碗柜的特征，需要堆叠摆放，也需要考虑能适合堆叠（当然，现在大家普遍都用消毒柜，堆叠的需求在弱化）；

如果脱离了这两个关键的场景，仅仅考虑了能满足装饭，能抓握，端住，然后把更多的心思放在美观设计上，其实是本末倒置的。

生活中，其实脱离使用场景设计的产品比比皆是，比如以前的路牌，只考虑了大白天，光线很好时，确实可以看清，可一到晚上就悲剧了，即使把远光打亮射到路牌上，也看不清路牌，因为路牌的字体是没有进行反光设计的。

又比如，很多公交车停靠站临时调整的通知，往往贴在车厢里面，可是人已经上车了，你再告诉他，你要去的站不停靠，已经没有作用了，这个就是完全违反使用场景的。

关键要素

那么，我们有了生活体验后，该如何提炼出用户场景的关键要素了，我以为，我们可以从电影中的场景片段具备的基本要素来进行考虑，比如一个电影的场景一定有这么几个要素：

时间、地点、人物、要做的任务

接下来，我们以百度地图为例，来分析一下这个产品都从那几个要素来进行了场景化的设计：

1. 地点要素

对于百度地图，地点这个要素是核心，其实就是用户当前的位置、以及你需要到达的目的地。

那么场景功能设计上，需要把用户的当前位置、目的地位置、距离，出行方式、出行的路径等都要考虑进去，才能有效支撑位置这个场景的需求。—这个还好说，地图产品都会这么考虑。

2. 时间要素

时间要素，之前我们看地图类的产品，都只是把实时路况加进去了，这个自然是场景设计里面所需求的，但你去看北上广的百度地图。

对于公交出行的方式，更贴心的场景设计是：你当前所在公交站，下一辆要到达的公交目前在什么位置，到达本站还有几分钟，这些都考虑进去了（这实质是位置+时间两个要素的结合设计）。

而当你上车了之后，还设计了到站的提醒功能。

这些细节的设计，才是真正把时间这个要素很好的体现到场景功能里面了。

3. 人的要素

人这个要素，所有功能其实都是围绕人来进行设计的，场景设计中人这个要素的核心，就是真正把自己当成用户，把用户的关注点、渴求和期望找出来，然后分清主次和核心点，进行设计。

百度地图里面，最近推出了“一路同行”这个功能，其核心就是很多聚餐的场景大家从不同地点出发，到达同一个目的地，有实时的位置通知和沟通的需求，就类似于微信里面的位置共享。

4. 要做的任务

任务这个要素，本来就是场景里面核心。

从地图的角度来说，用户基于当前位置、想到达的地方，想去发现某个点的需求，都对应场景设计中的一个个任务；关键点是要把核心任务提炼出来，不要用次要或者不重要的任务来干扰核心任务的使用。

而地图的核心任务，就是出行规划，场景设计的核心也是围绕这个任务来展开的。

那么好，你觉得百度地图的场景设计里面，还有那些点是可以更进一步的嘛，我想是可以的：

比如：

对于时间这个要素来说，是不是可以结合当时、当地的天气，给予用户一些更贴心的提醒了，假设外面的天气正下雨，当我打开地图进行路径规划时，是不是可以顺便提醒我带雨具呢？
比如当我在家里选择了公交出行，而根据我在家里的位置，离公交站的距离，下一辆公交车何时到达，是不是也可以提醒我啥时候该出门了。

当然，这些细节是不是要考虑进去，关键点还是不要影响核心任务的执行，以及操作使用的简单，易用上面。

总之，多关注生活，多从生活场景中去体验，并在需求分析和设计的过程中，始终把场景的四个要素放进去，看看是否每个要素都有哪些发挥的空间，结合起来有哪些细节可设计，你才能更好的把握好用户场景。

需求分析篇｜只需三步，掌握业务流程绘制的方法

业务流程绘制是需求分析中的重要环节，面对复杂的业务、众多的角色，如何来快捷的绘制出清晰的业务流程，本文试图将该过程拆解成简单的三步，让产品人员有效掌握业务流程绘制的方法。

在上一节里面，我们结合一个“用户自助寄件”的需求，分析了从业务需求、用户需求，向产品功能需求转化的过程，本节，我们继续沿用该案例，向大家展示如何高效快捷的绘制出业务流程图。

在业务流程图的形式中，对于产品人员来说，最经典的莫过于“泳道图”，从百度图片里面搜集的泳道图说明如下：

（图片自百度图片中搜集过来）

泳道图之所以应用比较广泛，是因为其：

清晰的展示了该流程里面涉及多少个“角色”；
该业务流程分成了多少个“阶段”；
角色活动的边界、流向清晰；

但一开始要直接来绘制泳道图，我们总觉得比较复杂，好像有些无从下手，又或是担心漏掉很多细节，那么到底如何有效的绘制出一个清晰明了，简单实用的泳道图呢？

下面我们以“用户自助寄件”的案例来进行说明。（该案例来自上一节的连载文章，建议可先查阅上节的该案例：需求分析篇｜从实例分析中理解业务需求、用户需求、功能需求的转化）

第一步：将业务分拆成多个阶段

用户自助寄件是一个业务，你也可以理解成一个任务，那么在自助寄件里面，大致可以拆解成几个阶段呢，在上一节里面，我们已经知道，可以拆解成三个阶段：

阶段1：在线填单阶段
阶段2：找柜子放件阶段
阶段3：支付阶段

具体阶段应该怎么拆，如何拆得比较合理，其实还是在于我们对业务流程的理解程度，我们在调研和需求分析中，是不是真正将业务场景、用户场景理解透了。

通常对一个任务的阶段拆解，你可以从任务执行时间上进行拆解，比如这个例子，填单和找柜子放件，是有时间分隔的，因为往往并不是填完单马上就会去放件。

然后，你可以从任务执行的位置、操作对象上来进行分割，还以填单和放件来说，地理位置上变了，特别是操作对象上变了，那么也是适合拆成两个阶段。

事实上，对任务阶段的拆解，你更多的是从时间、地理位置和操作对象几个维度上的不同来最后确定要区分几个阶段。

当然，一开始分得不合理也没关系，因为对阶段进一步细节分解、梳理过程中，会帮你发现不合理的地方，然后你还可以继续修正。

那么，当你第一步进行了业务的阶段拆分后，其实你可以简单的绘制阶段流程图，示意如下：

这个很简单，我们接着往下说。

第二步：阶段内各角色流程活动的梳理

有了第一步的分阶段，我们需要对每个阶段的细节内容进行梳理，阶段细节的梳理，其实要弄清楚的这里面会涉及那几个角色，这里的角色，不仅仅指用户，系统或者某个实体作为和任务有交互的地方，都是一个角色。

以“在线填单”为例，这里面有那几个角色呢，首先，肯定有：

用户角色：就是自助寄件的人；
系统：在线填单后，系统要接收处理快递单，肯定也是一个角色；
快递柜：是用于用户后续放件的地方，它也是一个角色；

这个案例里面，主要是这三个角色；有了角色后，那么我们就需要对每个角色，在这个阶段里面的具体的活动来进行整理。

在“在线填单”的阶段，任务的发起角色是“用户”，主要的活动也是他来触发的，所以，我们肯定要从用户这个角色开始梳理他的阶段内的活动。

那么用户在这个“在线填单”里面都需要执行哪些活动呢，其实联系现实中寄件填单过程，你很快就能理解到用户主要有“填写收件人信息”、“填写物品信息”、“寄件人信息”、“需要的柜子大小等”，整理成流程图，就是这样：

这个流程图里面的活动，其实都是蛮容易就能想到，唯一刚开始可能缺漏的是活动“4”，但其实一开始有缺漏没关系，后面进一步的分析会帮你发现这个缺漏。

理完用户这个角色，那么接下来要继续梳理“系统”这个角色流程活动。

很显然，用户在线填完单后，系统要接收该快递单，要考虑分配怎样的柜子，以何种方式来让用户找到柜子、开启柜子等内容，那么你会逐步梳理出系统的流程活动是这样的：

其实系统的活动也还蛮简单，也是只有5步，梳理完系统后，还有快递柜，显然，快递柜的位置和空闲状态是由快递柜本身的系统来返回的，它的流程图我们在这里暂略，在后面的总图中会看到。（需说明的是，实际上快递柜和快递公司，由于不是一家公司，所以，这里面快递柜是一个独立的角色）。

按照角色梳理完阶段内各自的活动后，接下来就是整合的操作。

第三步：使用泳道图来整合各角色的流程活动

有了上面的各个角色的阶段内活动图后，我们这个时候来把它们整合成泳道流程图，显然就很容易。

还以自主寄件中“用户在线填单”为例，最后整合出的泳道流程图如下：

看起来这个流程图一眼望去还是比较复杂的，但其实如果你按照上面的三步：

第一步，将业务分拆成多个阶段；
第二步，阶段内各角色流程活动的梳理；
第三步，使用泳道图来整合各角色的流程活动；

你一定可以比较轻松的完成整个业务流程图的绘制。

当然，在具体的整合过程，以及整合后，我们还需要对很多细节进行推敲，完善，很多时候也不是一次性就完成的，这里面还有很多正常、异常的情况需要去考虑，但有了上面的基本方法，你的框架定下来了，细节逐步去完善就不会很难了。

需求分析篇｜报表分析的三个关键要素

面对客户各种复杂多变的报表需求，我们如何能快速抓住要点，梳理出清晰的报表逻辑，从而设计出满足用户需求的报表，是产品人员在需求调研和分析中很重要的工作，本文把报表分析过程拆解成三个关键要素，帮助产品人员快速理解和掌握到报表分析的要点。

在我们的软件产品设计里面，报表很多时候是不可或缺的一部分，并且报表通常是管理者、高层领导要看的东西，是不是能很好满足他们的分析需求，往往对项目的成功起着重要的作用。

在今天的互联网产品里面，报表分析已经转化为日常的数据分析，成为产品运营的核心工作，所以，如何清晰的理解报表分析中的关键点，就显得尤为重要。

接下来，我们以某互联网产品统计工具的报表为例，来讲述报表分析的关键点：

1. 报表的三要素

要理解的报表的三要素，先上图：

如上图所示，每个报表都有三个关键要素：报表主题，报表指标，分析维度，我们逐一说明如下：

报表主题

报表主题，很多时候你也会把它当标题看待，事实上我们也是以主题对标题来进行命名的。

但核心点是，每个报表主题一定清晰的对应着某个分析的目标，代表了客户期望从这个报表中获取到的信息，比如上图中留存分析，通常是基于客户想分析产品的使用情况，为版本功能优化、用户体验改版等提供数据支撑。

但很多时候，特别在一些 TO B项目里面，客户往往是直接告诉你我需要什么报表，背后分析目的和目标并不一定明确告知你，这就需要我们在调研的时候，多问几句“您是用来做哪方便分析的，希望达到什么目标”之类的问题。

只有把报表期望得到的目标理解清楚了，你才能确定一个清晰的报表主题出来。

报表指标

有了报表主题后，很自然的，我们需要用哪些指标来支撑该主题的分析呢，还用上面的留存分析为例，你看到，事实上是从4个关键指标来进行分析的：使用时长、使用频率、访问页面、使用间隔。

这4个指标从不同的方面来对用户使用产品的行为进行量化、从而帮我们对产品使用情况进行分析。

当然，具体在指标值上，可以有数值，也有基于数值衍生出来的各种百分比，如同比、环比、方差等等多种形式。

另外，指标还可以是复合指标的体现，比如对于绩效考核的得分来说，分值就是一个复合指标，而复合指标里面，还蕴含着子指标。

但无论是哪种形式的指标，关键点还是要想清楚，围绕着报表主题，我应该用哪些指标数据来进行衡量。

分析维度

有了报表主题，有了分析指标后，接下来就是分析维度。

上面的留存分析，初看过去，好像没看到具体的分析维度，实际上因为这个报表相对简单，所以分析维度也比较明确，就是围绕着时间维度来开展的，而实际上对于留存分析，我们经常可以看到“日留存”、“周留存”、“月留存”，这里面的“日”，“周”、“月”就代表了三个不同粒度的时间分析维度。

从分析维度来讲，通常就是时间维度、空间维度，不同的维度支撑起我们对趋势、对发展分布、地域之间差异间进行对比分析，找出存在的问题点。

除开大面上的时间和空间维度，更细化的产品维度、服务类别维度等等对于更具体的定位到问题所在，有着重要作用；

更多的时候，我们还会对多个维度进行组合分析，然后找到其中的趋势、或者问题所在。

把握住了上面的三个关键要素，你也就能比较清晰的来设计一个报表的，但如何来展示报表了，这就是我们要说的第二点。

2. 报表展现形式

设计出报表了，该如何展示呢，报表的展示形式其实非常多，我们对常用的展示形式说明如下：

折线图：通常用于趋势的分析，所以其分析维度通常都是时间维度；
柱状图：通常用于对比分析，如果趋势分析是纵向，那么柱状图就是横向的对比分析；
点状图：多用于多个变量的回归分析；
雷达图：多用于一个复合指标，存在多个子指标的分析展示；
漏斗图：销售分析的经典图，其主要用于来看转化率；
饼图：主要用于看各分支的占比分析，也是一种横向对比的展示；
仪表盘：主要用于展示可以量化成分值类的指标，通常给企业高层管理者，喜欢这种仪表盘的展示，一是因为毕竟直观，二是因为仪表盘代表着一种企业驾驶、驾驭的感觉，所以很多人直接称这种图表分析的组合为企业驾驶仓；
热点图：是参考气象云图的方式来进行展示，通常用于展示有地域特征分布，并且实施动态变化比较快的数据；
地图：使用地图来进行展示，通常都是和地域、地区统计分布相关的；

展现形式还有很多，在很多时候也会以多种形式来从不同维度、不同组合方面来展示数据，以求得更直观、简单的呈现数据的信息，实际中需要我们灵活应用；

3. 报表的穿透

有了报表的要素、报表的展示形式后，为了实现某个分析目的，我们还需要考虑报表数据之间的穿透，穿透实质上有两个方向，一是纵向的穿透，一种是横向的穿透，用一句话总结是：横到边，纵到底。

对于纵向穿透，比如一个部门的绩效考核得分，90分，你需要了解90分里面的各项组成指标的得分情况，然后你向下穿透，分布看到子项的：工作业绩完成得分、团队建设得分、成本支出得分等几个子项指标；然后可能这些子项指标还有进一步的子指标组成，你需要进行逐级的穿透，最后到每个人得分，每个人的指标情况，从而有效帮你从宏观到微观，掌握到整个数据的全貌和细节。

横向穿透，那即从对比分析方向，看不同部门之间的、不同区域、不同产品等等方面上的差异，从而为你找到差距提供分析支撑。

综合以上，当我们在需求调研及分析过程中，始终从报表的主题出发，抓住报表设计的三个要素，再选择好报表的展示形式，并做好报表的穿透分析，那么，报表需求和设计工作将变得不那么复杂。

项目成功的关键：团队认知管理

一个失败的项目，可以找出很多原因，但有一点一定会真实的存在，那就是团队成员对目标的认知不一致，然后行动上产生了差异，最终导致了项目的失败。本文从足球的团队运动角度出发，阐述团队认知一致性，对团队成功的重要作用，希望能对从事项目管理的工作者有帮助。

足球与团队

讲团队，离不开当今世界上最受欢迎的团队竞技项目–足球，作为一个坚持看国足比赛的人，刚好最近国足还蛮火的，所以，必须从国足说起：

首先，表明观点，我觉得里皮带给中国队最大改变就是：团队成员认知有了变化。

怎么说，我且简单分析里皮带的三场比赛：

第一场，对卡塔尔， 0:0，其实那场球从场面来看，踢得很不错，就是运气差了点；
第二场，对韩国队，1:0，坦白说，踢得不如卡塔尔的场面好看，但运气不错，我们赢了；
第三场，对伊朗队，0:1，这一场，实力上确实有差距，但场面上，我们敢攻，也能守，是真实水平的体现，只是运气不在我们这一边；

那纵观这三场比赛，其实最明显的一点就是：中国队整体的队形保持得挺不错，且无论在落后还是领先的情况下，心态都比较好。

那么，这个变化和所谓的团队认知有什么关系了，其实太有关系了，你想啊，11个人里面，我们通常分成前场、中场、后场三条线（貌似我要普及足球的阵型打法一样）。

当团队对本场球的目标认知不一致的时候，前锋想攻，后卫想守，中场一会随前锋攻，一会又疲于防守，三条线经常脱节，那不输球才怪了。

所以，思想认知上是不是统一，从整场的阵型，队员们相互之间的跑位，接应就能明显的感觉到。

而回顾我们以往看到的国家队比赛，领先了，不知道该怎么踢了，落后了也不知道该怎么踢了，大家的想法和目标不一致，所以经常性输球也是在所难免的。

所以说，现阶段，里皮带给国足最大的变化就是：让大家在场上踢球时，目标认知一致了；这个一致了，其实在亚洲范围，中国队水平其实看起来就像上了一个层次（好吧，废了这么口舌来讲国足，足以证明我对国足是真爱啊）。

说完足球了，我们来正式说说项目管理。

项目目标的认知管理

目标管理的核心不在于目标的定义，而在于团队认知的一致。

我们知道，在项目管理里面，目标是第一要素，在目标的定义上，我们通常要遵循SMART原则：

S=Specific ——-具体的
M=Measurable ——–可衡量的
A=Attainable ——–可实现的
R=Relevant ——– 有相关性的
T=Time-bound ———有时间限制

为什么需要按照SMART原则来定义目标了，因为这样的目标，才好理解和认知，然后才能产生好的执行力；据统计，90%以上的执行力不行，其实都在于目标的定义问题上。

在这里，我要说的是，目标定义清晰，明确，只是手段，让团队成员理解到位，认知一致，才是关键点所在。

记得傅盛在他的一篇针对创业者的文章中说到的，CEO的核心任务，就是把创业目标从一个开放式的问题，变成一个闭环问题，而这里所谓的闭环问题，其实就是一个简单可行的目标。

我深以为这确确实实是真相，是很多创业CEO们知道却不肯承认的真相。

所以，我想说，在你做项目目标管理时，除开定义好目标外，把重心放在团队对目标的一致认知上，才是做好目标管理的核心要义。

其实反过来，当你的关注点落在结果的“目标认知一致”这个点上时，它一定会倒逼着你把目标定义得清晰、具体和可执行。

说完项目目标的认知管理，我们再看来看软件的需求管理。

软件的需求管理

需求管理的本质，仍然是需求认知的一致性管理。

一个软件项目里面，最重要的就是需求管理，一个失败的软件项目里面，需求永远是脱离不了干系的；

需求管理，其实就两点：

确定需求范围；———–这一点在外包项目中尤为重要；
管理需求变更；———–这一点常常发生，经常带来致命的影响；

说起来就两点，可做起来真的很难，几乎所有发生需求扯皮的地方，不是在需求范围上，大家意见不一致，就是在需求是否属于变更上，双方存在歧义。

所以，你看，所谓的需求管理，其实还是一个需求范围和变更的一致性认知问题，把认知统一了，自然就不扯皮了。

我们再回顾一下软件开发项目的变化历程：

以前传统的软件项目开发里面，我们会出具详细的需求规格说明书，可是需求规格说明书，只有比较专业的人员能看懂，你想让客户也理解你梳理的规格说明书，然后脑补出相应的产品界面，那除非他就是产品经理。

今天，需求规格说明书，逐步演变成了PRD文档，更注重从用户的角度来描述需求。

以前，基于UML，我们会有各种用例图、类图、业务流程图等。

今天，我们还是会绘制各种业务流程图、交互逻辑、功能框架等，但更多的，我们增加了原型的输出。

特别是原型的输出，把原来大家基于文字的揣摩理解，表象化为对图形界面的理解，这一下大大的提升了各方对需求认知的一致性水平。

所以，你会看到，软件项目中中间输出物的变化过程，本质上就是一个不断提升需求认知一致性的过程。

说这么多其实看似很浅显的道理，其实还是想让各位项目管理者明白：项目管理过程，关注到结果才最重要，而着眼于认知一致性的管理，就是一种有效的结果管理的方法。

否则，我们往往能看到这么一种情况：过程好像都是对的，该有的流程和环节都有了，可结果就是错的。

不知道这5个坑，怎么能走好需求分析之路？

产品需求分析工作是产品一系列工作的开端，俗话说：良好的开始是成功的一半。为了让你在这个工作上有个好的开始，作者在本文总结了产品需求分析过程中5种典型的坑，并根据自己的经验教训给出了一些针对性的建议。

需求分析是产品经理的日常工作内容之一。作为产品原型设计的准备工作，需求分析在很大程度上决定了后续产品相关工作的方向和范围，其重要性毋庸置疑。所以，一个合格的产品经理应该在这个需求分析上有一定的方法和策略。

今天，龙哥根据自身以往的需求分析经历以及观察到的一些情况，分享一下需求分析工作中常见的5种坑。无论是对龙哥自己还是阅读文章的你，都算做是一种提醒和鞭策。

1、把自己当用户

这大概是产品经理最容易犯的掉进去的坑。

从需求的角度来看，产品经理是用户需求的代言人。此时，产品经理的身上其实融合了两种身份：

提出需求的用户
整理需求的自己

一般来说，在需求分析工作的开始阶段，产品经理大多都能保持一定的清醒，能够比较理智地区分需求的来源。随着产品需求分析工作的展开，无论是用户调研，还是竞品分析及相关需求分析巩工作，都会使得产品经理越来越熟悉用户的需求。产品经理在需求分析方面也会逐渐变得自信起来。

但较长时间沉浸在产品调研工作中所产生的成就感中，产品经理会渐渐地、不自觉地将这两种身份搞混，把自己当做典型用户，然后就会开始从自己的角度提出一些针对自己需要的但并非用户需要的需求，甚至到后期开始忽略用户调研，任凭自己的喜好来判断需求是否合理。

这种情况下，产品经理一般会变得比较固执和自我中心，会坚定地不认为自己发生了越俎代庖的状况，从而让产品后续工作出现不必要的偏差。

对此，龙哥有两个策略奉上：

策略1：融入到用户当中去，定期、有节奏地将产品需求梳理的结果和用户沟通

龙哥的经验是最少进行两次这样的沟通。一次是产品需求框架梳理完成，这次的沟通可以过滤掉方向上的偏差和错误；一次是产品需求细节梳理完成，这次的反馈可以在细节上过滤掉偏差和失误。

经过这样两次的沟通、反馈，基本上不会出现低级或致命的偏差，可以有效地避免踏入此坑。同时，可以将这两次反馈发现的错误情况进行记录，找时间反思一下自己为什么当时会犯错。

策略2：将自己和用户的角色关系拉平，不要将自己当做上帝

产品最终是给用户用的，某个功能需不需要，需求强度是低还是弱，并不是产品经理说了算，而是目标用户说了算。

产品经理要摆正自己的心态，记住自己的责任不是制定需求，而是发现用户需求，然后用自己的专业能力和知识将发现的用户需求变成规范、完善的需求描述文档。

一定要尊重用户的声音，因为你要的是产品成功，而不是你的所谓需求成功。

每当你固执地坚持某个自认为正确的需求的时候，记得及时想起龙哥这句话。

2、被用户带偏

产品经理的需求分析之路是一个坑接着一个坑的。坑坑不穷，生生不息。

成功跳过第一个坑的产品经理们这个时候会遇到第二个坑——被用户带偏。

虽然说产品需求最终是来源于用户的，但是，合格的产品经理们都应该知道，用户大多数是不专业的，他们往往会倾向于短视，会给出一个貌似是需求但却不是真正需求的表面需求（真绕啊~）。

如果你不是足够用心和敏锐，会很容易出现被用户带偏的情况，尽管这并非给你提出这样需求的用户的本意。

对于此坑，龙哥给你一个锦囊：问问为什么。

用户短视不是没有理由的，因为他想解决问题，他只不过是在自己的所知范围内找了一个他认为的合理的解决方案出来，你如果把这个解决方案当需求，那就会被带偏，甚至偏的相当离谱。

基于以上分析，你就会发现一个事实：可以通过问“为什么”（为什么你要这个功能？为什么你想这么做？）来获得用户表面需求背后的真实需求。一旦找到真实需求，自然就不会出现被带偏的情况。

举个栗子（一个产品经理都听的耳朵起茧的例子，所以龙哥只是提要一下，真不知道的筒子们可以度娘或者人肉一下）：

产品经理－福特：你还想要什么？

用户：我想要一匹更快的马

产品经理－福特：为什么你要一匹更快的马？

用户：因为我想速度更快一些，好节省时间

产品经理－福特：我造了个东西，叫汽车，比马快多了

这个坑是考验产品经理专业程度的地方，你不能懒，要用心，要从用户的表面需求中挖掘出他的真实需求。

3、眉毛胡子一把抓

产品经理跟用户打成一片，也能从表面需求透视到真实需求了，这个时候，第三个坑来了——眉毛胡子一把抓。

此时，产品经理搜集了一大推需求，每个都是货真价实的真需求，看起来都很重要，都不可或缺，但又隐隐约约感觉到这些需求的确有些多，看着有些头大。

这个现象的原因，大多数情况下，是因为没有对需求进行分类和优先级排序。关于这个坑，龙哥有一个建议：

使用KANO模型（来龙去脉这种事情，龙哥不普及，有为青年一般都自行解决）。

KANO模型将需求分为以下三种：

核心需求：龙哥也称之为基础需求。没有这个类型的需求，产品就没有做下去的必要。比如一个音乐播放器居然不能播放mp3
期望需求：在基础需求上的优化。有了这个类型的需求，你的产品就会让用户用起来比较舒服，比如音乐播放器可以自动下载并显示和当前播放歌曲完美匹配的歌词
兴奋需求：满足核心需求背后的用户心理动机。这个类型的需求，通常会让用户产生产品经理带我飞的感觉，比如音乐播放器的歌曲排行榜、歌曲的音效增强等等

这个排列顺序不是龙哥随意的写的。一般来讲，研发一款新产品，核心需求优先级最高，期望需求次之，兴奋需求再次之。

4、被领导掰弯

顺利走过了第三个坑，恭喜你，你现在来到了第四个坑——被领导掰弯。

你带着自己发现的、经过整理和分类的、而且排了优先级的用户需求，壮志满怀地跟领导汇报，期望得到领导的赞许和肯定，然而，你总会遇到被领导否掉的情况，尽管有时候你认为自己是对的。

莫名其妙地，你居然被领导掰弯了，搞出一个领导认可但你可能表面认可但内心去不一定认可的需求出来。

针对这一坑，龙哥的策略如下：这个坑要看情况。

如果领导是内行，那一般情况下，领导吃的盐比你吃的饭可能都多，他会高瞻远瞩，看到一些你没有看到的东西，给你一些超越你现有积累、经验以及教训范围的建议，因为这是超越你的，所以你当时可能很难理解，但你应该听他的。

另外一种情况，领导是外行，不但外行而且强势。这个时候就很可能出现这样的情况：分明不同意他的意见，但却碍于他是领导，不好意思说或者不敢说。

此时，龙哥给你的建议是：尝试地去说。整理好你的理由，而且你要对自己自信，你要相信自己不会平白无故地弄个莫须有的需求出来，你给领导讲你的逻辑或者论据，如果你理由充分且正确，领导也没有必要坚持一个错误的东西，毕竟产品好公司才会好。

当然，如果你尝试了3次以上，涛声依旧的话，那真的好好想想了。

5、究竟要怎么开发

搞定了领导，你来到了最后一个坑——究竟要怎么开发？

你可能会说，这还不简单，只开发核心需求呗。

事实上，如果你做过产品需求分析，就会发现，其实核心需求也是很多的。

关于这个问题，龙哥有以下两个心得：

策略1、明确本次上线产品的目的

并不是所有核心功能都是要上的。在不同的产品时期或者版本规划，核心功能的侧重点都是不一样的。你要明确这个时期或版本所要解决的目标用户的主要问题，也就是你本期产品的主要目的。

比如音乐播放器的第一版，首先要解决的是能够流畅、正确地播放市面上主流的音频格式。

策略2、围绕这个目的进行功能的MVP化

此MVP并非NBA的MVP，而是最小可行性产品的意思。这个MVP的范围是根据策略1的目的来定的，是核心功能的子集。所以，这里的两个策略是配合着使用的。

根据本期的产品目的划分出MVP，然后针对MVP进行产品化工作，以最小的工作量、最短的时间，最低的风险来验证产品的可行性。如果验证结果是对的，那就乘胜追击；万一不对，船小也好调头，尽快调整一下策略然后重新开始。

判断MVP是否合格有两个标准：第一个标准是“完整”，也就是说有了这些功能，产品的目的就能实现；第二个标准是“必要”，必要的意思是指定的功能不可减少，如果少一个，那么产品的目的就无法实现。

产品需求分析之路，可谓一步一个坑，一不小小就会掉坑里。

作为一个合格的产品经理，首先要熟悉这些坑的位置，大小和形状；其次，还要眼明脚快身体棒，及时填坑或绕坑。如此，方能成功地通往产品工作的下一站。

什么样的需求不该做：警惕伪需求陷阱

初级产品经理所需达到的标准是能够实现需求，而资深产品经理则需要能够辨析出什么样的需求应该做，什么样的需求不该做。

提需求、提想法永远是最简单的，任何岗位的人都可以提出很多希望添加的功能、补充的活动等等。但要在所有需求里面，清晰地将需求背后的价值看清楚，则需要基于对产品本身定位的正确认知，拥有具有穿透力的逻辑思维能力，甚至有时还需要也懂运营和整体调动的专业知识。

做产品工作，往往需要面对大量的需求，新需求可以无限递增，但资源是有限的，这一般都是产品经理的切身之痛。所以，最终将被真正实现的需求一定是经过过滤的。那么，什么样的需求不应该做呢？

不合理的需求。需求本身缺乏所支持的合理立场观点，导致需求本身不清晰或低价值。
找不到合理实现方案的需求。既然是正当的需求，如果没有合适的产品设计方案，那么也无从实现。
有技术实现性难度的需求。就算需求是合理的，产品也有相关的设计方案，但是从技术实现上，有较大难度的，可以不着急实现。
容易返工和容易被更改的需求。这次的需求在当下这个阶段实现后，紧接着进入到下一个迭代周期时，就会被马上调整更改的需求，可以重新思考其实现的优先级。
具有潜在风险的需求。既然都没有上述4点的问题，如果一些核心的业务需求，在没有经过实际的业务操作团队确认之前，都可视为具有潜在风险。

大家对照着需求列表，如果都不是上述五类，则至少可以先判断这些需求是应该做的。而至于什么时候做，是本次版本，还是下次的迭代版本？那么这就是需求优先级的问题了。

但是，知易行难，有一类需求其提出的立场理由似乎站得住脚，也有适合的产品设计方案，技术实现的难度和代价也不大，不过这类需求也很有可能是伪需求，它们是不应该被实现的。

伪需求的问题通常并不是完全不合理，而在于产品视野与思维的局限性。仅看到一隅的价值，却忽视了整体的危害。辨别诊断伪需求，需要我们看得更透彻、思考得更系统。

案例介绍

需求背景：

产品内具有两种用户群体——投资人与理财师。投资人可向理财师预约见面咨询服务的时间和地点。理财师接收到投资人的预约信息后可进行确认咨询预约的操作，并按期见面提供咨询服务。

需求声音：

为了保障让理财师对投资人提供更好的服务质量，所以要在对理财师发起预约咨询时加入一条新增的逻辑限制：理财师当前时间如果已有对其投资人的已确认咨询，则其它投资人在该预约时间段的上下1个小时内不能对该理财师发起新的预约申请。

需求分析：

此需求是一条逻辑的限制性需求，其所提交的立场基本清晰，实现方案也很明确，实现代价应该也不复杂。主要的产品设计包括：投资人预约咨询下单的时候，对该理财师进行校验，如果不符合此逻辑，此提供弹窗报错。如果体验要达到更好一些，甚至还可以在前端展示当前理财师的可预约时间段，剔除已预约时间并减去上下1个小时。总之，做起来并不难，但这是一个典型的伪需求。

分析过程：

先看需求价值

咨询服务的时间段选取并不是更好的咨询服务质量的必要前提条件。虽然这个需求可能考虑到了，显示业务中，见面的咨询服务在去拜访的过程中可能要花费一些路上的时间。但是真实的服务中，理财师提供1小时的服务咨询并不一定完全比提供半小时的服务咨询价值更高。服务的质量与服务的时间及服务的时间段并不存在完全的前后因果关系。

站在更高的角度来思考现有产品体系内的替换方案

在这需求提出之前，产品已确认有理财师的确认预约咨询的功能操作。所以，最终对于预约咨询时间与地点的确认主动权仍掌握在理财师手里。那么，我们假设，理财师目前确实已有一个已确认的预约咨询，如果新增的预约咨询进来，理财师会自己考虑上路上可能花费的额外时间。如果最终发现无法满足新的预约申请，则该理财师仍可通过不受理通过此新预约申请的方式来规避掉其中的风险。所以，既然现有的机制已基本能满足实际的业务操作，何必还要画蛇添足新增此逻辑呢？

此需求逻辑中的1小时的数值定义较难选定出最合理的设定。在实际的业务操作中，如果距离隔得远，那就算设定了1小时的间隔，这个时间可能仍然也不够。但如果距离隔得近，则可能半个小时，10分钟都可以让理财师赶到新的地点。所以，此需求中的具体是定义“1小时”好，还是“2小时”好，或是“半小时”，这都没有明确的合理标准。想不明白的事情，不建议先做。

当前需求带来的潜在负面危害

限制类的需求一旦做了，就真的很有可能限制掉一些潜在的需求。如果设定了“1小时”间隔，万一用户双方都存在在此间隔内进行预约咨询的需求。则此限制，就起到了合理需求被禁止的结果，用户体验与反馈则十分恶劣。

其他的一些声音：

也有观点认为此需求可以起到防刷单和保障性能的作用。那么，此时还是需要更全面的产品视野来分析。看看当前的这版产品内，是否有想过的咨询服务的奖励机制与标准。如果当前根本没有刷单的相关奖励，那用户又哪来的刷单动力呢？而对于性能这一观点，在此场景中最直观保障性能的应当在于笔数，大可以直接规范在一天之内投资人最大的预约发起量和理财师的最大预约服务接受量之上，但在此需求中反而又是回到了时间段上来做文章，多少有点本末倒置。

合理的需求：

上述的需求依次分析下来，多少漏洞百出。如果仅限制在新增的投资人预约咨询不得预订到理财师已定的服务时间段内，那么这个需求还相对说得通。不过也要考虑到后期或实际操作中，是否会出现理财师一对多的方式来提供咨询服务的情况。如果会有可能会出现，那么连这个需求限制都不应该加进来。

总结：

很多时候不是做的越多，限制加的越严格，就一定越有利于产品。做产品工作一定需要宏观的产品视野来辨别出哪些需求是伪需求，哪些需求不该做，哪些需求可以做但本次不着急做等……选择与决策是努力的最重要体现。

案例详解：设计方案前如何做好需求分析？

在设计方案之前，不要盲目的画线框图，了解用户需求，全方位思考，才能更好的为用户服务。

在设计方案之前，不要直接提笔就画线框图，而要多思考多理解，让人知道你的线框图都是有理可循的。例如产品经理在做竞品分析的时候，常常从表现层，框架层，结构层，范围层和战略层分析竞品，提出自己产品的需求。这时交互设计不是单单接受需求就好，而是要更深入的去理解需求。

无论是交互设计师还是UI设计师，对战略层和范围层的理解很重要。战略层是什么呢？战略层就相当于你盖一座房子要知道这个房子是给谁盖得，要解决什么问题。而你作为房子的设计师当然要先去了解用户需求。同时也要利用自己的专业知识让让用户在这个房子里住的更舒服，更开心，这就是范围层说明了房子有哪些类型的房子，哪些功能能帮助用户住的舒服。

同样利用盖房子理解，如果你的设计方案令人不满意很可能就是你没有满足用户需求或者业务需求。那怎么满足呢，就要很好的理解和分析业务需求和用户需求了。

在设计方案之前，就要分析业务需求和用户需求，明确设计策略。那么业务需求包括业务目的（业务目的就是为什么要做这个功能？)和业务目标（产品期望得到怎么样的成功？)。以下尝试用一个具体的需求来讨论分析如何在设计方案之前做好需求分析。

提出需求：某线上教育英语网站 “邀请好友送次卡”的需求

一.分析业务需求

业务需求：做一个邀请好友一起学习的页面
业务目的：获得更多用户，用户数提高
业务目标：提高注册率，推广产品让更多的人知道（知名度）
衡量指标：邀请量（增加）注册率（提高）
用户行为：点击“邀请”按钮

了解问题比提供解决方案更加重要。这里解释一下目的和目标的区别：目的是达到某一个目标后想要做的事情，也就是实现目标的真正动机。目标要符合SMART原则，S具体的，M可衡量的，A可实现的，R有关联的,T有时限的。

二.分析用户需求

目标用户：小凌（上班族，90后+有英语基础，有线上学习的经验）
用户需求：获得更多次卡
用户场景：通过电脑邀请/分享好友
用户行为：点击分享链接
用户体验目标：快速完成分享，获得次卡

目标用户是指使用某一产品或服务的典型群体，不是个体。目标用户同时也是产品或服务的直接接触对象。比如小凌如果报名学习线上英语，但是付款的是他的爸爸而不是他自己的时候，这里的直接服务的人是小凌而不是小凌的爸爸，所以目标用户是小凌，而不是小凌的爸爸。

在分析用户需求时需注意，用户描述的需求一般都是外在表象，用户自己不可能提出自己认知外的方法。用户体验目标是指用户在使用产品时，期望得到的最终成果，这才是内在的原因和动机。

三.分解关键因素

需要从业务视角转变为用户视角，创造动机让用户更愿意点击分享。并且排除用户在使用前的担忧，更愿意分享好友注册学习。解决用户在使用中的障碍，让用户更快捷方便的分享给好友并获得次卡。从而提升用户体验，同时也顺利达成业务目标，提高注册率，知名度和业绩水平。

用户为什么会点击分享邀请好友呢（动机）？用户会有哪些担忧？使用过程中会遇到哪些障碍？这三个问题是从业务视角转换为用户视角的关键。下面具体分析一下这三个问题。

创造用户愿意主动执行的动机，比如：可以获得免费课程；多来多得；好友一起学习们可以互相监督，学习效率更高。
用户会有哪些担忧？比如：如何邀请？邀请好友麻烦么？邀请后如何获得次卡？朋友会愿意注册么？邀请后会告知我朋友注册成功了吗？这个活动是否可信，次卡是否有使用期限？次卡如何发放等等问题。
用户会遇到哪些障碍？比如：不知道分享到哪里？收不到次卡怎么办？等待收到次卡的时间太长等等。

关键因素就是指用户在使用前后会遇到的动机，担忧和障碍。关键因素越详细，解决方案就越多。问题慢慢清楚了，就可以提出初步的解决方案，如下图：

四.归纳设计需求，明确设计策略

通过分析用户体验路径，找到各个接触点，了解用户在使用的整个流程中遇到的问题，结合关键因素分析提出合适的解决方案。并完善流程中的各个步骤。在实际过程中，也可以以对比竞品的用户体验路径来完善自己的产品。

1.初步解决方案整理

整理关键因素，归纳解决方案，确定和各个部门的任务，提高效率。

2.建立用户体验路径和情感坐标

根据各个接触点的问题提出如下的解决方案设想。

在会员中心显示明显的“邀请入口”，可以加入动态效果，在会员中心页面有闪烁或者跳动的按钮；
查看规则尽量简短，或者利用时间轴解释规则，但尽量放在底部，不要占据用户大部分视觉中心；
点击分享给予恰当的反馈，告知用户已经分析成功。或者弹出模态窗口“分享成功！快去告诉您的好友获得一次体验一对一学习英语的机会吧！”或者也可以有简单的动态效果，分享的icon从loading变成对勾；
若好友注册成功，加快审核过程，提示获得次卡。在未获得次卡时，安抚用户。
获得次卡，除了恭喜用户获得次卡，可以马上约课以外，还可以提示用户“邀请好友得免费次卡”多来多得。

总结

不要盲目的去画线框图，只有在设计方案前，更好的理解和分析了需求，才能很好地服务用户帮助用户使用产品。同时，只有站在用户的角度去分析理解产品，才可以帮助产品站在全局的视角提升用户体验和设计需求，从而打造优秀的用户体验。

超详细分析｜高级产品经理做一个需求，和你有什么不同？

前段时间“高级产品经理与普通产品经理的差异”这个话题讨论得火热，联系到这段时间的工作感悟，从如何做一个需求这个工作中最常见的点，切入讨论，以供反思和讨论。

1 前提

首先定义一下这篇文里提到的两种产品经理。

普通产品经理大约分为两种，一种是资历比较浅、没有亲身经历过足够的版本迭代或产品生命周期的新手；另一种则是可能从业时间较长、也经历过足够的需求历练，但一直在进行重复性的需求处理，没有从更高层或者更深刻的角度去反思自己的业务，从而导致自己的业务能力到达一定水平后就停止爬坡。这里需要说明的是，普通产品经理并不是工作不到位，而是工作侧重执行层面、对工作的思考程度尚浅、还有很大的提升空间。

而文中说的高级产品经理，不与任何公司的等级或头衔挂钩，而是指在完善处理需求的基本业务能力以外，能够拥有自身的产品观与严谨的方法论，并应用在日常每一个需求的处理或决策上。一些高级产品经理仍然奋斗在一线，而另一些已经在管理岗位，虽然不完全直接做需求，但同样会用他的产品观与方法论影响整个团队。

2 做一个需求

那么高级产品经理做一个需求，究竟有什么不同？很早之前我做“零基础进击产品经理”的科普课程时，总结过一个产品经理日常处理需求的流程：需求分析——产品文档——需求评审——跟进开发——需求上线——评估效果——迭代优化。其实无论是高级产品经理，还是普通产品经理，整个流程的差异不大，区别在于期间每个流程的方法论与侧重点。

需求处理流程

a. 需求分析

对一个普通产品经理来说，分析需求的步骤很多时候在回答”用户要什么”以及”老板要什么”，能够回答好这两个问题就非常不容易了。而对于高级产品经理来说，在此基础之上，还需要回答两个问题：“业务要什么”以及“产品本身要什么”。

问“业务要什么”，很显然是要考虑公司目标和利益。时代不同，整个行业正在从务虚专享务实，很多公司已经越来越重视盈利性，单纯只考虑用户诉求是不足够的。即便考虑的不是盈利性，也要考虑你当前的需求是否与公司整体目标一致，比如当前公司主推的业务是什么？发力点在哪部分用户？未来一段时间要的是拉新还是留存？我曾经专门在微信群里分享如何基于行业和业务进行产品分析，并整理了文字版发在微信号破壳里，就是给大家一个方法论去回答好业务的问题，进而把握好整个需求的方向。

问“产品本身要什么”，则是对产品本身成长和发展的整体把握。很多产品经理在评估一个需求的时候，觉得是用户需要的、也是业务需要的，就没什么问题了，然而这时候高级产品经理则会再进一步去思考：这个需求后续该如何去迭代？是否与产品本身的规划一致？高级产品经理要做的不光是抓住一个需求点、打造一个功能，更需要考虑清楚这个功能以后如何成长、如何和产品整体规划融合起来。

b 产品文档

文档的表现形式和书写习惯多种多样，这个和公司规模和团队合作都有关系，倒也不能作为区分高级产品经理和普通产品经理的点。这个环节里能让人觉得“高下立现”的有三个点：需求释义；特殊场景；数据追踪。

需求释义是指，高级产品经理要确保自己对需求的理解足够清晰和准确，并够传达给整个团队。普通产品经理需求执行阶段，往往直接就开始写文档描述功能，这就无法把这个功能的重要性传递给整个团队；相反，高级产品经理则会把为什么做这个功能、为什么要这么做、对业务有多大影响这些问题都和团队解释清楚，无论是通过文档本身，还是口头或邮件表述（上面说了各个公司习惯可能不一样），都会是对整体团队的激励，提升技术、测试、运营等团队的参与感，甚至可能在沟通中带来更好的想法，优化实现目标的方案。

特殊场景是说那些主流程以外的流程分支。比如用户登录时输错密码了怎么办？用户输对了密码但是验证码又错了怎么办？突然变成弱网环境怎么办？……普通产品经理能够对主流程梳理地清楚到位，对特殊场景的覆盖往往力不从心；这时候高级产品经理则会尽可能覆盖全这些特殊场景或者是错误分支，给开发团队更明确的处理方案，这么做一方面是确保自身对功能表现的控制力，一方面也是从产品层面确保产品在不同端的体验一致。

到了数据追踪的环节，很多普通产品经理会直接把该打的tracking全部加上，确保没有遗漏即可。有些时候这么做的确也可行，然而如果遇到排期紧张或页面交互复杂的情况，这种做法则会造成开发资源浪费。实际上，做数据追踪的科学方式，是要依据该需求的核心目标而制定，数据追踪所实现的其实是定性目标的量化分解。

举个例子，假设一个电商产品想要增加销量，在首页新增了一个专题功能，目的是引导用户、刺激购买，那么最核心需要追踪的就是点击率和购买率，以及专题触发的点击率和购买率与其他路径带来的有什么不同，是否真的能更加刺激用户购买。比照交互路径，收集的数据应当是设备开启次数、专题区域展示次数、交互路径上可点击区域的展示次数和点击次数，从这个路径触发的商品页展示次数、购买次数等等（其中的次数要考虑到展示设备数、展示人数、实际展示次数的不同）。以目标量化分解为出发点，追踪核心路径的路径并保证数据纯粹性，比盲目打点更能帮你评估功能的效用。

c. 需求评审&跟进开发

把需求评审和跟进开发写一起，是因为对于高级产品经理来说，由于前期对于需求的处理思考维度更多，方案设计更具说服力，也能够激励到整个团队的协作，在需求评审和跟进开发的环节，反而耗费的精力要小很多。相对地，普通产品经理还沉浸在“如何与程序猿相处”的问题中，甚至在开发环节发现一些问题再做修补，其实都是对精力的损耗。

d. 需求上线

这个流程其实大家都在做三件事：一是确保功能相关的素材和相关的部门准备完毕；二是功能回测无问题，达到可上线状态；三是上线节奏控制，是否需要内测、分渠道等等。这些其实都没有太大的差异，只是高级产品经理会在细节处理上更到位。比如说，一个新功能的上线，普通产品经理会通知到运营团队准备相关素材或者活动推广，也会主动参与到方案讨论，然而高级产品经理会同时通知到客服团队，做好用户咨询的准备。

虽然是细节，体现的则是考虑更周全。

e. 评估效果

需求上线后到了评估效果的环节，这里就是我之前写的“数据追踪”派上用场了。比起普通产品经理面对数据的再加工，高级产品经理在进行数据追踪时就已经想好了该如何评估这个功能的效果，主要是看哪些指标。

f. 迭代优化

普通产品经理通常是在评估效果后，根据数据反馈对功能做下一轮的调整和优化。然而这会产生一些很棘手的问题：比如说，有些优化会造成版本不兼容（尤其是移动端），这就不得不维护两套逻辑，还要分别考虑到不同版本的用户体验；又比如说，到了下一个版本，这个功能的优化需求被降低优先级了，那么上一个版本的问题可能会在线上待更长时间，回头再处理时就是更恶心的版本不兼容；还有一种可能，时间长了，事情又多，这个优化需求就被大家遗忘了……

高级产品经理在做需求时，首先一个出发点是：不留已知的坑在下个版本优化——因为下个版本可能就优化不了。所以在刚开始做需求设计时，就尽量避免一些有可能会挖坑的设计，或者在上线效果不确定时先做小流量测试，甚至是通过H5页面或者微信生态测试；其次，在需要优化升级时，也会再次根据当时的产品状态和业务要求进行评估，这又回到了第1步的需求分析，完成需求处理的闭环。

3 总结

总结下来，我们会发现与普通产品经理不同，高级产品经理在做需求时有这么几个特质：

重视业务，契合公司战略，回归商业本质；
对需求要有规划，一个好棋手是下棋一步，心中已有九步；
目标清晰，并贯穿需求始终；
激励团队，激发群体智慧，一群人战斗总要好过一个人战斗；
细节决定高下。

当然，什么“尊重用户”“数据驱动”“团队协作”这些基础素质就不写了（如果还不具备，大多数情况说明还不是一个合格的产品经理），总结的这5点更侧重于一个普通产品经理的自我提升。这5点特质，看上去似乎没有什么，但在实际工作中却是一个产品经理思维高度与业务素养的重要反馈，要想面面俱到的确需要更多付出。

正好也到年末，新年计划的时候，不妨让自己更靠近一个高级产品经理吧。

需求的折磨：需求评审的前、中、后，产品都要做些什么

每一个需求的从无到有，从有到确认；每一次的需求评审，从失败到成功。对产品经理来说都是一次折磨。每一个版本迭代，我们都需要反复地被折磨，换了新工作后到现在已经4个月了，工作方法的转换，2个版本，4次需求评审的折磨。我也慢慢发现错误，改变工作方法。

第一个问题，出在需求评审，为什么需求评审就是没办法一次通过呢？为什么需求总会被大家指责？

首先，我们应该知道需求评审存在的意义，到底需求评审的作用是什么？

在之前几次失败的需求评审中，我把需求评审用来与大家敲定需求，许多人是第一次了解到这个需求，但是每个人都会有不同的想法，显然，这里错了。

1、2个小时跟您根本完不成统一意见、达成共识、确定需需求细节这所有的工作。因此需求评审的真正作用应该是在前期沟通充分的基础上作为最后一次的需求确认，得到各方认可，令相关方配合接下去的工作（不要觉得前期沟通太充分，需求评审再核对一遍大家都已经清楚的内容，就像在浪费时间）。

但是还是能够帮助所有项目成员更加清楚了解项目的所有内容，有利于后期的配合，因为单独沟通的时候都是片面的，不可能单独和运营人员沟通过多的技术问题，一起开个会会让大家更好的互相了解。

需求准备：

收集需求：

日常工作中我们需要建立自己的需求池，与用户的沟通，跟踪主要竞品迭代情况，留意市场变化，反复体验现有产品找出待优化的点等工作，应当成为产品经理的日常工作，需要不间断的去做，而不是在产品迭代项目启动后踩开始进行。用户直接反馈的需求是比较有价值的，通常可以从用户的来电／用户在app内的反馈／相关的讨论社区／各种社交群／甚至是成熟竞品开设的讨论群组等（不仅可以了解用户反馈的需求，也可以探查竞品的部分问题与后续迭代方向等）。

验证需求必要性：

适当的用户调研／竞品分析验证需求合理性，为说服相关方做准备。

迭代排期：

总有无数的需求要做，要按照产品的生命周期去做合理的排期。

讨论会：

初步方案完成后，尽可能的去组织产品内部的讨论会，发散思维，吸收更多的意见与建议（其中可能有你没有想到的哦，团队作战总好过一个人瞎想）。

与需求方沟通需求：

需求是否做？何时做（排期情况）需要及时喝需求放反馈；需求如何做？在有了策划方案后要和需求放沟通，看是否符合他的期望，同时协调需要配合的相关事宜。

需求大致确定后，不确定开发成本的需求，需要额外和技术人员做沟通，即使调整方案。有些技术方面的需求，要尽早与开发达成共识，尽早筹划。比如现有数据库、服务器性能是否能承受后续业务的快速成长等？

需求评审前：

完整的需求说明：

demo图并注释文字的做法会比较好，此外将所有相关的内容（包括流程图、表格、版本管理等）全部整理在一个Axure文件中，并写明需求场景与前置后置需求），会更方便与设计、技术、测试的沟通，避免不必要的反复沟通。

尽可能想清楚所有的细节、准备尽可能完善的文档，（当然了，完美几乎是不可能的，尽力而为吧！不要出大的纰漏）并提前与相关人员沟通（研发、需求放等相关人员），达成一致。减少二次评审、扯皮的概率，避免不必要的背锅。

需求说明文档说到底是给设计、开发／测试人员看的，不管使用什么样的工具、格式，最重要的是看文档的人能够看明白能够接受，方便他们工作，不妨在交付物交付后询问一下他们的意见与建议（对于需求文档而言，这些相关工作人员才是用户啊，以用户为中心，产品经理时刻牢记！）

提前发出文档：

可能有些时候文档来不及提前完成，但是没关系。合理安排时间，尽量提前完成文档，完不成就先把初稿（需要完成大部分内容，少数细节未完成影响不大）完成发给大家看，目的并不是过细节，而是希望在需求评审前大家对接下来的项目要做什么内容，为什么做达成一致（目的认知上的不一致，根本就不可能聊到一起去。）

需求评审中：

step1：说明此次迭代／产品的主要目的是什么

让大家对项目有一定的了解。

step2：需求简要说明（告诉大家项目范围在哪里）

常用xmind，mindmanager等工具（前面有说整合到阿axure中，凭审批还是可以用原文件，方便修改）。

step3：需求详细说明（配合demo图进行讲解）

step4：最好用自己的笔记本电脑做展示，有问题的地方做标注，帮助会后的修改调整工作。

这部分最好能自己做，虽然会影响会议进程，但是只有自己最了解所有内容，别人帮忙记录可能会抓不住重点。

需求评审后：

评审完成后，修改相关问题后，连同修改内容清单邮件给参会人员，取得最后的沟通协调。如果修改功能过多，且比较重要的，就只能开二次评审会了。

敲定设计时间、测试时间、上线时间。

配合设计是完成产品设计的工作，当中可能会遇到需求的调整问题。

后续工作

到此为止，围绕需求评审的相关事宜就告一段落了，当然在后续的工作中，根据项目的具体情况，可能还需要召开设计评审、测试用例评审、功能评审（一般由开发召开），虽然这些评审会，产品并不是第一负责人，但是按照目前的通行情况，产品经理通常会兼任项目管理方面的工作，因此我们需要帮助设计、测试、开发完成后面的评审工作，特别是在设计与用例评审中，有时会遇到对需求提出异议的情况，此时已定要做好协调工作，保证项目的顺利进展。

总结：

之前大多数的时间，在师傅的提醒下去做一些事，或者说在师傅确定大致迭代目标与方向后做后续的策划沟通工作。同时大部分的需求来源于运营方，所以只要沟通到位就没有大问题了。但是目前的一些需求，来源于产品内部，来源于各位老板，没有比较具体的目标，在产品方向上各有各的想法争论不休（这也是目前公司最大的问题，战略不清，方向不明）并且产品总监，技术总监，上级产品经理都有各自的想法，干涉影响需求确定的工作。此外也有沟通上的一些问题，存在有人固执己见的现象，而我一时之间又找不到说服他们的方法。或许这就是产品助理与产品经理的区别吧！

如何构建产品经理的技能树：需求到底怎么挖（三）

三种需求挖掘法

很多产品经理会特别苦恼，用户明明就在街上、就在身边，但感觉总是把握不住用户的心理。有时聊到他们喜欢的，做出来他们反而不喜欢。有时以为他们不喜欢的，突然哪天就成了爆点。

在有些产品经理的说法里，对需求的把控是要有天赋的。这种天赋更像是「悟道」一样，总是能对用户的心理信手拈来，一拈一个准儿。这叫做对需求的sense。

还有的产品经理，会认为用户的需求都是要用大规模的用户研究来获取的。这样的方式会像是工程师、数据专家和心理学家的领域范畴。大家通过一些固有的、科学的方法来得到定量以及定性的需求。

这几年比较流行的一种说法，是产品经理应当「顺势而为」，随便做一个MVP先扔到市场上看效果，关键在于判断用户使用产品的数据，然后得到一些迭代的指导，去慢慢演化。在大公司也有类似的工作方式，也就是常说到的growth hacker，以数据指导产品设计。

我们可以把这三类分别叫做悟道法、用研法和增长法。

这三类方法究竟有无优劣之分呢？当然有。不过对他们的优劣比较的话，可以看出他们适合的场景究竟是怎样的。

首先，对悟道法来说，它强调的是我们要有洞察力，要能理解用户。用这套方法的话（只要能力充分），对需求的把控应该是非常强的。但相对而言，风险太大。

试想下，我们想象自己就是用户，即使想得再完善，都未必真的是用户所想。更不用说，有很多产品面向的都是无数大众，把控他们的想法是难上加难。

本质上来说，悟道法就是以「我们的人生经验」去判断用户。如果我们是建筑行业从事 50 年的老专家，我们去把控建筑行业用户的需求，可能真的是手到擒来。但要让我们一下搞明白二次元用户的需求，可能没多少人敢说自己有十年深厚的经验。所以这个方法跟我们的人生经验有关。

另外，作为产品设计者，确实存在一种说不太清的sense，这个sense在一些公司被称为「快速转换成小白用户」或者「以小白用户角度去想事情」的能力。这样的能力，看似简单，但在我从业这些年的观察里，能做到的产品寥寥无几。大部分产品经理都只能看到表面，难以直指重心。

对年轻的产品经理，用悟道法去提炼需求是很危险的。这也是为什么我们常常听说有创业者仿照乔布斯的方法，想出新主意，说「这肯定有需求的」、「做出来用户肯定喜欢」，但最终效果不佳的原因。

其次，用户研究囊括了很多专业的、技术性的方法，这些方法大都已经有成型的、成体系的知识框架了。其中有很多方法，比如问卷调查、用户访谈，都已经融入到大大小小的公司之中。

对于用户量较大、用户群体复杂的产品，用户研究肯定是必备工具。在这种场景下，仅凭产品经理或者需求分析师去死磕是没意义的。

不过用户研究也有缺点。定量的研究会有数据上的陷阱和偏差，而定性的研究实际上又跟执行者的水平息息相关，也容易出现偏差。

最后，MVP 和 growth hacker 这些概念的火爆，是有其时代背景的。互联网产品的快速迭代提供了快速检验的可能。既然能低成本检验了，那在设计之前去花大量人力、物力钻研有什么意义？直接做就好了。

在迭代过程中不断发掘真实的需求，来优化产品，基本已经是现在产品设计的共识了。

关于这三种方法，可以看这张表：

这么看的话，大概也就清楚了——这三种方法并不是非此即彼的，而是要适当配合的。

所以，最合适的关系应该是这样的：

我们通过个人的经验判断，得到基本的一些思路和想法，再去用相对严谨周密的用研方法确认，然后用 MVP 、黑客增长以及其它的实践方法做检验，从结果中再继续做判断……周而复始，也就以需求为轴，把整个迭代推动起来了。

在不同的产品和公司，这三者的形式可能各有区别，但都缺一不可。

比如，我见过有的朋友想做某个领域的产品，会不断去推演和琢磨用户可能有的需求，花很长时间去考虑需求的情况、以及如何满足。但却始终不去做确认，也不做验证，只是拿已有的这套东西，做出很完整的产品方案，直接丢给了某个外包团队开发了。这就相当于完全使用悟道法，不考虑用研，也不考虑迭代。

有家公司则不是这么做的。

他们先通过自己和身边一些朋友的生活工作中，发现了大家有云盘存储的需求（了解需求）。接下来，他们没有直接设计产品，而是把产品的主要特性制作成了一个广告视频，在网上投放，用户瞬间激增（验证需求）。最后，他们真的把产品做出来，在不断迭代后，大获成功（实践需求）。

这家公司就是著名的Dropbox。

需求挖掘可以依照这样的路径，那每个步骤里我们应该做什么呢？

对于「悟道」，前面提到了，更多的是依据经验来判断。一个人能想到的需求、做出的判断，是跟他的视野有直接关系的。从这个方面说，并没有太好的速成途径，需要的是不断学习、不断了解。

不过在这过程中，对需求做初步判断还是有方法可循的。

悟道法：需求的初步判断

不管是从什么方法得到的需求，实际都是用户的一种属性，是想表达用户期望的一件具体的事情，因此它会有几点原则。

1、需求一定要是确定的

既然需求是由人产生的，那就的确有很多需求是不确定的、波动的、无法捉摸的。

最常见的大概就是人的感情（严格来说，人的情绪也是能在生理和神经机制上被描述的，但要想搞清楚仍然很难），尤其是爱情。

比如，有的朋友想要做恋爱培训的生意，他的确是情场高手，也熟知女性心理，这似乎是个好点子。不过，具体要满足什么需求呢？

市面上能够看到的教人追女生的、以及做 PUA 的各种产品，没有一个敢打包票说，可以满足一个男生追到某个特定女生的需求。为什么不能满足这样的需求？因为这个需求本身是无法确定的，对象女生的情绪、她的状态是无法把控的，这样的需求就不能构成产品的可行性。

所以，我们看到，大部分这样的产品，都是从提高男生魅力、提高男生社交技巧这个角度出发的，这些都是可控的、确定的能满足的需求。

2、需求一定是要客观存在的

有很多朋友会强调说，「我认为这个需求肯定存在的，就算冒天下之大不韪我也要把产品做出来」。这样的话是没意义的，因为做产品就是为了给用户创造价值，要是当前无法确定用户真的有这样的需求、无法确定需求的客观存在，结果就只是自嗨而已了。

有几种情况下的需求不能算是客观存在的。

只是自己的主观臆断。是凭借自己的推理得到的，而不是通过个人体会和观察得到的。
是自己的特殊需求，不是别人的需求。只有自己期望用这样的产品，就像我在之前文章《如何构建产品经理的技能树（一）》里提到的。
现象存在，但推理得到的需求有误。像现在胖子越来越多了，看似健身和减肥的需求也同比增长，可实际上这些胖子里有多少并不需要减肥，没有搞清楚。

有时，我们在设想需求上花的时间过少，导致我们没有去细想需求是不是客观的、真实的。我们基于一个错误的前提去继续做分析，自然就会得到错误的结论。

3、需求是现象背后的原因、原理，而不是现象本身

我们只满足现象表现出的用户要求（want）并没有意义，我们要满足的是这背后的用户需求（need）。

那个经典的段落还是可以放在这里再讲一遍。

有一个小旅馆开在大学旁，老板每晚都会接待很多大学生情侣。这些大学生情侣来做什么大家可以想象到，只不过他们碍于面子，都隐晦地说是来上自习的。

老板看到了现象，的确是情侣会来上自习，于是得出了结论：要更好地满足他们上自习的需求。于是把小旅馆房间里的床铺搬走撤掉，把写字桌加宽加大，配上高级的台灯和座椅，试图更好地赢取大学生来上自习的市场。

结果呢？旅馆很快就关门大吉了。

这虽然是个段子，可是类似的尴尬故事在现实生活中仍然处处可见。

诺基亚当年嘲笑苹果的 iPhone 发布会，关键不在于他们高傲自大，而在于他们没有理解用户需求已经在发生转移了。

电话和短信作为功能手机的核心功能，在智能手机上只是配套功能而已。在这样的背景下，通话质量和稳定性、电池容量，甚至包括能不能砸核桃，都没那么重要了。

从表面上，手机还是那样的手机，但实际上，现在手机满足的完全是另外一些用户需求了。

再拿手机举个例子。

如果有一家叫凤梨的牌子，也做了一款手机，并且配置、体验样样都远超苹果，是不是就能替代苹果了呢？

我们要知道，有一批苹果用户，他们买手机并不是为了配置和体验（即使同时也获得了它们），他们只是为了彰显身份、提高自己社交的身份。对于他们来说，性价比再高的凤梨，都不会考虑的，除非凤梨能够替代苹果，成为精英人士们的标配。

总的来说，一定要满足这三个条件，我们才可以谈需求，才可以找到需求、悟到需求。

另外，在「悟道」的阶段，除了个人去反复在自己心里推演，我们常用的还有头脑风暴的方法。可以找了解背景的朋友，或者产品同事，一起集中讨论某个特定主题的需求，把需要考虑到的碎片化的信息尽量枚举完全。

在头脑风暴中，可能就用到比较流行的分析思路或者工具，比如：

思维导图
SWOT
时间推演
场景化故事
6W2H
用户画像
…

其中，亲和图（Affinity Diagram）可能是我认为比较有效果的呈现方法。亲和图看似很高端，实际也就是我们平时所用的在白板上罗列要素，去讨论相互关系的方法。亲和的意思是，我们根据所列内容的相似性去进行整理和归纳，以便形成结论。

总之，无论是用个人的思想实验，还是集体的头脑风暴，一定要用纸笔或者白板可视化地呈现，否则效果会大打折扣。

用研法：需求的检验措施

用户研究方法有多种多样。网上流传的一个汇总大概是这样的：

这些方法有定量的，也有定性的。有相对复杂的，也有很简单的。那这么多的方法，究竟该如何推进呢？哪些方法该用在哪些地方呢？

我们回到需求挖掘的本质上。需求挖掘的整个流程就是我们要对需求逐步把控，从「隐隐约约感到似乎有需求」到「完全搞清楚需求的细节」，是层次分明的。

刚才所说的三种方法的交替，实际就是「发现需求」、「验证需求」、「实践需求」的过程。在用户研究，也就是验证需求这一步内，我们也可以有这样的交替步骤。

观察法：知道可能想要什么

先说第一步。

我们是不是应该一开始就发问卷、做访谈，到处搜集信息？

当然可以，但是问卷里用哪些题目？访谈要问哪些事情？

举个例子。我们想做一个健身训练的产品，我们意识到现在社会消费升级、中产阶级和白领都对健身有了更强的需求，我们认为这方面是有很大市场的。可是我们如果即刻发问卷，问大家会不会用这样的产品、需不需要健身，对我们的需求分析是毫无意义的。因为我们并没有具体想了解的事情，得到那些粗略和模糊的回答也是毫无价值。

我们应该首先要做的，是先看目前大家健身方面的需求是怎样得到满足的。他们有多少人在健身房，他们都是怎么去健身的，他们健身的时间、流程大概是什么样的。另外，现在有多少健身房？健身器材的市场近几年发展如何？

再细致一点，我们还要观察每个人健身的痛点在哪里。是不是有经常加班、时间很紧张的状况？是不是很多人经常坚持不下去？他们的目的是希望减肥，还是希望更健康，或者是期待练出一排肌肉？

观察能够让我们知道，现在正在发生什么，知道用户可能想要什么。然后我们就可以对感兴趣的一些点，进行下一步的探究。

有的产品经理可能会觉得，这些判断岂不是很主观的？把这些所有可能存在的问题，包括提到的健身流程啊、健身的目的啊、痛点啊，都放在问卷里让大家填，不应该是更准确的吗？

这种想法过于理想化了。

首先，一个问卷的问题类型，是越简单越好。通过观察，你可以了解健身相关的各种信息，就可以用选择题的形式来出问卷。如果是访谈，也能问得很精准。

换句话说，应该是信息了解得越多，出的问题就越准。如果你观察到大家健身的目的主要就是三种，几乎不存在第四种，那选择题就可以有四个选项。反之，你没有观察到这些信息，可能就需要让用户填空，或者提供很多想象的可能性，选择就不止四个了。

其次，观察得足够多，我们就能知道我们关心哪些问题。有很多问题在观察的时候都已经解决掉了，或者我们判断是不感兴趣的，对我们分析需求没有帮助的。这样在设计问卷和访谈的问题时，就能大大缩减数量，节省用户时间。

我们每个人都曾经填过问卷，有些人也接受过访谈或者街头调查。试想下，有一个产品希望你帮忙填写特别大部头的 100 题问卷，有填空、还有很多问答题，想问你关于某件事情方方面面的观点，和你只需要快速填写 10 个选择题，你更容易接受哪种？

观察法的形式也是多样的。可以直接到街头观察，或者有条件的话，邀请用户到某个观察室进行观察。具体要用哪种方式，是要根据产品而变化的。像我们如果做一个打车软件，那观察用户平时如何打车、叫车，就不能请他到室内了。而看一个用户平时是如何上网使用浏览器的，在室内观察并用电脑做记录则更加合适。

用这样的观察法我们能知道，现在用户是如何满足他们的需求的。

我们现今所做的需求几乎都是客观存在的，也就证明过去用户都有满足这方面需求的方法。虽然移动互联网带来了很多新的产品和功能，但本质上都是满足了已经存在人类社会很久的需求。像 BAT 分别满足的是信息获取、消费和社交的需求，只是相较过去的笨办法，它们更加有效、成本更低、体验更好。

有的产品经理会错以为需求都是产品创造的，既然以前没有这样的产品，那它横空出世大家都会喜欢。这显然没有道理。

因此，总结下来，我们在观察法这一步要做的事情就是：

知道用户现在是用什么办法满足我们设想的需求的
知道其整个流程和相关的状况
分析其中可能存在的问题、痛点等，为下一步做准备

调查法：知道真正想要什么

接下来就是耳熟能详的调查法了，其中最常见的是调查问卷。

在这一步，我们要做的主要是定量地验证一下发现的需求。

定量指的是要知道数量上的一些状况，包括但不限于：

目标用户不同属性的组成如何（男/女，高收入/低收入，年龄等）
用户目前用不同方式满足需求的比例是怎样的
用户在需求方面最关注的点有哪些
用户最不满意的地方（痛点）有哪些
以你想象的新的方式满足用户，有多少人能接受
……

这些是常规的几大方面，在具体操作中，也会有很大不同。

对调查法来说，由于大都是量化的数据，因此对数据采集、数据加工和数据分析都要时刻保持警惕。

以问卷调查为例，有些陷阱需要注意：

1. 对数据真实性警惕

如果是观察或者访谈，我们是能够直接了解用户当前的状态的，在判断信息时，我们会有所侧重（比如有的人表现得很随意、不用心，我们就不会太看重他的意见）。而调查问卷这样我们无法直接接触用户的调查方法，我们就不知道那些信息是相对真实的、哪些是随便填写的。

因此，不管是投放的时候，还是收集结束要形成结论的时候，都要考虑，这些数据是不是真的有效。

2. 对问卷题目的误导性警惕

问卷题目的制作其实比很多人想象中要复杂得多，并不是想到什么问什么，就能得到真实的回答。

例如，有的学者曾经做过实验，「如果有人犯了 XXX 罪，你会杀死他吗？」和「如果有人犯了 XXX 罪，你会同意判他死刑吗？」看似是差不多的问题，但在调查结果上，却是天壤之别，结果几乎差了 4 倍多。

再比如，这两个问题「大家都说特朗普会是不靠谱的总统，你觉得是吗？」和「你认为特朗普会是靠谱的总统还是不靠谱的总统？」得到的结果也是截然不同的，前者会有强烈的暗示。

关于如何制作问卷方面的知识已经非常成熟了，有很多课程和书籍可以参考。

3. 对意料之外的影响因素警惕

对于大量分发的问卷，即使问卷题目没有问题，也会存在其它意料之外因素的影响，比如社会文化因素。

有的问卷是关于调查情趣用品使用情况的，那女性就普遍不太愿意填写，最终很容易得到男性使用情趣用品远多于女性的错误结论。

或者填写问卷的人是有另外的企图。像有的电商平台如果发问卷询问大家，怎样的折扣是大家能接受的，结论可能是 5 折才能接受，但实际上大家平均 8 折就会来购物了，只是都希望问卷的结果能影响电商平台多给优惠。

总的来说，在这一步要做的事情是：

定量地去看用户是否真正存在需求
验证之前观察和思考的结论是否正确
确保调查的准确性和真实性

焦点小组/访谈：知道为什么想要

需求分析在最后阶段，总是要跟用户见面、聊天的。如果哪个产品经理从来没有跟自己的用户说过一句话，那这样的产品经理是绝对没可能做出好产品的。

确认了需求真实存在、哪些需求是用户最关注的，我们实际是缩小了要考虑的需求范围。针对已经确认的这些，我们要把从广度的用研，转为深度的用研。

焦点小组是多人的形式，适合我们跟一些核心用户讨论拟定的关于需求、功能这样的主题。焦点小组需要专业的、能够有效引导大家的主持人，确保话题保持在预期的框架内，也确保能发掘出大家的真实想法。

至于为什么不直接用一对一访谈，是因为通过焦点小组我们可以再做一层过滤。在焦点小组这样的氛围中，我们能知道主要用户们之间的异同点。有分歧的可以继续探讨，对于大家一致认同的点，我们用访谈形式去继续深究。否则，因为访谈的对象数量毕竟有限，我们得到的信息仍然是有偏差的。

在焦点小组或者访谈的过程中，我们不仅要反复确认对方的需求，同时也要尽力发掘他们需求背后的本质。就像我们召集了一批希望健身的用户，我们要在这一步搞明白他们为什么需要健身，以及为什么存在那些痛点等等。

总的来说，大概就是这三类核心的用研方法，能够让我们对需求的认知由粗到细、由浅入深。

关于增长法和 MVP 等方法，已经是需求和设计强耦合的流程了，因此我们放在后面单独讨论。