pos机打发票的盖子怎么打开

原标题：你可能已经学会了假流程图，并学会了用三个步骤绘制大型工厂的流程图

文章来源于网络，若有侵权，请联系我们删除。

  流程图有没有限定的标准？正确规则的流程图有什么规范？本文将从三个方面来作出解答：流程图的意义、流程图怎样绘制、常见的流程图问题。

pos机打发票的盖子怎样打开（网络配图 侵删）

  作为一个产品经理，画流程图是必备的技能。如制定订单处理的流程，制定商品审核的流程，制定用户开银行账户的流程等。

  也有非常多的文章在介绍怎样画流程图。我们发现有各种画法，也有各种概念。这里产生一个问题：到底什么样的流程图是正确的？有没有标准？

  无标准野路子的流程图必然会产生歧义，必然是思路混乱的。比如以下两个流程图就都是有问题的，并导致表达混乱。

pos机打发票的盖子怎样打开（网络配图 侵删）

  有问题的流程图

pos机打发票的盖子怎样打开（网络配图 侵删）

  有问题的流程图

  其实流程图是有标准的，这就是UML（统一建模语言）制定的标准，被其称为活动图。并且这个标准被微软和IBM等大厂采用。我们通过本文就能够知道，上面两个流程图的问题了。

  既然了解到很多流程图是有问题的，所以要画好也不是那么容易。所以我也会分三篇文章来介绍UML的流程图怎样画，分别是：

  第一篇：怎样制作正确规则的流程图？

  第二篇：怎样制作人人喜欢的流程图？

  第二篇：流程图的概念解析

  其中第一篇会让大家理解流程图的正确姿势和语言。第二篇会手把手教让大家绘制粗细得当，人人喜欢的流程图。第三篇是概念解释，破除业务流程图，任务流程图和功能流程图的误区。

  要先学流程图的规则是什么，这就好比下象棋。我们首先要理解下棋的规则是什么，然后再学习怎样去赢得比赛的策略。如果反过来，这就好比知道怎样下棋，却不了解基本规则一样。规则枯燥但还是要先来学习的。

  本篇文章包括：流程图的意义、流程图怎样绘制、常见的流程图问题。

  一、流程图的意义

  对于产品经理要重视流程图的绘制，这背后是逻辑清晰的表达和思考。

  首先，很多产品经理往往一上手做交互页面原型。但这样往往因为流程想不清楚，导致原型图需要重画。所以要先画流程图，再画原型图。

  其次，研发经常批评产品经理没有逻辑。而画流程图就是建立你的逻辑的一种方法，也最终用在面试表达，产品评审发言中，下面我们就看看怎样画。

  二、流程图怎样画？

  流程图是为了完成某一任务而描述的相关活动的执行顺序。UML称流程图为活动图，为了便于讨论，后面还称其为流程图。

  下面我们以订单为例子，带领大家一步一步画出流程图。整个流程涉及到从用户下单到收货的流程。下面就是这个订单流程：

pos机打发票的盖子怎样打开（网络配图 侵删）

  其逻辑是用户下单后，物流人员就需要送货到家，用户收货后，在点击确认收货，即完成整个订单。这里就涉及到以下概念：

  1.活动的概念

  这里物流人员送货到家和用户确认收货，都体现了一个人做了什么事情，都会涵盖“主语谓语宾语”。“用户”是主语，“点击”是谓语，“确认收货”是宾语。

  而人做了什么事情，就体现了一个“动作或操作”，而UML则称其为活动。其实和动作或操作是近似的意思，但活动的概括更为广泛。

  活动的标准画法是带圆角的矩形框，里面写具体的活动，活动内容写成“主语谓语宾语”，宾语或主语根据说话习惯可以考虑省略。

  活动之间用带箭头的线连接在一起，称其为“转移”。表示做完了一个活动就可以转移到下一个活动，比如物流人员送货到家后，用户才会确认订单完成，否则就无法进入下一个活动。

  2.起点和终点概念

  一个流程图有一个“起点”，作用是表明一个流程从这里开始。起点画是个实心小圆。

  一个流程图也有“终点”，作用是表明上一步的“活动”就是整个流程的结束。对于上面的订单流程而言结束的活动就是“用户确认收货”。这个活动完成后，整个流程就算完成了。终点画法则是一个实心圆加一个空心圆。

  注意：起点必须有，而终点可以省略不画或有多个。终点画上的好处是可让别人知道你考虑了终点因素。但有的流程涉及到的终点过多，并且结束显而易见，画上就显得累赘。

  3.判断和并行概念

  现在我们已经能够画出了流程图。但我们发现这个流程会有很多细节需要补充，这就是我们接下来要介绍的判断和并行概念。我们以问题为出发点，看怎样完善流程图。

  “网上支付或货到付款”有不同的处理则怎样表达？——用判断标志来解决。

  此时物流人员就需要对订单进行判断，如果是网上支付（送货前支付）则直接给货物到用户，否则必须先让用户支付现金或先刷POS机后，再给货物，此时流程图如下：

