任务结构设计都包含哪些逻辑

我们的项目一般是面向政府部门，政府部门的各级单位和不同级别人员中，有上下级关系，经过各种了解和调研，在他们的日常工作中会有很多上级部门下发给下级部门的工作任务，然后由下级对上级下发的任务进行反馈。

在数字化改革之前，客户一般是通过纸质文件、IM软件如浙政钉等平台进行文件转发；在数字化改革开始以来，大量的系统上线，包括面向C端的为民服务的应用，以及部门间的多跨协同应用，那么很多线下的工作/任务流程都搬到了线上，要做好系统，就要深入各单位部门了解其中业务，并与其一起探讨线上流程的必要性与可行性，做了多个项目后发现，==任务下发及反馈功能，属于常态化需求==

在梳理了大量业务后，总结出几套逻辑框架，我们可以从以下功能进行设计

场景一：发起人直接分配任务

发起人、责任人、参与人

首先需要解释一下“人”这个概念，在一些任务中，尤其是跨部门协作任务中，很多情况往往是以“部门”为单位进行展示，所以在选择责任人或参与人时，还可能选择的是部门。还有一种情况，就是这个人可能在多个部门，这种情况比较复杂也不常见，暂不考虑。

在实际情况中，发起人、责任人、参与人三者之间的关系不不确定，即可能是上下级关系、也可能是平级，回到场景中，所以发起人在选择负责人或协作人时应该从整体组织架构中选择（在没有项目组的前提下）。

定好选择范围后，则还要考虑责任人选择数量，我们需要设计成可选择多个责任人吗？ ==不行！==

据观察，在实际业务中，每个任务所分配的责任人/部门也只有一个，不存在多个负责人的情况，否则双方意见不一致时容易造成任务管理混乱。同时，不同的负责人对任务的理解也可能是不一样的。
在实际业务中，多个责任人的设计，会导致其他人不容易找到相应的人员，界定责任也容易造成混乱，容易降低效率。
在产品设计中，责任人和协作人的权限大概率是不一样的，责任人主要是管理整个任务，任务的进度、退回、转交、办结、添加参与人等权限都应由责任人管理。如果设计了多个责任人，他们都有相同的权限，在到达一定数量容易导致任务进度的更新、状态的管理变得混乱，这个不仅仅是业务逻辑会变的混乱，在开发层面也有同样的问题。

基于以上，参与人的重要性也凸显出来，为了让其他人能够参与到该任务中，可通过添加参与人的方式进行设计。参与人的权限一般比责任人低，在我遇到的业务场景中，参与人一般的需求是汇报任务进度、反馈任务情况、上传自身的任务成果。

别忘了还有任务发起人（创建者），任务创建者都能干嘛呢？创建完任务就不管了吗？这个等我调研一下再补充…

总结：一般情况下任务负责人只能选择一个，且必选；而任务参与者能选择多个且非必选。

其他任务信息

一般包括：任务名称、任务内容、任务类型、优先级、开始结束时间、备注、标签、子任务等任务名称和内容这种 input、textarea 等类型组件最好规定字数限制，否则字数过多在展示或代码方面会出现报错等问题。

场景二：任务下派

一般是由上级角色给下级角色发布任务，下级角色反馈任务。该任务流转过程可能只有一个节点，也可能是多个节点，多个节点相对复杂一些，需要注意不同节点下任务负责人的权限控制。

任务下发

任务下发者创建任务，填写完任务信息后，会从组织架构树中选择要下发给的账号或部门，这里有两种下发方式

直接下发给某个人：

这个比较简单，下发给某账号后可直接获取到该信息，那么账号的APP、短信、系统中可直接收到任务信息。

下发给某部门：

当组织庞大、且办公地点分散，一个组织不清楚另一个组织的负责人是谁，且组织人员也有经常变动的情况，会直接给某部门发送任务。到了部门如何分配任务呢？我这边思考了两种方案：

该部门所有人员均可查看且可反馈该任务信息，但是该方案容易踢皮球，每个人都觉得任务应该别人去做。同时，每发布一个任务则该部门所有人都会通知，包括不相干的人，这无疑是一种打扰。
在该部门设置负责人，由负责人去做该事情。这显然是更加合理的方案。

具体设计细节，可查看[[组织架构管理设计]]

任务退回

