自媒体行业有一句不知道是谁说的名言：用户有图就不会看文字,有视频就不会看图。虽然这里反应出了现代人的一些浮躁，但也从侧面说明在沟通效率方面，视频优于图片，图片优于文字。而平时大家又都在抱怨老人没有留下文档，自己又不写文档。用视频来记录文档制作成本太高，而用文字记录文档有没人看，所以使用图表来描述文档就显得经济实惠一些。
画过的流程图没人看，多数是因为阅读的人看不懂。这就像篮球比赛中的传球一样，传球失误多半责任是传球人的动作不规范导致。文档也是一样，阅读的人看不懂，多半是文档作者描述问题不清晰。所以针对流程图我们需要有一套标准化的定义。
先贴一个流程图，大家看看能否理解需求。
圆角矩形表示程序开始或结束
矩形表示单据的状态
带箭头的线表示数据流向
菱形表示数据流向的判断
程序员报销审批，金额大于等于1000，提交单据后需要经理审批，金额小于1000直接由财务审批，经理通过后需要财务审批。“经理待审批”和“财务待审批”这两种单据的状态一定对应各自的操作页面，用矩形表示。“经理审批通过”这是一个数据流向，对应“经理待审批”这个页面的“通过”按钮的事件，用带箭头的线表示。程序员提交的报销金额是否大于等于1000这个判断就是数据流向的判断，用菱形表示。
什么情况下需要画流程图
如果业务流程中只有一个步骤的审批，那就不用画流程图，毕竟流程简单看代码也花不了多少时间。大于一步的审批就一定要画流程图。
画流程图的注意事项
带箭头的线上一定要注明操作数据的过程，比如“审核通过”。
线与线不要交叉。
不要多条线使用一个箭头。
流程图一定要有开始和结束的圆角矩形框，让读者第一眼就能看出数据的整体，这也是做事的规矩，有始有终。
记得我的初中数学老师讲坐标系的画法，他说画坐标系一定要写x，y和0，如果谁只画了一个十字架，即使题作对了也不给分。
流程图的“开始”要画在上面，“结束”要画在下面，正常的数据流向要自上而下，例如“审核通过”，异常的数据流向可以自下而上，例如“审核拒绝”。因为人的潜意识都是自上而下的，都是希望得到肯定回答的。所以请顺着人类的潜意识思维描述需求。
流程图可以有多个结束，但是只能有一个开始。
流程图尽可能在一屏显示，或者能够打印在一张A4纸上，如果一张图中内容过多，建议拆分为多张流程图。
流程图工具
visio，微软出品，仅限windows。
wps，可导出jpg、png等图片格式，导出svg、pos格式需会员充值。
www.processon.com 浏览器在线编辑，可导出图片格式和svg、pos格式文件，但免费模式想加最多只能创建9张流程图。
Gliffy Diagrams 谷歌浏览器插件，只能导出图片格式和自研的gliffy文件。
注：svg和pos文件是流程图通用格式文件
画流程图有啥用
流程图是沟通的利器。在钉钉上一张图能说明白的事就不用浪费太多的口舌来解释。
流程图是离职交接的利器，有了流程图可以避免上家公司接手的同事追杀到你们家。
流程图还是需求变更的利器。产品经理要改需求，只要看看流程图上改了哪些矩形，就知道这次变更需要改哪些页面；流程图上改了哪些线，就知道这次要改哪些按钮的代码逻辑。
流程图就是需求。因为现在的需求你和神都了解细节，等过了2个月就只有神能了解细节了。我开发的功能，未来新人或者其他部门的人对此有疑惑他们只能来问我，如果自己开发的功能自己都说不明白，那tm就尴尬了。
写在最后一
大学的软件工程老师说过，只要需求文档确定，大家的工作就需要低头写代码。工作之后我一直认为这是理论脱离实践的笑话。直到我深入研究流程图才发现，流程图就是对应着代码，菱形有几个向下指的箭头，那么页面是就有几个与之对应的按钮（也可能是单选框）。
写在最后二
如果产品不画流程图，咱们技术就画。与产品经理碰撞后一定要敲定一个最终版的流程图用于开发编码，因为没人会看那冗长的文字版需求。最后贴一个酸奶爸爸之前画的流程图，显摆一下。