从无到有：任务状态与工作流的设计思路

　　不管是项目协作还是处理事务，都会包含着一些基本的业务流程。如何有效地将项目有条不紊的进行，不妨了解一下任务状态与工作流的设计思路。
　　一、概述
　　无论你的公司是采用邮件还是项目管理工具进行项目协作，处理工作都会包含着一些基本的流程从想法的提出到最终交付物的产出，或是计划的搁置。我们把这些任务所处生命周期的节点称为【任务状态】，而任务在状态之间的流转称为【工作流】。
　　那么，关于任务状态和工作流的设计过程中，我们还有哪些思考和选择？请看下文。
　　二、为什么引入【任务状态类型】？
　　Worktile7。0引入了【任务状态】的概念，并且支持自定义，也就是说客户可以根据自己的实际工作场景配置任务状态。
　　但是，这回带来一个问题：如果对每一个任务状态都加以区分，那么在报表、统计等环节（例如统计任务的延期率），将极大的增加配置的复杂度。
　　实际工作中，我们会意识到：进行中的状态，可以有“设计中”“开发中”等自定义任务状态，但是其本质都是已开始但未完成的状态。所以，虽然客户自定义的任务状态千变万化，但他们必属于三种基本【任务状态类型】，即：未开始进行中已完成。
　　如图1所示：开发和销售任务的状态有很多，但是都属于三种任务状态类型。
　　图1：以开发和销售的任务状态为例
　　【任务状态】体现在展示层面，而【任务状态类型】则体现在数据层面。例如，在【配置报表】的过程中，如果我们对状态进行统计和筛选的话，筛选值的设定将限于三种基本任务状态类型。
　　三、为什么默认任务状态是必选？
　　任务状态和任务流代表的是工作的流程，所以任务状态不能为空，我们必须设置默认任务状态也就是定义一个新建任务，它的初始状态是什么。
　　在任务状态设置的过程中，我们必须选定一个状态为默认状态。
　　例如推送类型的任务，其初始状态为【未开始】。
　　图2：【状态设置】界面
　　四、任务状态管理是统一还是分散？
　　在第一篇设计思考中，我们曾提到中庸化的思维。所以，我们并没有选择给每个任务类型设置自己的任务状态库。但是，任务状态有两个特点：
　　任务状态与任务类型相关，它本身就是一种分组形式；
　　任务状态的数量不会特别多。
　　综上，我们最终选了统一管理的形式，通过【状态管理】统一增删改，配置任务类型的时候调用即可。
　　图3：从【状态管理】中进行选择任务状态进行配置
　　五、工作流如何构成
　　介绍完任务的状态，我们可以开始介绍任务状态之间的流转即工作流了。
　　在此之前，我们以Worktile运营同学推送文章为例帮助读者有一个基本认知。一个推送类型的任务，创建之后的默认状态为“未开始”，通过一系列流程和动作，最终流转到“已发布”的状态。未开始不能直接到“已发布”，这与现实工作的流程不符，而设计中的状态则可以。
　　推送任务的工作流如图4所示：
　　图4：运营推送任务的工作流
　　一个完整的工作流由以下基本元素构成：
　　转化名称：帮助成员理解该转换的含义
　　起始状态：工作流的初始状态
　　目标状态：工作流的最终状态
　　流程条件：对此流程进行操作的权限条件
　　动作设置：工作流转后发生的动作
　　要设置一个工作流，我们需要明确这些元素（流程条件和动作设置不是必须）。
　　要合理配置工作流，我们需要注意以下两点：
　　工作流是单向的；工作流的起始状态和目标状态决定了这个工作流，所以当二者互换位置之后，就成了一个新的工作流。所以说工作流是单向的，如果我们需要一个反向工作流，则需要重新添加。
　　工作流与任务类型的对应关系；同一个任务类型对应多个工作流，而一个工作流只对应唯一的任务类型。
　　结语
　　不同项目中的不同类型事情，会有不同的执行流程。如果缺乏有效的项目管理工具，哪怕项目干系人都清楚项目流程，但是在项目的执行、回顾和优化过程中，仍会面临诸多困难。
　　同时，缺少一种承载物，任务执行中或多或少地都会带有“人情”因素，导致执行不力。