本文 2020-10-30 首发于公众号【一个数据人的自留地】。

1、驾驶舱的产品设计都有哪些坑

什么是 BI 驾驶舱？

近几年 BI 驾驶舱兴起，有很多名词：“BI 驾驶舱”、“决策驾驶舱”、“管理驾驶舱”，在网上随便搜索一下，能找到很多概念。我们先查看业内主流的 BI 驾驶舱定义，如下：

商务智能驾驶舱，顾名思义就是商务智能，也就是说当大家在日常操作的过程中，能够有效的寻找到如同驾驶飞机一样的感觉。这个系统是专门为企业管理而设计的一个 BI 分析系统，它是为企业高层创建的虚拟办公场景，有利于更好的决策，它是一个基于业务数据的高级决策支持系统。

可以看到，BI 驾驶舱表现形式上就是 BI 看板（Dashboard），从业务含义上说，它是一个跨业务条线、面向管理决策的数据关键指标聚合看板。关键词：面向决策。

0 到 1 阶段产品设计中我们遇到的坑

• 真实需求难判断、需求蔓延

找用户调研，用户其实也说不清楚具体有什么需求，就是感觉很多数据指标都要看。虽然一开始我们只想做核心指标，但收集需求后，发现需求很多、指标越做越多。

• 产品解决方案、产品规划没有切中要点

解决方案不够好，导致做了产品规划，但 1.0 版本上线后，其实对决策指导意义并不大，2.0 难以推进，最终沦为了“面子工程”。

• 团队共识问题

当团队对产品设计质疑的时候，如何说服开发同学保证核心指标的上线呢。有时候也可以用来与用户/客户达成共识。

如果 0 到 1 阶段，这几个问题点做不好，那么在升级迭代的时候就会遇到更大的问题。其实这些大部分问题，都是产品方向、需求梳理的问题。

今天我们谈一下，使用用户故事地图是如何解决从 0 到 1 的产品设计及后续产品功能规划的。

2、什么是用户故事地图，如何使用？

什么是用户故事？

用户故事是敏捷开发中的常用概念。Scrum 中文网《用户故事》的解释如下：

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1. 角色：谁要使用这个功能。

2. 活动：需要完成什么样的功能。

3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：

英文：

As a , I want to , so that .

中文：

作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例：

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。

用户故事的固定格式是：

“作为……（用户角色），我想要……（完成活动），以便于……（实现价值）”。

形式上以卡片居多，类似下面这样：

或者这样的：

以敏捷开发来说，完整的用户故事还要包括验收标准等其他内容，还有很多细节要求，比如用户故事不能太大，要尽量细分等等。因为本文主要讲使用用户故事地图来进行产品需求的收集、梳理，所以对于用户故事的介绍不展开太多，感兴趣的同学可查看文末推荐资料学习。

用户故事来描述需求有什么优点？

用户故事能够迅速的把需求目的、需求价值描述清楚，在进行需求调研时，通过整理出这样的格式，能够避免产品经理把功能点、解决方案误以为是需求。

看一个例子：我们常常听到用户（需求方）对我们说：

“你给系统加一个每小时生产效率数据”——这个是功能点

“帮我们做一个可以对比分析的生产效率指标的工具”——这个是解决方案；

“作为一个运营管理人员(who)，我想要需要关注产线效率（what)，以便及时干预效率降低的情况（value）”——这个是用户故事。

什么是用户故事地图？

用户故事地图顾名思义是将用户故事组合成的，由于地图中的每一个用户故事，都是比较清晰的需求点，所以用户故事地图可以既能看到需求全貌又能看到每个需求点的细节。因此我们又说，这是一个“既见树木、又见森林”的好工具。

一般的用户故事地图有手工的，也有软件工作制作的。软件制作出来的用户故事地图：

手工的用户故事地图：

用户故事的优点在于：

1.可以清晰需求的整体全貌，和每个需求的场景；

2.帮助你避免需求的混乱、遗漏，理清楚需求之间的关系；

3.能够直观地进行需求的分级、方便下一步长期产品规划；

如何制作产品的用户故事地图

用户访谈

推荐和团队成员一起进行用户需求访谈，因为产品从 0 到 1 的需求调研十分重要，团队成员一起做，可以保持后续对项目完整性、全面性的认知。团队共同制作用户故事地图，推荐使用白板+便签的手工方式，将用户故事卡片，粘贴在上面形成你们自己的用户故事地图。

调研方法上举例：

分析 BI 驾驶舱需求的时候，大多数会将用户故事按照时间线进行张贴组成用户故事地图。比如：

