产品之路系列（7） 详细需求分析之功能主线

7 详细需求分析之功能主线

业务流程识别

信息系统的核心价值之一是支持业务，而业务支持的核心是对业务流程的固化、优化和重构。在需求分析时，识别出相关的业务流程是关键任务之一。
下面是业务流程识别任务指引图：

什么是业务流程

企业或组织满足外部客户服务请求的一系列协作就是业务流程，每个员工的工作都属于某个流程。

业务流程的源头是服务请求，它由多人协作组成，需要一些有效的规则进行控制，如果业务流程管理不到位，就会出现三人种树故事里，当种树的人不在，挖坑和填坑的人仍然按照自己负责的部分进行，那所做的事情也将毫无意义。

业务流程图只允许有一个起点，但可以有多个终点。
业务流程有开始端和结束端，也算是一个端到端流程，它有两个关键点

• 完整：服务请求是否被满足或被拒绝；例如客户购买商品和客户刷卡两个流程就都不属于一个业务流程，因为购买商品必定要付款的，单独分开不够完整；

• 边界：注意识别职能边界和系统边界，业务流程不要跨越边界；例如：客户提出一个需求变更，一般需求上线才算流程结束，但是如果系统是一个需求管理系统，那上线其实已经不在它的边界之内，当对需求变更做出处理决定时，流程就结束了；再比如：用户投保一份意外险，保单生效时就是流程结束点，而不是出险或保险到期，后二者已经跨越了职能边界。

业务流程识别关键

业务识别的过程通常采用：先外后内、先业务后管理的顺序进行，根据指引图，可以看到具体分为四个步骤：

• 1 识别外部引发的主、变、支流程，满足外部客户请求通常是产品/服务核心价值所在
  

• 2 识别内部引发的主、变、支流程，满足内部员工或在特定时间、状态下发起的请求
  

• 3 识别管理流程，有一部分业务流程是为了实现控制、监督、管理意图；管理流程识别角度包含：业务审批控制，人、财、物、资源的管控，进度和异常控制
  
  管理流程识别相对会是一个难点，不过通常管理流程不会太多，可以通过与客户代表的交流迅速补充

• 4 判断业务流程优先级，业务流程是系统交付的最小单元，制订优先级有利于做出更合适的迭代计划
  
  一般可以根据使用频率、是否与主营业务相关作为优先级判断的标准，还可以根据卡诺模型来划分

输出物

业务流程列表模板

业务流程分析与优化

在标识出相关的业务流程之后，接下来的关键任务是逐个流程进行了解与分析，绘制出流程图，并对关键流程做适度的优化。

下面是业务流程分析与优化的指引图：

业务流程分层指导

业务流程天然可以分为三层：

• 企业/组织级流程：最宏观，表现的是企业组织部门之间的协作关系，供决策层阅读
• 部门级流程：表现的是岗位间协作关系，供管理层阅读，业务流程分析应该在这个粒度上进行
• 个人级流程：具体岗位的工作步骤，到业务场景分析的时候再细化

判断一个流程图是否过细的两个重要原则：

• 1 是否与协作无关
• 2 是否不是独立可汇报的工作单元

部门级业务流程图示例图：

业务流程八要素

在业务流程分析中，最重要的是理清业务流程中的八大要素，5个基本要素，3个管理要素

• 基本5要素：分工，协作，活动，分支，产物关系；规模、风险、专业带来了分工，分工带来了更加细化的工作任务就是活动，活动之间存在协作，协作可以按顺序进行，也可以是并行或异步进行，在协作过程中会传递工作产物，构建出了产物关系，同时协作过程不是一成不变的，它存在协作分支，分支也是流程图中一个重要元素。

• 管理3要素：异常，审核，规则；流程执行会出现异常，需要制订一些备案，为了尽量减少异常，事先干预的方式就是建立一些流程规则，事中把控的就是建立审核机制。其实还有事后统计，但这个不属于业务流程了，是报表维度需要考虑的事情。

流程分析要点

1 正确选择合适的流程图描述方式：

• 流程图/活动图：强调每个角色执行的活动
• 顺序图：强调个角色间的协作、交互
• 数据流图：强调数据处理过程

2 通过一听二问三读的方法，完整整个流程图的绘制

