作为一个产品经理，画流程图是必备的技能。如制定订单处理的流程，制定商品审核的流程等。
有很多的文章介绍如何画流程图，我们发现有各种画法，也有各种概念。这里产生一个问题：到底什么样的流程图是正确的？
有没有标准的画法？无标准野路子的流程图必然会产生歧义，必然是思路混乱的。而网上相当比例都是野路子流程图。比如以下两个流程图就都是有问题的，并导致表达混乱。
其实流程图是有标准的，这就是UML（统一建模语言）制定的标准，被其称为活动图。并且这个标准被微软和IBM等大厂采用，用来做业务分析。下面我们通过学习就能够分析出来上面两个流程图的问题在哪里。
既然了解到很多流程图是有问题的，所以要画好也不是那么容易。所以我也会分三篇文章来介绍UML的流程图怎么画，分别是：
第一篇：如何制作正确的流程图？
第三篇：如何将流程图用在日常工作和生活中？
其中第一篇会让大家理解流程图的正确姿势和语言。第二篇会手把手教让大家绘制粗细得当，人人喜欢的流程图，并进一步扩展流程图的进阶知识。已经完成请移步阅读。
先学制作流程图的规则是什么，这就好比下象棋，我们首先要理解下棋的规则是什么，然后再学习如何去赢得比赛的策略。如果反过来，这就好比知道怎么下棋，却不了解基本规则一样。规则枯燥，但还是要先来学习的。
第三篇是扩展，即通过学习流程图更好的去在工作中表达沟通，甚至可以用来理解编程语言。进行扩展这点也是我之前的观点学习知识重要的在于“建立知识的多通道连接”，只有建立知识之间的连接，才能让技能飞速增长，打通任督二脉！具体文章请移步看《产品经理工作遇到困境，学什么来破解？》
本文是第一篇包括：流程图的意义、流程图如何绘制、分析网上常见的流程图的问题。
一、流程图的意义
产品经理画流程图有两个作用, 分别是：
1）用于和非研发部门交流: 决定人员都做什么工作？描述公司的核心业务。例如用户下单后，就涉及到物流部门进行发货，系统进行开发票等工作。
2）用于和开发人员交流：对于系统开发人员来讲，更关心的是这个订单系统的流程是什么。因此需要更多的细节描述，如下单之后如果出现供货不足无法发货，该怎么处理？
我们下一篇就会展开不同目的如何绘制流程图，本篇主要目标是绘制表达无错的流程图。
对于产品经理则要重视流程图的绘制。
首先，很多产品经理往往一上手做交互页面原型。但这样往往因为流程想不清楚，导致原型图需要重画。所以注意要先画流程图，再画原型图。
其次，研发经常批评产品经理的地方就是产品经理没有逻辑，而画流程图就是建立你的逻辑的一种方法，也最终用在面试表达，产品评审发言中。
下面我们就展开说明流程图怎么画。
二、流程图如何画？
流程图是为了完成某一任务而描述的相关活动以及这些活动的执行顺序。UML称流程处理的图为活动图，但为了便于讨论后面还称其为流程图。
下面我们以订单流程为例子，带领大家一步一步画出大厂标准的流程图。整个流程涉及到从用户下单到收货的流程。下面就是这个订单流程。
其逻辑是用户下单后，物流人员就需要送货到家，用户收货后，在点击确认收货，即完成整个订单。这里就涉及到以下概念：
1. 活动的概念
这里物流人员送货到家和用户确认收货，都体现了一个人做了什么事情，都会涵盖“主语+谓语+宾语”。“用户”是主语，“点击”是谓语，“确认收货”是宾语。
而人做了什么事情，就体现了一个“动作或操作”。而UML则称其为活动，其实和动作是同样的意思，后续我们都用活动这个概念。
活动的标准画法是带圆角的矩形框，里面写具体的活动，活动内容写成“主语+谓语+宾语”，宾语或主语根据说话习惯可以考虑省略。
活动之间用带箭头的线连接在一起，称其为“转移”。表示做完了一个活动就可以转移到下一个活动，比如物流人员送货到家后，用户才会确认订单完成，否则就无法进入下一个活动。
2. 起点和终点概念
一个流程图有一个“起点”，作用是表明一个流程从这里开始。起点画法是个实心小圆。
一个流程图也有“终点”，作用是表明上一步的“活动”就是这个流程的结束，对于上面的订单流程而言结束的活动就是“用户确认收货”。这个活动完成后，整个流程就算完成了。终点画法则是一个实心圆加一个空心圆。
注意：起点必须有，而终点可以省略不画或有多个。终点画上的好处是可让别人知道你考虑了终点因素。但有的流程涉及到的终点过多，并且结束显而易见，画上就显得累赘。
3. 判断和并行概念
现在我们已经能够画出了流程图。但我们发现这个流程会有很多细节需要补充，这就是我们接下来要介绍的判断和并行概念。我们以问题为出发点，来看看如何完善流程图。
如果订单针对“网上支付或货到付款”有不同的处理过程如何表达？——用判断标志来解决。
此时物流人员就需要对订单进行判断，如果是网上支付（送货前支付）则直接给货物到用户，否则必须先让用户支付现金或先刷POS机后，再给货物，此时流程图如下：
这个判断点就用菱形符号来表示，此时是一个进入多个出，并且在出的线条上用方括号表明判断条件。这里的：
条件一是“如果用户是网上支付”（简称：网上支付），则相应的动作是“物流给货物到用户”；
条件二是“如果用户是货到付现金”（简称：现金支付），则相应的动作是“物流收取现金”。
条件三是“如果用户选择POS支付”，则“物流用POS机收钱”。
注意和其他流程图的菱形符号中间要写字不同，这里不允许在菱形符号中间写任何字，但表达的意思是一样的。菱形位置里面其实是可以写“物流确认支付情况”，写文字易于理解但是略显累赘。
再如电商遇到的如果用户支付完毕，有的时候会反悔并告知商家。对于商家也会存在两种选择，“同意则取消订单”或“拒绝则坚持发货”。这两种表达方式都可以达到同样的效果，只是方法不同。
了解了和传统流程图的不同表示方法后，对于UML体系，除了上面介绍的用带菱形的表示方法外，另外一个方式是不加入菱形判断图标，如下图所示：
这两种表达方法都是可以的，但需要注意要在转移线上写出判断条件。对于本案例加入判断的菱形图标会更加清晰，此时明确物流人员在这里要进行一个判断。
如果用户还要同时开发票则流程怎么表达？——用并行标志来解决。
现在很多的送货是货物和发票放在了一起一并寄送过去，或者支持电子发票的方式。但是还有一些企业开纸质发票，并且货物和开发票地并不一致。这个时候就需要货物和发票分别寄送到用户手里。
此时意味着两拨物流人员一个在送货和一个在寄送发票。这里就是一个并行处理，表达方式如图所示：
画法是画一个粗横线，再加上一个进入和多个出的转移线条。对于本例子，出的两个分支流程是配送货物和发票寄送，此时同步处理但并不在意谁先做谁后做。
4. 汇合和合并概念
网上支付和现金支付送任意一个完成就算完成如何表达？——用合并来解决。
此时只要是网上支付或现金支付任意一个方式就算完成了支付。即条条大路通罗马，我们只要一个路径能到达，就可以进行下一步了，此时有两种表达方法：
第一种方法直接通过三条转移线连接到下面的活动即可，这个也是我们在前面看到的。第二种方法是画一个菱形并且多进一出。注意这个菱形符号在这里不是表示要判断，只是借用了菱形符号而已，因此也不必在线条旁边加入判断条件。
实际上第二种画法是UML的标准画法。但毕竟看流程图的人有的不是编程人员，画上会让人误解，为了便于沟通可以选择第一种画法。但是在看到网上的流程图加入合并的菱形标志的时候，要意识到这里不是进行判断，而是在做合并。
这里另一个例子就是用户可点击确认收货，而系统也可以自动确认收货，也是那个先确认收货都算收货，订单即最后完成。
发票和商品用户都收到才算订单完成如何表达？——用汇合来解决。
前面我们讲了货物和发票是分别寄出的，对于用户必须是发票和货物同时收到了才会点击“确认收货”，两者缺一不可。具体表示见下图：
表达方式是一个粗横线，再加上多个进入和一个出。进入的分支是送货物和送发票，此时同步处理但并不在意谁先做谁后做，但汇合的时候必须要都完成才可进入到下一步。
另一个例子就是吃饭上菜的例子。我们到餐厅菜是分别上的，只有都上完了才算完成了。而在野路子的流程图中，是没有办法表达这个并行汇合处理的。
通常并行和汇合成对出现，此时并行执行两组活动，但必须两组活动都完成才能进入下一环节。而上图也就是一个完整的流程图了。
5. 流程图的总结
流程图表示方法最后总结如下表：
三. 通过问题学概念
流程图的绘制方法和逻辑看完了之后，我们再来看一些来自网上的流程图，逐一明确一下常见的问题是什么？好让我们避免同样的错误。
案例一：流程图中不应有非活动的内容
上面的流程图是说产品经理的工作包括需求收集，需求讨论和需求评审等工作，并为此画了流程图进行阐述。思考一下，这个流程图的问题是什么？
我们按照流程图的概念来看，流程图要求每个框起来的都是一个活动，活动的典型即存在“主+谓+宾”。
在这里面“有效需求、已有功能和需求池”都不是一个活动，这里都是在说需求的不同类型和功能概念。真正体现活动的是产品经理进行“收集需求，讨论需求和需求评审”。
而这里大家会说，我要体现“有效需求和需求池”等概念该怎么做？
那么可以这样描述：我们可以将需求划分为新需求+老需求，其中新需求产品经理需要过滤成有效需求和无效需求。而进入需求评审环节的是新需求的有效需求和老需求并放入需求池中，在这个环节我们决定本期开发的需求是那些。
上面这种描述，如果你理解了UML的面向对象的思考方法，就可以有效来描述了。这个以后也会有专题来讲。另外其实知识是相通的，如果按照金字塔原理进行逻辑思考，也能得出上面的描述内容。
通过这个案例，我们发现将需求处理的方案和需求评审流程的描述混在一起，会让受众群体迷惑，而如果分开描述则会清晰很多。
案例二：流程图不同于状态图
这是一个买家下单和付款的流程。这里仍然按照“主谓宾”来拆分，我们发现待付款不是一个活动，而是一个状态。而横线上的“买家下单”才是个活动（即用户点击下单）。
因此这个仍然不是流程图，在UML里更适合用状态图来表达。如果此时按照状态图的角度来看，这里也是有问题的，我们以后会有专题来讲状态图。
案例三：流程图的逻辑需要仔细思考
这个流程图大家看是从用户下单到供应商供货的流程，我们假设这个就是京东或天猫的订单流程。在这里“生成送货单，以及用户选择支付方式，收款”等环节存在逻辑问题，大家想想逻辑问题是什么？
此时我们回忆一下我们在购物APP上如何下单的？这个流程是：
1）用户从购物车点击“去结算”，就会打开“提交订单页面”。
2）在“提交订单页面”允许用户选择网上支付还是货到付款，以及编辑送货地址，此时点击“提交订单”按钮。
3）则系统生成订单，并展示给用户“支付页面”。
4）在“支付页面” 允许用户可以选择某银行卡或支付宝后，再点击“银行卡支付”按钮。
5）此时系统展示“输入网银（或支付宝）密码”的页面。
6）在“输入密码页面” 用户“输入账户密码”后就完成了订单支付。
回忆完整个流程后，我们会发现如下问题：
问题一：“用户选择支付方式，之后收款，中间可以取消订单”这个概括就不正确。
实际上是“在提交订单页面，用户先点击提交订单；之后弹出输入密码页面，用户输入密码完成支付”。此时在点击提交订单后不输入支付密码时，用户可以到个人订单列表里面选择“取消订单”。因此概括起来是：用户提交订单，之后用户支付订单，在提交订单后可以取消订单。
问题二：生成送货单和其他活动不是并列关系。
系统的实际工作过程是“用户点击提交订单”后，系统就会生成订单，并抛出一个让用户来支付的页面。这个生成的订单我们可以在订单列表里面看到，针对待付款的订单用户可以进行支付或取消订单。所以生成送货单和选择支付方式是不是同时进行的关系。
通过这个案例其实发现流程训练首先需要仔细思考每个环节。其次这个涉及到对流程对每一步如何进行抽象的问题，如何画出人人都喜欢都明白的流程图的问题。这也是第二篇要重点讲的地方。
四. 总结
通过本篇文章，大家了解了标准的流程图的画法。
这里首先需要理解活动，判断、并行、并行汇合和合并等基本概念。其次通过三个例子，说明如何正确表达流程图，而不要学了假的流程图。
其次发现流程图只是其中的一种逻辑思考和表达方式，还有很多其他的方式需要进一步解锁。
最后举例的三个流程图指出了问题，但没有画出来。大家可以留言说说你的思路、说说认为的流程图怎么画。
向你推荐系列讲思路的文章，解决产品人表达不清，找不到方案，理不清业务的问题。