如果是面向业务管理决策的（管理层 BI 驾驶舱），那么你可以去访谈对应的业务线“老板的一天”，如果是面向财务部门专业决策看板（如公司财务业务 BI 驾驶舱），那么你可以访谈“一个财务人员的一天”。把用户这一天中每一个需要决策的动作，转化成用户故事，再张贴到用户故事地图上。团队可以讨论、投票需求的优先级。

（也可以视业务实际情况，按照流程节点顺序进行用户故事地图的整理，案例文章：人人都是产品经理：《后台产品设计系列：用户故事梳理地图梳理需求（七）》）

提炼产品解决方案（功能/数据）

首先，对每个卡片提炼出核心的功能点、数据。

我们通过一次用户故事地图的制作，会得到很多故事卡片。需要将故事转化为功能点，由于我们是做的 BI 驾驶舱产品，就要区分出哪些属于我们这个产品能满足的故事卡片，在众多的故事中，有一些是数据相关的，有一些则不是，在这个阶段需要区分清楚。

第二步，将解决方案以数据指标/功能点为核心进行整理、转化。

对数据相关的故事，列出对应的关键数据。一般来说都会有重合的，对重复的指标进行去重、整理。

如果是一个指标覆盖到了多个故事卡片，那么他的优先级会相应变高。如果一个指标覆盖的卡片较少，如果期对应的故事卡片优先级也不高。

做完了这 2 步就能得到一个有数据、有功能点、优先级的功能列表啦！产品设计最难的部分--需求收集、功能设计（数据指标）就完成了。

第三步，功能分组，产品版本规划

产品规划本质上是将功能点进行优先级划分，分成这一期和下一期的功能群组。

我们通过用户故事地图得到的功能点，组合成 BI 驾驶舱的解决方案后，可以和研发同学讨论。

由于我们是通过用户故事地图组织的，所以研发同学能够清楚地看到第一期和第二期的功能点分布，并且可以看到每一个功能点的细节。他们很方便就判断出第一期的功能点群组的大小，可以大概估算出是否能在预定时间完成产品的开发。

产品规划是一个动态调整的过程，重点是先做好 0 到 1 版本的功能群，其他的则可以放到后期功能规划，作为需求池的一部分。

3、实战：设计一款家庭厨房的 BI 驾驶舱产品

下面我们以要给家庭的厨房制作一款 BI 驾驶舱为例。

我们假设家里已经有了厨房 ERP、家人订餐 APP 等业务系统，厨房已经具备了基本的数字化，现在我们要增加一个 BI 驾驶舱。用户是家里的大管家——奶奶。

产品目标分析

首先我们分析，在厨房基本都是围绕为家人准备一日三餐的饮食上。

我们要围绕这个主题进行驾驶舱设计，就要先去了解一般都会遇到什么问题，哪些问题是可以通过数据来解决的。

用户故事地图制作

在一个周日的上午，我们邀请奶奶来到客厅，访谈的工具就是用户故事地图。

请奶奶聊一聊一天的一日三餐都是怎么准备的，我们准备了白板、便签、签字笔。

一切就绪，先在白板上画下一条线，按照大致的时间线做好标记：

然后开始请奶奶从早餐的准备说起。

前一天晚上我会看一下厨房有什么食材、冰箱里面有什么半成品，比如有包子、饺子、面条，然后问家里人，早餐都想吃些什么，想吃包子，还是饺子，根据大家的意见决定明天早餐，比如都是吃饺子，不能有人吃饺子有人吃包子（做不过来）。

从这段描述中，我们可以得到 2 个用户故事：

故事 1：“作为给大家准备早餐的人(who)，我想要在关注厨房的食材/食物储备情况（what)，以便及时提供第二天早餐可以吃什么的备选（value）”

故事 2：“作为给大家准备早餐的人（who），我需要在晚上准备好第二天的早餐备选菜单（what），以便提前沟通让家里成员得到第二天早上确定的早餐菜单（value）”

早餐结束后，奶奶要去买菜了：

做完早餐后，差不多 9 点我就要出去买菜了。

买菜的时候，我想着午餐和晚餐要做什么菜，看下今天菜市场有什么菜，可以和冰箱里的已有的食材搭起来的，这两天才吃过的就不买了，因为总得换换口味。

这个时候你可以追问一些细节了，比如“一般我们都做几个菜呀，怎么定呢”。

奶奶回答说：

中午儿子媳妇都在单位吃，家里就我们老两口和孙子，简单点一荤一素就行，不过如果他们有时候回来得提前和我说，要多准备一个菜。晚上儿子媳妇回来都在一起吃饭的话，就一般是一荤两素一汤。周末就要更丰盛一些，加一个荤菜了。

这样就又整理出来了以下故事：

