一个宏大的功能，是如何被设计出来

当我们决定要做某个功能时，就进入到产品经理基于对需求的理解从而进行功能方案设计的环节。

场景和需求方面的不再在本文赘述，本文只讲讲功能方案设计的过程。

01 Epic？

如大家所知，敏捷项目管理会把 Feature 分为「Epic」和「Story」两种级别。

Epic 是多个 Story 的集合，来描述一个非常大的功能。比如甘特图、地址字段等。这些 Epic 都至少可以拆分为一个 MVP 版本的大 Story 和后续修修补补的小的 Story 则单独进行发布。

继续用甘特图这个例子来讲，我们在 Phase1 的 MVP 阶段只需要通过“起始日期”、“结束日期”来生成甘特图以展示项目在时间轴的进度情况。

而对于像是“甘特图可以按照某个字段进行上色”、“甘特图中可以对任务进行分组显示”、“可以拖拽完成起止日期的设置”等需求都被拆分成了后续的 Story 单独进行发布。

这样做的好处是，尽量缩短一个大功能的发布周期，避免花费资源做了对用户价值不大的功能。

敏捷和瀑布的优劣势这些太基础的也不多讲了，直奔重点聊聊当我拿到一个 Epic 功能时如何应对。

依然求生欲满满地再声明一下，本文仅代表我个人主张，不代表公司立场。

02 阶段说明

我会从四个阶段开始推进一个 Epic：思路整理、初步方案、Phase1 整体方案、验收用例和交互细节。

这四个阶段结合了产品经理和交互设计师常用的英国设计协会的「双钻模型（Double Diamond）」和 d.school的 IDEO设计思维，梳理成更加符合黑帕云产品功能设计节奏的方法。

不难看出，上面两个思维的方法都是先发散再收敛，再发散再收敛，最终到推进功能的开发阶段。

从每周的发布功能数量上就可以清楚地了解到，黑帕云是一个高效的产品型公司。我们有三位产品经理，两位设计师，虽然大家所负责的都是不同的产品线，但是每周还是需要定时定点碰头开个讨论会，会上由负责人讲解需求的背景和功能设计的方案。

在 CEO 陈金洲先生（公众号：米高说）的多次强调下，为了保证产品讨论会的高效性，很多过程产物都不会在这个会上进行宣讲和讨论。（比如各种脑图、流程图……）

在进行产品设计之前，都属于「响应用户需求」的阶段，具体从「提出需求」到「采纳需求」的分析见之前写过的这篇如何响应客户的需求。

1. 分析研究

拿到 CSM 给到资料后，就开始进行一些分析研究的工作了，这个阶段是发散的阶段，需要尽可能去挖掘清楚用户的问题是什么，业务上有哪些上下文，竞品的动作等等，最终会有一些零碎的、非结构化的研究结果。

但在这个阶段，我一般不会形成书面的材料，只会丢进 eagle 或者语雀小记这种便签，随手记下来。方便快速记，也便于快速找到并翻看。

2. 思路整理

分析研究的差不多之后，大脑中已经开始形成问题的雏形。接下来要做的事情就是把这些想法开始聚焦到问题上，定义出对用户最有价值的，技术成本相对不高的核心要解决的问题。主要在宏观上进行需求分析，大体思路整理。不过也会形成一些快速的想法，但还是主要整理当前的问题、现在的限制。再根据这些问题快速尝试解决方法，不会考虑细节，也不会在这个阶段思考交互和呈现，也不会思考 phase1 阶段计划做哪些。

到了这个阶段之后，就会有一些低保真的图可以来表示思路了，也可以在会上讨论了。在讨论时，需要关注解决方向是否合理，是否技术受限，是否可行。

3. 初步方案

在思路整理结果的基础上，我会开始做一些设计的探索，开始发散不同角色视角的界面呈现。

这个阶段会框定方案范围，会写写功能逻辑，并以真实场景模拟的中高保真程度界面展示（辅助描述功能，表意组件之间的层级结构，但不代表界面设计方案）。在这个阶段不关注界面设计是否合理、文案是否优雅，而是要围绕需求层面以及功能的方案设计，通过两三次的讨论，吸收会上大家的反馈，再去突破和审视，并且避免遗漏业务场景，从而做出设计方案的最优解。

4. Phase1 整体方案

在初步方案讨论后，将以一个最小最简单的业务场景进行收敛，并且框定 Phase1 的整体方案。框定依据是会模拟一个真实场景，去走一遍这个场景下的业务，看看初步方案是否能够符合，再从上一阶段的方案中进行功能裁剪，将范围缩减至最小。再将其他功能拆分出来，安排到后续的版本迭代中。

栗子：比如“地址字段”功能 MVP 在订单场景下，满足填写收货人地址、筛选收货人地址即可。分组和统计需求则可以拆分到后续的迭代中。这个阶段的重点将不再是多场景，而是要评估所选场景是否合适，以及功能设计和 Phase1 的范围是否能满足所选场景。

5. 验收用例和交互

最后的阶段主要是 Story 的拆分和细节的验收标准（Acceptance Criteria，简称AC） 书写，我们一般这个阶段就不会在产品讨论会上和大家同步了，一来细节太多，二来没有必要讨论，第三浪费大家的时间，所以讨论价值不高。

一般一个 Story 的颗粒度是以可以交付到客户手中的价值（也可描述为可进入完整测试）作为标准。拆分 Story 的过程中，需要将 AC 描述清楚，开发在 Show Case 时，会按照 AC 逐条展示。

AC 需要描述用户的使用路径，什么角色看到什么入口，点击之后会发生什么。除了正常的逻辑，还需要包含一些异常逻辑的处理，比如数据量超出 X 条时，不允许复制数据。除了期望功能外，还需考虑其他相关的影响。

例子：比如成员字段开启「允许使用多个成员」，功能期望为在填写成员字段时，可以添加多个成员。相关的影响有：筛选条件中的如何筛选多成员字段、增量导入数据如何识别多成员、分组时能否分组、能否按多个成员生成图表等相关处理。

在这个阶段会尽量避免有遗漏的场景，并且要仔细检查交互是否合理。

接下来会以一个黑帕云在 2021 年 06 月 04 日发布了一个“筛选关联”的功能为例，讲解整个功能设计的过程。

03 需求背景

最早是做汽车后市场的小特科技提出的这个需求。小特科技使用黑帕云来管理他们门店的订单数据。

在之前文章找到数据表中最新的一条关联记录中讲到「关联」，同样的，在订单数据中有这样几张表之间是关联关系：

所以在创建一个订单时，需要填写“下单门店”、购买的“商品类型”最后填写购买的“商品”（库存表），像是这样：