任务和业务流程图分清用好,三步教会你绘制大厂流程图(第三篇)

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

业务流程图、功能流程图、任务流程图……我们经常听到这些名词伴随着定义/概念出场,然而,这些概念真的是正确并且准确的吗?

继上两篇,讲述了流程图的规范,以及讲述了如何画出不被研发怒怼,能让运营看懂的流程图后,我们继续来明确几个网上的概念。

前面两篇文章请移步查看:《制作规范不错的路程图》、《制作人人喜欢的流程图》。

本文明确的是以下问题,也是经常容易被理解错的概念。

  1. 业务流程图只是一个说法而不是一种画法;
  2. 任务和业务流程图多此一举的概念;
  3. 功能流程图不要用不要提。

下面我们一步一步说明。

一、业务流程图只是一个说法而不是一种画法

先看下面两张图,在一些表述中,分别被描述成是业务流程图和任务流程图,而两者的区别是:

1)业务流程图就是带泳道的流程图,是表述业务流程的。

2)任务流程图是无泳道的流程图,是表述任务的。

而实际上这两个表述都欠妥。

业务流程图(泳道图)

任务流程图

业务流程图的描述为什么欠妥?先看下面对业务流程图的描述:

业务流程图就是描述那些个体在什么条件下做了什么事情,他们之间有何关联。

主要分两个方面:

1)涉及到哪些主体(角色)?

2)每个主体(角色)都有哪些工作?

而这里如果理解成“带泳道的就是业务流程图”,那么请看下面的两张图,描述的内容是相同的,但无论加不加泳道,是不是都在表述业务呢?

不带泳道的描述业务

带泳道描述业务

因此业务流程图只是一个说法,而不是一个具体的画法,可以加泳道或不加泳道。

二、任务和业务流程图多此一举的概念

另一方面,”业务流程图和任务流程图”概念则不建议提,实际上是多此一举的概念,仅仅是个修饰词而已。看下面的表述:

任务流程图就是在你的产品操作上,用户通过什么样的操作来完成它的目标,比如你去银行ATM机器上取钱,你是如何一步步操作把钱取出来的。

其实就是用户操作的过程,而如果概括为任务则成了“你的任务是去取钱或去注册”,这个就不准确了;而如果对于快递员如果说“你的任务是送快递”,则表述正确。实际上:

1. 对用户就是具体操作,显然用“用户操作流程”来解释就可以,比如:用户取钱流程图,用户登录流程图,用户下单流程图等。

2. 对快递人员而言则是一个任务, 比如:快递员送快递任务流程图。

因此建议工作中不要提任务流程图概念。对用户而言这不是一个任务,对快递人员而言是一个任务。直接说你要干什么就可以。参考下面两个说法那个适合?

  • 说法一:老板和各位研发,我们过一下我画的用户登录任务流程图和快递送货任务流程图。
  • 说法二:老板和各位研发,我们来过一下用户登录的流程和快递员送货的流程图。

显然第二种说法更为直接有效。

再举个列子,看下面的流程图,这个到底算是业务流程图,还是任务流程图呢?

实际上你发现,用“系统流程图”表述更准确。因此你会发现把流程图归类为任务流程图和业务流程图,其实没有必要。就是流程图,只不过有不同的修饰词。

因此可以在日常工作中,可以表述成:操作流程图(表达用户的注册的操作),业务流程图(表达公司内部处理订单的流程),系统流程图(如上图,表达系统内部的逻辑处理),任务流程图(表达快递员送快递所要完成的任务)等等各种说法。

至于用那个修饰词或想自己造一个修饰词,您随意写吧。实际上以上流程图,都没有画法的区别,都是一样的,为什么要分出不同的概念呢?

三、功能流程图不要用不要提

下面的表达称其为功能流程图:

而实际上:

1. 要么表达操作流程,用流程图。

2. 要么表达每个页面有什么主要功能,用页面流程图。

3. 要么表达功能之间的关系,用UML的用例图。

就这个案例看,就是要表达每个页面的主要功能。用页面流程图画3个简化的原型页面即可,又清晰又简单。不要用流程图表达功能,这不是流程图的目标。流程图是表达一系列的动作,而不是表达一系列的功能。

