如何制作决策流程图

如何制作决策流程图:把每个决策写成一个问题,让出口穷尽且互斥,把判定标准写在图上,并给每一种结果一个结束。附缺陷分级实例演示。

决策流程图描绘的是一连串选择:每个决策都是一个问题,每条出口都标上一个答案,而这些答案合在一起,恰好把每一种情况覆盖一次。

简而言之

  • 每一个菱形里都是一个问题,而且要写成读者答得上来的样子。
  • 出口穷尽且互斥——每一种情况恰好匹配一条。
  • 判定标准属于图上,不属于作者的脑子里。
  • 宁可用两个清晰的决策依次排开,也不要一个带五条出口的决策。
  • 把问题排序,让最省事、最能排除的那个排在最前面。

什么样的决策图在压力下仍然好用

决策流程图的读者,是那个必须做出选择的人——通常很急,而且往往没有作者当初掌握的背景。这比流程图面对的读者要苛刻得多。这意味着:问题必须能用读者手上真正有的信息回答,出口必须覆盖每一种情况,判定标准也不能只存在作者脑子里——“这个算不算严重?”只有在图上写明什么叫严重时,才算一个决策。

技术上的要求是:每个决策的各条出口必须穷尽且互斥,每一种情况恰好匹配一条路径。“穷尽”失败时,读者的处境不在列表上,于是他自己发明一条路。“互斥”失败时,两条路径都说得通,两位读者看着同一张图却做出不同判断——这看起来像团队不一致,实际上是图本身的缺陷。

下面的示例是一个缺陷分级流程,从头到尾几乎全是决策:能否复现、之前是否已经报告过、严重程度如何、修复是否通过评审、是否通过验证。六个决策,其中四个可以把事项打回上一环。

六个决策,一个缺陷

缺陷分级,从上报到关闭。几乎每一步都是一次选择,而其中大多数都能把事项打回上一环。

  1. 最省事的问题排在最前

    能否复现?在这个问题得到回答之前,下游的任何事情都不值得做,所以它排在最前。按“能省掉多少工作量”给决策排序,是您能给一张分级图带来的最大一项改进。

  2. 给死胡同真正的结束

    上报人没有回复,事项以“无法复现”关闭;重复的缺陷关联到原始记录后关闭。这两者都是正当的结果,各自有自己的终止点——一张只以“已修复”收尾的分级图,描述的并不是分级。

  3. 按严重程度分流,并写明严重程度的含义

    严重级会触发一次生产事件并跳过待办队列;标准级则转给负责的团队。把“严重”的定义写在这个决策旁边,否则两个人分级同一个缺陷会分出两种结果,而且两人都能说自己是照着图做的。

  4. 会向回跑的决策

    代码评审和验证都会把不通过的情况送回开发,而验证不通过是重开事项而非关闭它。正是这些回环,让决策流程图对返工的多少保持诚实。

运作方式

  1. 先列问题,再列答案

    把流程里包含的每一次选择都写成问题。然后按“各自能省掉多少工作量”排序:用最小的力气关掉最多事项的那个问题排在最前。把昂贵的问题问在最前面的分级图,浪费掉的正是它本来要节省的那些力气。

  2. 让每个问题都答得上来

    确认读者能用眼前已有的东西回答它。“这是重复的吗?”在有一个可搜索的缺陷跟踪系统时是成立的;“这是已知问题吗?”则不成立,除非图上写明已知问题记录在哪里。

  3. 把判定标准写在决策本身上

    把门槛写进该步骤的备注里:什么样的缺陷算严重、什么算充分的证据、多大金额会触发那道额外的审批。没有写明标准的决策,产出的是看起来一致的图和实际上并不一致的决策。

  4. 检查出口覆盖每一种情况——且只覆盖一次

    对每个决策自问:有没有哪一种处境不匹配任何一条出口?有没有哪一种同时匹配两条?两者都是缺陷。三路分支完全没问题——标准、常规、紧急——只要每一种情况恰好落在一处。

  5. 如实地画出回环

    评审不通过、验证不通过、关闭后又重开:它们各自都在某个特定步骤上回到流程之中。假装工作是线性的,正是让估算最后描述出一个谁也没经历过的流程的原因。

  6. 拿真实案例来检验

    取上个月走完这个流程的十个事项,逐个放进图里走一遍。那些走不通的事项,会告诉您缺了一条出口,或者某条标准其实只存在于某个人的主观判断里。

应避免的错误

  • 标准含糊

    “严重”“紧急”“重大”——每位读者都会自带一套门槛,于是这张图交付的是标准化的外观,而没有标准化的实质。

  • 出口彼此重叠

    如果一个事项确实可以走两条路,两个人就会把它分向不同方向,而且两人都有道理。把分支划成互斥的。

  • 只有一条出口的决策

    如果只画了一条路,那它就不是决策。要么把另一种结果也画出来,要么把它改成一个普通的流程步骤。

  • 五层深的决策嵌套

    长长的决策链既难以追踪,也更难修改。当这棵树确实很宽时,在图旁边配一张决策表,通常比再加几个菱形更清楚。

制作您自己的决策流程图

把缺陷分级示例作为您自己的图表打开,然后把里面的问题换成您的团队实际会做的那些决策。

制作您自己的决策流程图

相关指南

常见问题

什么是决策流程图?

一种结构以决策点为主、而非以顺序活动为主的流程图:每个菱形提出一个问题,每条标注过的出口通向不同的处理方式。分级、资格审查、升级规则和审批路由,都属于决策流程图。真正把它们区分出来的设计约束是:每个决策的各条出口必须把每一种情况恰好覆盖一次,这样任何按图行事的读者都会走到同一个结果。

一个决策可以有两个以上的结果吗?

可以,只要这些结果穷尽且互斥。一个变更申请分成标准、常规、紧急,就是一个干净的三路决策。真正会带来麻烦的,是带五六条出口的决策,它往往其实是套在一个菱形里的两个决策——拆成两个之后,两个都更好回答,日后也更容易修改。

决策标准应该写在哪里?

写在决策本身上,而不是附录里。在 QueryChart 中,每个步骤都带一个备注字段,门槛、定义或对制度条款的引用就该写在那里。放在另一份文档里的标准,只会被查阅一次、被大致记住、然后被不一致地使用——这正好抵消了把决策记录下来的全部意义。

怎样表示一个回跑的决策?

把这条出口指向它所返回的那个步骤的行号。代码评审不通过退回开发,或者验证不通过重开缺陷,两者都只是一条连回图中间的连线。回环是正常的,把它们画出来,正是让决策流程图对流程真实包含多少返工保持诚实的方式。

本指南所用的模板

缺陷分级流程图(bug triage) — 缺陷分级流程图:缺陷受理、复现、重复项检查、严重程度与优先级、升级、修复、代码审查、QA 验证与发布上线。

Browse all 流程图与业务流程映射指南