• 一听：听客户代表描述，以最简单的方式画出主脉络，把分支、产物关系、异常、规则、审批都放在一遍
• 二问：先沿着流程进行发问，看看是否存在分支，然后边问边修正，同时补充产物关系，针对异常、审批、规则等要素进行提问
• 三读：复述一遍流程，与客户代表或领域专家达成共识

流程图心法关键：

• 分工要平级：流程图每个节点的层级应该相同，
• 活动命名动宾结构：所有流程活动节点都是一个工作任务，不能使用名词或名词短语
• 绘制全流程：先不考虑系统边界，画出业务的线下线上全流程
• 从服务请求者开始：从服务请求者开始保证流程的完整
• 主从活动只留一个：每个活动都可以通过主从角度去描述，比如客户缴费和收费人员收费，应该只保留一个(根据流程图的阅读对象考虑保留哪一个)

3 补充事中的管控点：

• 审核：流程中控制的风险审核项
• 规则：流程各环节有什么相关规则，包含协作间规则、活动执行规则、数据规则
• 异常：不按流程进行特殊情况处理，诸如应急流程、绿色通道等，用文字或独立流程图表示

4 分析流程执行过程监管需求
管理者为了更好监督、控制流程执行会有一些相应的管理需求，这时会产生一些功能性、非功能性需求

• 进度与效率监控执行
• 执行异常监控
• 其它管控

流程优化

采用最典型的ESIA策略：

• E 清除无效：找到流程中不产生效能的、浪费的、低效的环节，然后想办法清除
• S 简化高频：对频率最高的环节进行优化，流程效率将上升
• I 整合依赖：将相互依赖的环节整合在一起，提高效率
• A 自动化繁琐：把人做起来麻烦的事交由计算机来完成，提高效率

在整个过程中，我们要利用同理心转换到客户视角，完成两次流程穿越：

• 以自己为独立用户角度穿越一次
• 以自己为不同/团体用户角度穿越一次

输出物

业务流程描述模板

业务场景识别

识别出系统相关业务流程并分析优化后，接下来的工作就是基于流程识别系统中关键的业务场景。
下面是业务场景识别任务指引图：

业务场景和功能场景

作为互联网时代产品经理，相信大家都应该对用例、用户故事需求分析技术耳熟能详了，但是在实践中，真正能正确使用的，还是少数人。大部分常常还是假借用例、用户故事分析，行功能分解之实。特别是由程序员转岗过来的产品，往往陷在功能场景里。

业务场景：站在用户视角，关注其业务场景和使用场景
功能场景：站在开发视角，关注提供什么功能

拿一个教新用户使用照相机的例子，功能场景模式的教法就是一上来告诉他：这个是开关，这个是快门，这个是回放，这个是闪光......，而业务场景模式的教法就是先确定目的，了解用户需求，比如先满足如何拍照和查看照片。

如果直接进行枯燥的功能性描述，只能拒人千里之外，导致与用户沟通不畅，影响需求的获取与理解。而生动的、用户视角的使用场景、业务场景描述，才能与用户产生共鸣，实现需求的获取与理解。

用例产品思维与工程思维

用例分析技术的核心在于用户视角的需求观，强调目的和场景的重要性，而不是技术功能性罗列。
以下是一个图书馆管理系统的用例图，有什么问题？

大多技术出生的产品经理看到后都认为非常合理和正确，但是这是典型的使用了功能场景维度去描述。如果按照这种CURD的方式，那么所有系统的所有功能都可以通过CURD来表示了。

如果站在业务角度，那就要考虑图书馆新增图书到底表达的是什么？有可能是新购买了图书入库，也有可能是之前遗失的图书，突然找到了，然后重新要登记到系统库中。

另外删除图书表达的业务到底是什么？可能是图书遗失了，也可能是图书过于陈旧需要报废了。所以新增图书和删除图书的用例，可以修改为下面所示：

注意：并非所有系统CRUD都不适用，有些偏技术性功能或计算机域系统，可能是完全是适用的，比如购物车功能、数据库持久框架。

用户故事本质

熟悉用户故事的人应该都知道它的标准句式：作为XXX(角色)，希望通过系统XXX(解决方案，功能要求等活动)，以便达成XXX(业务目的，业务价值)

这个句式强行让人站在用户视角去考虑，天然具备业务场景的特性。