四、总结和后记

业务流程图,任务流程图和功能流程图是很多人听到的概念。

而实际上在经典的UML中就没有这些概念。没有这些概念是正确的,因为这种归类不严谨,也没有什么用。本人也试图去找到底是谁提出的这个概念,但是没有找到。如果有人知道源头和解释,欢迎指正。

相关阅读

制作人人喜欢的流程图,三步教会你绘制大厂流程图(第二篇)

你可能学了假流程图,三步教会你绘制大厂流程图(第一篇)

 

作者:擎苍(微信公众号:引爆产品思维),产品狗一枚,10年产品和运营经验,曾负责上市公司的互联网团队组建和运营,曾在多个垂直领域头部公司做产品狗。

本文由 @擎苍 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 功能流程图的源头,是在一篇全网超高阅读量的文章中看到的。对方详细解释了任务,业务和功能等流程图。按照其定义是各不相同。而实际上我们实战中从来没见过。之后我再分析,其实更适合用页面流程图表达。而按照奥姆剃须刀原理,也不应增加这些不必要概念,很多余。

    直播例子,自身逻辑清晰直接写逻辑也可,也可画流程图。可以理解直接写逻辑相当于编程语言写if等的汉化版。具体选哪个,在于那个研发更容易理解。

    回复
    1. 功能流程图的源头,是在一篇全网超高阅读量的文章中看到的。对方详细解释了任务,业务和功能等流程图。按照其定义是各不相同。而实际上我们实战中从来没见过。之后我再分析,其实更适合用页面流程图表达。而按照奥姆剃须刀原理,也不应增加这些不必要概念,很多余。

      直播例子,自身逻辑清晰直接写逻辑也可,也可画流程图。可以理解直接写逻辑相当于编程语言写if等的汉化版。具体选哪个,在于那个研发更容易理解。

      回复
  2. 我的个人拙见,交流交流。因为功能流程图这个说法还是很普遍在用,它就是**功能流程图,比如注册功能流程图、订单功能流程图等等,也会省略功能二字。但是这些都是一款产品的功能,它不是任务也不是业务,为了统称它们所以管叫功能流程图吧。

    像这些流程图存在也是很有意义,它就是针对一个功能来详细告知开发它的逻辑。类似注册登录这种普遍人都已经接触的功能当然不用细化,而一个全新的功能点就需要细化逻辑。比如:做一个直播功能,它需要很多判断逻辑。进入直播间前可能需要判断直播是否开播,直播是否会员制,是否拥有试看5分钟功能等,因为涉及到判断先后,不同的处理方式会有不同的结果。当然这个可以用原型去描述,但是相比之下流程图是否更加清晰呢?

    这是我个人的拙见,希望抛砖引玉,有大牛前来指点一下。

    回复
  3. 有几张图片看不了。

    回复
  4. 图挂了,重新编辑一下?

    回复
  5. 感谢大神精彩分享,收获颇丰,第三篇前两张图看不到呢

    回复
  6. 正常流程都会思考,但异常情况的处理则是考验产品逻辑的关键,期待你出个异常处理的文章

    回复
  7. 思维挺拔高的,不同阶段理解不尽相同,但不管如何,流程图是产品思维剖析的利器

    回复
  8. 期待您的下一份作品

    回复
  9. 逻辑清晰强大,不愧是产品大佬~

    回复
  10. 三篇文章都看了,非常感谢您的分享。

    回复
    1. 谢谢了,要多多运用才好

      回复
  11. 三篇文章都看了,感谢作者您的分享!

    回复
  12. 您的三篇文章都看了,谢谢您

    回复
    1. :idea:

      回复
  13. 您的三篇文章都看了,谢谢您

    回复
    1. 谢谢阅读,不过更高的获得要练

      回复
  14. 楼主会说说页面流程图和UML用例图吗? :oops:

    回复
    1. 短期难,其实除了流程图,下一步最需要掌握的思考利器是状态图,有这个才能做好后台的审核等逻辑,不至于丢三落四。
      而下一步会有新的方向,简历面试或者解决方案的思考。

      回复
    2. 状态图也是很期待了

      回复