当我们谈业务流时，我们该谈论什么？（上）

柒 2023-07-24 17:26:18

社会是由无数条自行运转、循环往复的流程所组成的，大至生老病死，小至吃喝玩乐，它们让我们的生活按部就班，亦如业务流让我们的业务井然有序。

事物存在自有其理，当我们 [谈业务流] 时，我们该谈论什么？

01 业务流的价值

业务流是指组织协同各种角色完成业务目标的一系列活动，简单来说就是：“在业务中谁做了什么事，产生了什么结果，并把信息传递给了谁”，它常以流程图的形式出现在产品经理的工作中。

产品经理作为业务需求与产品之间的桥梁，在产品的全生命周期，都需要借助业务流去处理多样的业务信息，梳理业务需求的逻辑，顺利完成产品设计。

基于业务流在产品经理实际工作中所发挥的作用，业务流的价值主要体现在：

1. 降低解读业务的难度

业务流通过一系列特定的符号和连接线，将业务中多元的角色、复杂的事项用图形展示出来，相对于文字描述可以更清晰的表达流程之间的逻辑关系，便于产品经理理解业务的走向。

我们以日常下馆子吃饭为例，对比文字和图形这两种不同的表达方式。

文字描述：

小明去餐馆吃饭，服务员招呼小明落座并询问他吃什么，小明查看菜单后点菜，服务员为小明下单并喊厨师备好食材烹饪，厨师做好后打铃让服务员上菜，小明拿到饭菜后开始用餐，小明用餐后去收银台结账，服务员送客，小明离店。

可以看出，作为描述业务的常用方式之一，文字描述法虽然可以把业务逻辑记录下来，但呈现内容冗长，对业务步骤及业务节点的反映不够直观。

流程图展示：

通过流程图可以清晰的看出，小明、服务员、厨房、收银台四种角色在业务中各自的任务，以及他们之间如何产生联系。

2. 补充理解业务的视角

完整的业务流除了包括能满足用户刚需的核心流程，还包括从业务节点引申出的分支流程和异常流程，这些非核心流程可以保证业务流的完整性、连贯性和容错性，帮助产品经理发现业务中的问题，进而制定优化方案，调整业务细节。

举个栗子：

几乎所有的互联网产品中都有注册模块，为了让用户顺利完成注册，不仅要考虑用户正常完成注册的流程，也要考虑“注册账号格式错误、验证码无效、网络中断”等系统异常流程，如下图所示：

理想状况下，我们期望达成目标一蹴而就，但是在实践的过程中，可能会出现各种状况，分支流程和异常流程是对核心流程中可能会出现的状况而提出的解决方案，用以补全我们理解业务的视角。

人之所以视角不全的是因为对达成目标所需的必要条件考虑不周，所以，我们能预判的断点场景越多，业务解决方案就会覆盖越多的流程漏洞，让业务具有更强的抗风险能力，支撑业务完成。

试想一下，如果自始至终都没思考过异常业务流程，当主线流程被打断，又该如何处理？

3. 提升交付需求的效率

业务流解决的是怎么做的问题，即从执行的角度告诉我们如何把个人或组织制定的业务目标实施到位，了解业务流中各角色之间的协作关系，以及各环节之间的衔接关系，有助于加深产品经理对业务的认识程度，避免因不了解业务而导致的产品方案频繁修改、产品需求落地困难等问题，提升产品经理交付需求的效率。

我们以产品同学常参加的需求评审工作为例：

需求评审作为业务信息同步的重要环节，需要产品经理向团队成员解释业务需求的前因后果，以期达成团队共识，快速开展工作。

如果缺少了业务流的辅助，即便PM可以用三寸不烂之舌把业务逻辑解释清楚，但由于团队成员的业务理解能力各异，认知水平不一，很难仅靠只字片语就在短时间内完全理解复杂的业务关系。

这种情况下，一方面，产品经理需要频繁沟通才能强化大家对业务的印象，这无形中会延长会议时间，增加单个问题的解释成本，并降低产品经理的工作效率；