用户故事自身具备六个特点：独立性、可协商性、有价值、可估算、简短、可测试

可以说把项目需求拆分成用户故事是很高级的技能，用户故事技能的具体的使用不是本章节探讨的范畴，有兴趣的读者可以参考阅读用户故事专题和相关书籍。

业务场景识别要点

• 基于流程图识别系统角色：流程中涉及哪些用户？对于非必须的用户纳入系统支持有什么价值？不支持有什么不足？系统中这些用户角色是什么？如何抽象为权限系统的角色？

• 基于流程图识别业务场景：对每个活动、分支、判断点进行分析思考，哪些业务活动系统要支持？哪些是部分支持？审批点是否属于系统内？判断点是否为独立环节？

• 补充业务场景：思考特定时间、特定状态触发的业务场景(定时任务，告警提醒等)

• 绘制用例图概述业务场景：可以利用用例角色之间泛化关系，用例之间包含、扩展、泛化来简化用例图，同时要注意用例图的阅读对象

  包含关系表示一定会执行的公共子事件流；扩展关系表示不一定会执行的扩展事件流；泛化表示公共事件流

注意：不要试图利用用例图来表达业务的流程，用例图是表达执行者到底能做什么，流程是管理者关心的角度。

就像开发团队中，产品和测试要专注业务的全部流程节点，而前端开发和后端开发，作为执行者，更关心的是在不同业务流程中，自己负责那部分细节，前端只需考虑调用后端接口的时机，需要提供的参数，以及响应结果，至于业务处理细节，前端人员一般无需知道。

另外也存在一些无业务流程或弱业务流程的系统，服务请求基本上就可以代表为业务场景。

输出物

业务场景描述模板

业务场景分析

识别出系统的业务场景之后，就要以场景—问题/挑战—方案的逻辑来分析每个业务场景，得出系统所需要的功能。

下面是业务场景分析的任务指引图：

2 挑战：思考每个场景下，可能会遇到的问题

3 方案：针对问题，思考系统应该提供什么样的功能

业务场景分析要点

• 概述业务场景：思考该业务场景中，用户的业务目的是什么？执行该业务场景有什么前提条件？结束条件？除了场景执行者外，还有谁关心它？关心什么？

• 细化业务场景的业务步骤：梳理方法就是场景—挑战—方案模型的第一步骤，描述时需要注意一些要点

  1 重在人机交互而非人机界面，重在用户意图而非用户动作；
  2 结构化陈述，避免分支与循环，分支循环用单独事件流陈述；(避免出现如果..那么...重复执行...等词汇)

• 遍历步骤分析困难，导出功能：属于场景—挑战—方案模型的后二个步骤，思考的时候建议以下两个角度
  

  1 执行步骤时，变化和异常情况下会遇到什么困难？
  2 针对这些困难，系统需要需要提供什么的功能支持？

• 识别环境与规则：考虑性能(人数、业务量、峰值密度等)、易用性(用户文化水平、学习曲线)、部署环境(网络、软硬件环境)等非功能性需求

• 分析实现方式，完成初步交互设计：体现交互过程(页面流转、业务步骤)，一些静态快照(体现页面具体内容)，设计说明(设计原因、建议、约束)

输出物

业务场景分析模板

管控点识别与分析

信息系统的核心价值之一是支持管理，而管理支持的核心是通过管理流程事前规避风险，事中通过规则与审批控制风险，事后通过数据分析优化流程。

事前与事中的工作是在流程识别分析中一起完成的，而管控点识别与分析就是负责通过数据分析来管理优化流程。

下面是管控点识别与分析任务指引图：

管控点识别

曾经风靡一时的营销经典案例啤酒与尿布的故事，大家应该十分熟悉，但是我们自己思考下，这个案例中的数据是否完整？

如果只是提升客户满意度，只关注啤酒与尿布商品间销售关系就足够了。但如果是你想让客户多走走，增加停留时间，增大销售机会的，那可能还不够。
你要还要思考用户角色有没有影响？如果有影响，你应该如何调整？

很明显男士和女士同时去购买这两件商品的时候，需求是不一样的，对男士来说啤酒是兴趣，尿布是使命；对女士来说尿布是兴趣，啤酒是顺带。
人们可以为兴趣多花点时间，所以你应该知道怎么摆放二者了吧？