pos机打发票的盖子怎样打开（网络配图 侵删）

  这个判断点就用菱形符号来表示，此时是一个进入多个出，并且在出的线条上用方括号表明判断条件。这里的：

  条件一是“如果用户是网上支付”（简称：网上支付），则相应的动作是“物流给货物到用户”；

  条件二是“如果用户是货到付现金”（简称：现金支付），则相应的动作是“物流收取现金”。

  条件三是“如果用户选择POS支付”，则“物流用POS机收钱”。

  注意：和其他流程图的菱形符号中间写字不同，这里不允许在菱形符号中间写任何字，但表达的意思是一样的。菱形位置里面其实是可以写“物流确认支付情况”，写文字易于理解但是略显累赘。

  再如电商中如果用户支付完毕，有的时候会反悔并告知商家。对于商家也会存在两种选择，“同意则取消订单”或“拒绝则坚持发货”。这两种表达方式都可以达到同样的效果，只是方法不同。

pos机打发票的盖子怎样打开（网络配图 侵删）

  了解了和传统流程图的不同表示方法后，对于UML体系，除了上面介绍的用带菱形的表示方法外，另外一个方式是不加入菱形判断图标，如下图所示：

pos机打发票的盖子怎样打开（网络配图 侵删）

  这两种表达方法都是可以的，但需要注意要在转移线上写出判断条件。对于本案例加入判断的菱形图标会更加清晰，此时明确物流人员在这里要进行一个判断。

  如果用户还要同时开发票则怎样表达？——用并行标志来解决。

  现在很多的送货是货物和发票放在了一起一并寄送过去，或者支持电子发票的方式。但是还有一些企业开纸质发票，并且货物和开发票地并不一致。这个时候就需要货物和发票分别寄送到用户手里。

  此时意味着两拨物流人员一个在送货和一个在寄送发票。这里就是一个并行处理，表达方式如图所示：

pos机打发票的盖子怎样打开（网络配图 侵删）

  画法是画一个粗横线，再加上一个进入和多个出的转移线条。对于本例子，出的两个分支流程是配送货物和发票寄送，此时同步处理但并不在意谁先做谁后做。

  4.汇合和合并概念

  网上支付和现金支付任意一个完成就算完成怎样表达？——用合并来解决。

  此时只要是网上支付或现金支付任意一个方式就算完成了支付。即条条大路通罗马，我们只要一个路径能到达，就可以进行下一步了，此时有两种表达方法：

pos机打发票的盖子怎样打开（网络配图 侵删）

  一种方法直接通过三条转移线连接到下面的活动即可，这个也是我们在前面看到的。第二种方法是画一个菱形并且多进一出。注意这个菱形符号在这里不是表示要判断，只是借用了菱形符号而已，因此也不必在线条旁边加入判断条件。

  实际上第二种画法是UML的标准画法。但毕竟看流程图的人有的不是编程人员，画上会让人误解，为了便于沟通可以选择第一种画法。但是在看到网上的流程图加入合并的菱形标志的时候，要意识到这里不是进行判断，而是在做合并。

  这里另一个例子就是用户可点击确认收货，而系统也可以自动确认收货，也是那个先确认收货都算收货，订单即最后完成。

  发票和商品用户都收到才算完成怎样表达？——用汇合来解决。

  前面我们讲了货物和发票是分别寄出的，对于用户必须是发票和货物同时收到了才会点击“确认收货”，两者缺一不可。具体表示见下图：

pos机打发票的盖子怎样打开（网络配图 侵删）

  达方式是一个粗横线，再加上多个进入和一个出。进入的分支是送货物和送发票，此时同步处理但并不在意谁先做谁后做，但汇合的时候必须要都完成才可进入到下一步。

  另一个例子就是吃饭上菜的例子。我们到餐厅菜是分别上的，只有都上完了才算完成了。而在野路子的流程图中，是没有办法表达这个并行汇合处理的。

  通常并行和汇合成对出现，此时并行执行两组活动，但必须两组活动都完成才能进入下一环节。而上图也就是一个完整的流程图了。

  5.流程图的总结

  流程图表示方法总结如下：