当部门收到任务后，可在系统中标记任务完成，则该任务实现了闭环的操作，但是当部门觉得该任务不合理、不应该由我来做等情况，可以将任务退回。

退回操作一般是直接退给任务下派者，退回后下派者可收到退回消息，可以选择重新编辑任务进行下派或直接删除任务。

当任务流程有多个节点时，一般是退回给上一个节点。但是具体需要根据业务情况而定，比如需要统一退回到某个节点，或者统一退回给起点，更加灵活的话由用户自己选择退回到哪个节点，但是后面的情况非常之少，同时现实中这样做也不是很合理，所以一般不会去用。

下图是一套较为复杂的业务流程

任务状态

任务常见状态有：草稿、待审批、待认领、待开始、进行中、已完成、已退回、已关闭等，我们分别分析。

草稿

发起人先填写内容，不做任务下发，后期可随时更改，待时机成熟时再对任务进行下发。

待审核

这种状态涉及到审核操作，即任务创建完成之后，需要经过审核才可进入实施阶段。在数据权限的控制下，除了发起人，审核人是第一个看到该任务信息的角色，通过后相关责任人和参与人才可看到任务信息或收到任务通知。审核不通过，则退回给发起人，发起人需要重新修改提交或直接删除。

待认领

与待审核类似，当负责人收到任务后，会评估该任务具体情况，比如工作内容是否具体、时间安排是否合理、负责人是不是应该是别人等，如果符合，那么就可以认领，不符合则退回给发起者，发起人需要重新修改提交或直接删除。

已退回

在待认领或待审核过程中，被审核员或负责人退回后，会将状态变为“已退回”。

待开始

即执行者收到任务但是还没开始实施，在创建后/认领后/会自动进入该状态。这种状态有点鸡肋，作为执行者，我在完成任务后将任务标记为已完成就行，如果还要打开平台将任务由待开始标记为进行中，增加操作且有点浪费时间了，面对大量的任务，则容易引起手忙脚乱的情况。当然也有解决方案，比如需要在任务中配置开始和结束时间，不过需要考虑的情况依然很多，所以这种状态不建议加到流程中。

进行中

有两种方式进入该状态：

若配置了开始时间，则该任务根据开始时间自动变为“进行中”
手动标记我依然觉得该状态鸡肋，理由同上，站在领导角度来看，我只需要知道任务是否完成，完成质量如何（结果导向）。其他的只是辅助信息，可有可无。

已完成

需要负责人手动标记。任务的完成一般代表着闭环，从实际情况来说，任务的完成代表了前面所有的任务信息都已经固化，即任务信息不能更改，但是在设计过程中，尽量考虑极端情况，比如进行中忘记添加成员等等，所以在任务结束后，各种任务信息我一般考虑都是可以继续更新，只是状态变化而已。已完成还可以细分两种状态：按时完成；超时完成。是根据任务截止时间和标记完成状态共同决定该任务是按时还是超时完成的。在考核要求比较严格的公司中，尤其是政府部门，会比较在意这个，他们会统计所有人的所有状态，对工作人员进行加减分。

总结

在设计任务结构时，除非客户要求，我一般不会考虑这么多状态

客户会被需要操作繁多的任务状态有所抵触
开发也会被如此复杂的业务逻辑所逼疯
在后期维护方面，都要付出较大的成本，降低效率，对公司、客户、开发都不好

我日常设计思路

在基础流程的情况下，状态只需包括：未完成、已完成
在有审核流程的情况下，状态包括：待审核、已退回、未完成、已完成
在有认领流程的情况下，状态包括：待认领、已退回、未完成、已完成

子任务

有时候，任务会分主任务和子任务，我们分析一下子任务的创建逻辑。子任务是基于主任务进行创建，所以在填写子任务参与人，应该是从主任务的参与人中选择。主任务状态需要根据子任务状态变更，当子任务没有全部完成时，主任务不可点击完成；当主任务完成时，不可再新增子任务或更改子任务为“未完成”状态。

任务动态

任务动态主要是溯源，查看各成员的操作和动态。

主要格式为李晨（操作人）+ 创建了（动作）+ 任务（内容）+ 时间
动作包括：创建、认领、退回、完成、更新、重做等
内容包括了任务信息中的所有字段内容与动作具有关联性，比如李晨创建了任务，就不能展示为李晨创建了备注，而是李晨更新了备注。