另一方面，业务流是团队内部交流业务的基础，缺少业务流的需求方案犹如无源之水、无根之木，若产品方案缺乏说服力和可信度，则难以支撑产品经理去推进需求的研发、上线。

通过业务流，可以减少产品经理与团队成员之间无效沟通的次数。以业务流为基础的产品方案，帮助产品经理诠释业务的运作模式，提高需求内容的易读性，提升交付需求的效率。

02 梳理业务流的初衷

业务流始终关注的是业务本身该如何运转，它为我们提供了一种“业务俯瞰图”的效果，如果把梳理业务比作修建高楼，那么业务流就是指导建筑队构建地基、砌墙架顶的蓝图。

建筑师在修筑之前，对所建之物已了然于心，产品经理犹如产品业务的建筑师，在梳理业务流之前，也需要明晰梳理它的初衷。

1. 梳理业务流，只是为了完成工作任务？

动机不同，实施行为后所得到的收获亦不同。

面对上司交待一项工作任务，我们是仅仅抱着交差的想法去完成，还是多加思考完成工作的意义，从而把这项工作尽善尽美的收尾？选择前者，就只是在任务列表上打了一个“√”，选择后者，则意味着我们不光要完成任务，还要赋予结果更多的价值。

因为产品设计工作是产研开发过程的开始，梳理业务流又是产品设计的重要环节，所以不同的梳理动机，对于后续的研发过程势必会造成截然不同的影响。

假如，在梳理业务流的过程中，重视对业务逻辑的推演以及业务关系的把控，持续跟进梳理后的业务流与实际业务的匹配度：

一方面，团队进行流程梳理后，可以验证流程的可行性，利用结果反馈，优化、完善流程，界定产品功能的界限；

另一方面，流程梳理作为流程管理的第一步，可以逐步分解业务流的要素，为流程顺利打通提供依据，提高对接业务的效率。

相反，如果我们只是简单的把业务背景从字面意思转译为流程图，虽然也可以完成基本的梳理工作，但缺乏了对整体业务目标、业务要素的重视以后，会导致业务流定义不清晰，业务信息表述不准确等问题，需求方案的执行效果也会随之变差，无法保证业务需求被完整实现。

而且，重新制定业务流还需要产品经理耗费更多时间、精力返工修改既定的业务流程，以填补业务需求的bug。

梳理业务流可以提高工作效能，优化解决方案。所以说，梳理业务流不只是为了完成工作任务，更是为了提高产品设计工作的价值。

2. 梳理业务流，只是为了达成团队共识？

梳理业务流的过程，其实也是传达业务信息的过程。

为了避免业务角色之间、团队成员之间因业务信息脱节、业务信息不同步而导致的信息孤岛问题，产品经理在梳理业务时，需要协调团队资源、寻找与项目有联系的业务上下游对齐业务信息，比如通过和渠道、市场部门交流业务诉求，确保设计的业务流在现有推广资源条件下具备可行性，与研发、算法团队交流技术实现，确保产品功能在目前技术基础上的落地可行性。

梳理业务流就像是在编排表演，为项目的各个角色安排戏份，并让他们参与到业务的小剧场中，共同演绎完成业务的全流程。

经过上通下达的串联，业务流程在梳理清楚的同时，也增加了业务信息在团队中、项目组内部的传达频率，大家在普遍认可业务流的情况下，达成共识便可以保持业务认知水平的一致性，提升协同工作的效率，营造出相互信赖的团队合作精神，从而增强团队协作的效能。

团队效能是在规定的项目环境下和规定的项目时间内，对团队工作完成规定任务程度的度量。团队协作的能力、团队协作的状态、团队协作的规则共同组成了度量它的函数，在人力相对稳定、执行条件相对固定的情况下，执行任务的状态就变成了左右团队协作的胜负手。梳理业务流，不只是为了达成团队共识，更是为了增强团队协作的效能。