通过上面这个例子是想说明，在管控点识别的时候要关注客户的喜好，再决定提供什么产品/功能，而不是有什么产品/功能，选出来给客户。

还有一个经典的案例来说明管控点识别时，一定要知道客户背后的意图，否则功能只能浮于表面，无法真正解决用户问题。

大家可以思考下考勤系统的中的一个报表：员工迟到统计表，你认为员工迟到统计报表有什么用？
统计一下哪些员工迟到？

那为什么要统计员工迟到？
统计出来扣钱呗！

为什么要扣钱？公司缺这点钱吗？很明显公司不可能缺这点钱，那到底是为了什么？
继续陷入思考中......

不出意外，大多数公司目的都是借此来评估员工工作的积极性，所以你弄清楚了报表背后的真实意图，你就可以思考要达到评估员工积极性，还可以有哪些报表？

你还可以开发出这些崇尚人性本恶，老板很喜欢，员工很生气的报表：上班离岗时间统计，实际上班在岗时间统计，打卡与到岗时间差统计.......

针对同一个管控点，不同企业组织不同管理者都可能使用不同的指标，不同的报表来管理这一意图，因此我们在做业务报表、BI报表、数据挖掘分析时，核心是把握用户想要什么信息，他的管理意图是什么，才能实现有效分析。

管控点识别要点

• 标识管理者：管理者分为管理型和经营型，不同类型管理者关注重点是完全不同的
  

管理自我，其实不属于管理者，就是普通员工，做好个人的时间管理、计划管理、情绪管理等，这群人不会在管控点识别与分析中被关注

管理团队，管理型的第1级，关注于团队管理、人员管理，一般属于组长角色，在管控点识别与分析中可能少量关注

管理事务，管理型的第2级，关注于整件事情涉及人、进度、资源等，一般属于项目经理，主管角色，在管控点识别与分析中经常遇到

管理职能，管理型的第3级，关注于多事务，一般属于部门经理，管控点识别与分析中经常遇到

管理业务，经营型的第1级，关注于经营型指标，更加关注客户产品、供应商等主题，具体的执行性事务关注变少，在管控点识别与分析中经常遇到

管理业务群，经营型的第2级，关注于多业务，对于资本、发展方便更重视，想法也更宏观，都是关注决策性管控点

• 标识管控点：根据不同管理者，通过访谈、侧面了解、职位职责、考核指标分析等方法标识管控点
  

  管理维度问题：事务管理(进度、异常)，财务管理(成本、利润、资金使用)等
  经营维度问题：客户(满意度、贡献)，产品，供应商，竞争对手等

• 分析所需指标：管控点是why，报表和数据分析手段是how，指标是二者的衔接，指标和管控点是多对多的关系，可以复用

• 分析实现方式：确定使用什么实现方式，主要工作就是确定数据源、查询条件，具体展现字段等

输出物

管控点识别分析模板

业务报表分析

当完成管控点识别与分析之后，就开始着手业务报表的分析实现了。

下面是业务报表分析任务指引图：

业务报表分析要点

• 明确报表的使用场景：核心是理清三个问题，谁使用？(至少分为生成者和阅读者)，为什么用？(真实的背后意图)，使用频率如何？(决定了性能要求与技术解决方案)

• 分析报表的内容：输入条件、数据来源、报表中数据项、格式、计算方法

• 整理报表的输出要求：呈现方式与要求，显示和打印是否有区别？分类小计处理方式，多页处理规则？页码、表头要求？

输出物

业务报表描述模板

维护需求分析

分析系统投入试用之后，运行维护阶段所需要提供的辅助功能，主要包括：配置、运维、升级、迁移等方面需求

下面是运维需求分析任务指引图：

运维需求分析要点

• 标识配置性维护场景：主要考虑系统在这几个维度变化时，应该如何应对：用户群变化(权限)，流程变化(业务流程、规则)，数据变化(来源、体量)，法规变化(政治、行规)。这些可预见的变化，通常可以通过配置功能来提前应对，当然还需要平衡项目资源成本来综合考虑。

• 标识运行阶段维护场景：可以分为正常与故障两个角度进行分析

  正常时：运行状态的监控，数据备份要求
  故障时：故障的定位、排错、恢复与应急措施

• 补充其他维护场景：系统初始化规则，系统升级要求，系统迁移要求等

输出物