故事 3：“作为准备午餐和晚餐的人（who)，我想要知道每次吃饭人员数量（what），以便在进行菜单规划的时候，能够明确到底要准备几个菜（value）”

故事 4：“作为采购食材的人（who），我想要关注厨房的食材/食物储备情况、近几天家里已经吃过的菜（what），以便在买菜的时候考虑我要买什么菜（需要能利用起来已有的食材，不做重复的菜式），还可以让全家饮食多样化、营养均衡（value)”

故事 4 有点大了，我们还可以拆分一下：

故事 4.1：“作为采购食材的人（who），我想要关注厨房的食材/食物储备情况（what），以便在买菜的时候考虑我要买什么菜（需要能利用起来已有的食材）（value)”

故事 4.2：“作为采购食材的人（who），我想要关注近几天家里已经吃过什么菜（what），以便在买菜的时候考虑避免才吃过的菜，能够让全家饮食多样化、营养均衡（value)”

奶奶又补充道：

偶尔饭桌上聊天，会问大家都想吃什么菜呀，比如现在冬天了，我会和大家说现在是吃羊肉锅子的季节了，想吃的话我就去买，周末给大家做。

我们得到了一个新的用户故事：

故事 5：“作为准备午餐和晚餐的人（who），我想要关注现在时令都适合吃什么菜（what），以便和家里人吃饭闲聊的时候一起讨论想吃的新菜品（value）”

这个时候，我们把这几个故事在白板上，按照时间顺序贴好便签：

提炼产品解决方案（功能/数据指标）

我们得到了 6 个用户故事卡片，现在开始提炼每个故事卡片的产品解决方案（功能点/数据指标），同时我们把卡片上场景相关信息也列上，得到一个大致的清单 1：

对清单 1 进行去重、合并，得到一个以数据信息为中心的列表(数据放在了第一列，注意这里我们把故事 2 按照数据角度拆分成了 2 行)：

现在我们得到了一个解决方案，这个 BI 驾驶舱提供的功能/数据有：

1、厨房库存 SKU 列表（可以是 TOP5）

区分主食类和非主食类。【覆盖 3 个用户故事，优先级：高】，数据源：厨房 ERP。

2、今日每顿用餐人数，分三餐显示

【优先级：中】，数据源：订餐 APP。

3、近 3 日历史菜品（去重）显示

【优先级：中】，数据源：订餐 APP。

4、菜单智能推荐

【优先级：低】智能化的功能。根据当前的库存食材、近几天已经吃过的菜，还加上目前季节时令养生等策略，推荐合适的 3-5 个菜品。

5、季节食疗资讯

【优先级：低】有 2 种方式可以做：

A.从外部数据源获得信息加工后，聚合成食材菜品推荐列表，可以和 4 一起做成智能菜品推荐（菜品+推荐原因）。

B.展示外部热门养生食疗文章标题，展示 3-5 篇。

产品功能规划

我们分析 5 个功能点，发现：

1-3 属于数据需求，并且数据源都能确定，并且需求点 1 覆盖了 3 个故事，优先级较高。

4-5 属于进阶需求，用户不是刚需，但是能提供的话会更好。

如果我们做产品规划，可以按照以上角度将需求进行分组：把 1-3 放在第一个版本实现，4-5 可以放在第二个版本中。（也有很多种功能分组的方法，关键看对产品方向和核心目标的理解，本产品主要是解决决策所需的数据内容，所以 1-3 就分成一组了）

PS，当然也可以和算法同学商量，他们是否能在第一个版本内做出来菜单智能推荐算法。

4、总结

经过一番简单的实战模拟，应该可以看到用户故事地图在我们进行 BI 驾驶舱产品需求设计中的作用了：帮助产品经理及其研发团队，理顺需求全貌。总结下来是三步：

制图：根据产品目标，制作用户故事地图（推荐使用用户访谈、白板工作坊的方式）。

提炼：将用户故事卡片进行整理，提炼出产品解决方案和数据信息，完成数据视角的转化。

分组：功能点按照一定规则进行分组，不同组别纳入到不同的产品迭代中（产品规划）。

用户故事地图本质上是以用户场景为核心，梳理出需求的全貌。从 0 到 1 进行产品设计之所以难，是因为大多数产品经理都只是面临一个方向：如何着手、如何细化、如何在产品设计中不跑偏，都是我们要时刻关注的问题。

对用户故事地图感兴趣的朋友，欢迎阅读以下的参考资料。

书籍推荐：

《用户故事地图》

文章推荐：

人人都是产品经理《用户故事》系列文章

后台产品设计系列：用户故事地图梳理需求（七）

Scrum 中文网：要写封闭式的用户故事