pos机打发票的盖子怎样打开（网络配图 侵删）

  三、通过问题学概念

  流程图的绘制方法看完了之后，我们再来看文章最前面的流程图的问题是什么？

  案例一：流程图中不应有非活动的内容

  上面的流程图是说产品经理的工作包括需求收集，需求讨论和需求评审等工作，并为此画了流程图进行阐述。思考一下，这个流程图的问题是什么？

  我们按照流程图的概念来看，流程图要求每个框起来的都是一个活动，活动的典型即存在“主谓宾”。

  在这里面“有效需求、已有功能和需求池”都不是一个活动，这里都是在说需求的不同类型和功能概念。真正体现活动的是产品经理进行“收集需求，讨论需求和需求评审”。

  而这里大家会说，我要体现“有效需求和需求池”等概念该怎样做？

  那么可以这样描述：我们可以将需求划分为新需求老需求，其中新需求产品经理需要过滤成有效需求和无效需求。而进入需求评审环节的是新需求的有效需求和老需求并放入需求池中，在这个环节我们决定本期开发的需求是那些。

  上面这种描述，如果你理解了UML的面向对象的思考方法，就知道这是另一种形式的描述。另外其实知识是相通的，如果按照金字塔原理进行思考，也能得出上面的描述内容。

  通过这个案例，我们发现将需求处理的方案和需求评审流程的描述混在一起，会让受众群体迷惑，而如果分开描述则会清晰很多。

  案例二：流程图不同于状态图

  这是一个买家下单和付款的流程。这里仍然按照“主谓宾”来拆分，我们发现待付款不是一个活动，而是一个状态。而横线上的“买家下单”才是个活动（即用户点击下单）。

  因此这个仍然不是流程图，在UML里更适合用状态图来表达。如果此时按照状态图的角度来看，这里也是有问题的，我们以后会有专题来讲状态图。

  案例三：流程图的逻辑需要仔细思考

  这个流程图大家看是从用户下单到供应商供货的流程，我们假设这个就是京东或天猫的订单流程。在这里“生成送货单，以及用户选择支付方式，收款”等环节流程表述错误，大家想想问题是什么？

  此时我们回忆一下我们在购物APP上怎样下单的？这个流程是：

  1）用户从购物车点击“去结算”，就会打开“提交订单页面”。

  3）则系统生成订单，并展示给用户“支付页面”。

  4）在“支付页面”允许用户可以选择某yinhangka或支付宝后，再点击“yinhangka支付”按钮。

  5）此时系统展示“输入网银（或支付宝）密码”的页面。

  6）在“输入密码页面”用户“输入账户密码”后就完成了订单支付。

  回忆完整个流程后，我们会发现如下问题：

  问题一：“用户选择支付方式，之后收款，中间可以取消订单”这个概括就不正确。

  实际上是“在提交订单页面，用户先点击提交订单；之后弹出输入密码页面，用户输入密码完成支付”。此时在点击提交订单后不输入支付密码时，用户可以到个人订单列表里面选择“取消订单”。因此概括起来是：用户提交订单，之后用户支付订单，在提交订单后可以取消订单。

  问题二：生成送货单和其他活动不是并列关系。

  系统的实际工作过程是“用户点击提交订单”后，系统就会生成订单，不生成订单就没有支付页面。这个生成的订单也可以在个人中心的订单列表里看到，针对待付款的订单用户可以进行支付或取消订单。所以生成送货单和选择支付方式是不是同时进行的关系。

  通过这个案例其实发现流程训练首先需要仔细思考每个环节。其次这个涉及到对流程对每一步怎样进行抽象的问题，怎样画出人人都喜欢都明白的流程图的问题。这也是第二篇要重点讲的地方。

  四、总结

  通过本篇文章，大家了解了标准的流程图的画法。

  这里首先需要理解活动，判断、并行、并行汇合和合并等基本概念。其次通过三个例子，说明怎样正确表达流程图，而不要学了假的流程图。

  我们发现流程图是一种逻辑表达方式，还有很多其他的方式需要进一步解锁，会在后续文章中讲解。

  说说你曾经踩过的坑？是否有点启发和改变？

  题图来自Unsplash，基于CC0协议