产品经理须知的三点用户需求分析|163

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

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

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

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

1. 报表的三要素

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

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

报表主题

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

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

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

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

报表指标

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

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

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

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

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

分析维度

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

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

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

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

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

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

2. 报表展现形式

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

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

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

3. 报表的穿透

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

业务需求（ Business requirement ）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。
用户需求（ user requirement ）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
功能需求（ functional requirement ）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求

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