流程引擎设计的复杂性远超想象——从预设规则到动态调整，一个自媒体公司的短视频协作系统案例揭示了流程设计的层层陷阱。本文将深入拆解业务场景与用户需求的博弈，展示从刚性流程到无流程设计的四次关键迭代，以及最终父子流程结构的精妙平衡。

之前我在产品经理初识流程引擎中分享了流程引擎的基本概念，本文在原文的基础上进行延伸，分享如何进行流程的设计。

本文将以一个案例作为切入点，分析不同业务场景下的流程究竟应该怎么设计。

场景：有一个自媒体公司，其中有一个专门负责短视频运营的部门，其岗位和工作内容如下：

需求：设计一套产品，可以用于这些岗位之间工作的协调和流转。

本文将以此需求为例，分析如何设计该产品的流程，从而实现各个岗位工作的协调和流转。

业务决定流程

我们先不讨论岗位的问题，只从工作流出发，在正常的工作流程中，上个岗位的“输出”是下一个岗位的“输入”，比如运营先发布选题，编导拿到选题后设计脚本，文案根据脚本编辑文案…以此类推，最终剪辑师完成剪辑后，将成片交付给运营发布，所以你首先想到，常规的流程应该是这样的：

但在实际的工作过程中，不一定所有场景都需要经过上述所有的流程节点，比如有一种叫做“切片”或者“混剪”的短视频，这种是将直播录屏剪辑精华部分形成一条短视频，这个过程往往只需要剪辑师进行剪辑即可，其流程如下：

这个时候你会想到，也许可以根据所要制作的内容类型来配置工作流。但这个时候会遇到一个新的问题，就是不一定同一种内容类型会永远遵循同一流程。举个例子，现在需要制作一条内容类型为“产品宣传”的短视频，这个时候会有两种可能：

1. 要宣传的是新产品，需要进行拍摄。
2. 要宣传的产品之前已经有拍摄素材，本次只是重新制作一条新的宣传短片。

那么你会发现，同样都是产品宣传，有时候需要进行拍摄，有时候又不需要，所以如果仅按照内容类型来配置流程是行不通的。

业务+条件决定流程

既然仅按照内容类型行不通，于是你想到，可以给内容类型加上条件来设计流程，比如都是“产品宣传”，可以再加一个条件，就是选题的时候需要选择新产品还是旧产品，这样就会得到两个流程：

就在你以为这个问题终于解决的时候，剪辑师告诉你，有一个旧产品需要制作的宣传视频，之前拍的素材都不符合条件，需要重新拍摄，你感觉天都要塌了，如果要叠加更多的条件，配置流程的工作量将变得非常可怕，也许只是一个小小的流程节点的不同，可能同一个内容类型你可能就要配置好几个流程。

业务+用户决定流程

这个时候你绞尽脑汁，一个天才的想法在你脑海中冒出来：既然业务多变，难以预先通过系统进行配置匹配到所有场景，何不把流程交给用户决定，比如说，由每个岗位的人选择将自己的输出成果交付给谁，如果当前岗位收到的成果不足以支撑他开展工作，他可以主动拉入另外一个原本不在流程里面的岗位进入流程进行协作，比如上文中提到的旧产品的宣传视频制作，当剪辑师觉得当前的素材需要摄影师重新拍摄的时候，他可以指派给摄影师，将原本不在流程节点的摄影环节拉入流程，具体流程如下：

你感觉到好像所有问题都解决了，但用了一段时间之后，摄影师跑过来告诉你，他实际上拿到脚本之后就可以进行拍摄工作了，偶尔也需要等文案完成，但根本不需要等设计完成，但现在的流程要等文案和设计做完他才能看到脚本，效率太低了，还有一点，就是并非每次都需要文案和设计的，流程太死了，根本用不了。

用户决定流程

于是你就想着，既然每个流程都能拉入另外一个节点加入流程，何不干脆不要配置流程，就让用户在实际业务操作中自行决定自己完成工作后，下一个节点交接给谁。于是你调整了策略，后台只配置流程节点，由前端用户决定流程，这样每个流程节点都可以相互组合成足够多也足够灵活的流程，如下：

这里并没有将所有场景都画出来，但你会发现，上方的各种流程场景，如果真的要通过后台来配置，随着流程节点足够多，则会叠加出无限多个流程，这是非人力所能配置的，但是如果是由用户来决定流程，那么每个人只需要关心他做完的内容应该交给谁，或者他要做的东西还缺少谁提供的内容就可以。

当你得意地拿着这个流程给各个岗位分享的时候，设计师刚看完就面露愁容，设计师认为，这样流程的确是足够灵活了，但是如果一个内容需要脚本和文案，但是设计只需要拿到脚本就可以先设计，等到文案做完了，再把文案放到设计图上去就可以，但是目前的流程，得等脚本做完给文案，文案做完给设计才能开展工作，很耽误事。

没有流程的流程

这个时候，死掉不少脑细胞的你想到了一个更加天才的设计：上述的流程之所以不能满足设计师的需求，是因为流程是串行的，如果改成并行，就可以解决，但是并行同样会衍生出很多复杂的流程，既然流程怎么做都不够灵活，那就干脆不要流程，运营发布选题的时候，只需要告诉系统，这个需求需要哪些岗位来完成就行，然后接到需求的每个岗位也都去标一下自己的输出需要由哪个岗位提供内容就可以，这样在实际业务中，就会根据每个人制定的节点形成一个“没有流程的流程”。

比如，运营发布选题的时候，把所有岗位都选上，最后运营只需要拿到剪辑的产出即可，于是此时，这个需求自动形成了如下的流程：

文案策划看到需求的时候，告诉系统说他需要脚本；设计师看到需求的时候，告诉系统，他需要脚本和文案，这个时候，需求又自动生成了新的流程：

在上方的流程中，脚本完成后，设计师就可以拿到脚本先做设计，之后等文案完成再补充设计图上的文案，而无需等着文案完成才能做设计。

拍摄看到需求时，告诉系统需要脚本；而剪辑则告诉系统，需要脚本、文案和拍摄的素材以及设计图，于是他们两个人指定之后，需求又有了新的流程：

这样，每个人到了系统上只需要关注自己需要的内容完成没有，也可以选择获得哪些内容后便可以开展工作，而无需等待全部需要的内容输出完成。

到目前为止，好像这个流程已经能够满足使用了，但没过多久，几个岗位的负责人都跑过来找你，说你这个流程快把他们弄失业了，需求过来了，直接就底下的人去接活，他们根本不知道有什么一回事；底下的人做完了，质量如何他们也把控不了，要求把他们也加入到流程里面去。

父子流程

你头发大把大把地掉，觉得最后设计的流程已经很完美，如果再加入每个岗位内部的独立流程，原来的主流程可能又会出现问题，突然你灵光一闪，既然主流程不能动，那就给每个主流程节点增加一个子流程，子流程主要做三件事：

1. 决定是否接需求。
2. 决定谁来做需求。
3. 决定产物是否合格。

按照上述的需求为例，所有节点都加上子流程，改造后的流程如下：

上图描绘的是每个岗位管理员接受需求后指派人员，人员完成输出后，产物审核通过的流程；如果管理员一开始就拒绝了需求，则相应岗位的节点会显示该需求已经被拒绝；而如果人员的产出被管理员认为是不合格的，则人员需要根据需求继续完善，直到管理员接受产物之后，下一个节点的岗位管理员才能够看到上一个岗位的输出产物。

以上便是本文的全部内容，感谢阅读。