端简单的任务管理模块的搭建

　　笔者分享了搭建一个基础的任务协同模块中重要的部分和细节点，具体可分为三个部分。让我们来看看吧。
　　这段时间主要做了一件事情，重新改善了我们公司的产品中的一个任务协同模块。当然这个模块并没有像teambition这么庞大的以项目为主体的任务协同系统，而是类似于今目标、销售易下的一个子模块应用。这个模块虽然看似简单，但是我在实际设计的时候，还是踩了不少的坑，需求方案总共经过了两次大改。到现在整体的框架已经完成。
　　因此这篇文章的主要目的是对这段时间的一个复盘总结，讲一讲我认为在搭建一个基础的任务协同模块中重要的部分和细节点。
　　1。构成任务的成员
　　先从实际的场景出发，在实际的工作中场景中任务形式会根据不同公司不同部门，任务形式会千差万别。总结起来，大致有以下几个场景。
　　场景一：发起人直接分配任务给责任人，并且发起人能够实时查看任务进度和完成情况。
　　场景二：发起人发起任务给自己，即责任人是自己，但是需要一定的其他人员有查阅的权限。
　　场景三：发起人带上级或者他人进行发起，需要这个上级有查阅的权限。
　　1。1发起人、责任人和参与人
　　在这三个场景中，发起人和责任人之间的关系有可能是上下级关系，也有可能是同部门的同事，或者发起人和责任人。在我们原先的产品任务模块的发起的权限逻辑中，发起人在创建任务的时候能够选择责任人只能是自己或者直接下属。但是这样的设定太过死板并且是不符合实际的场景的。
　　这是任务模块的第一个细节点，即一个发起人在整个产品中是有其对应的一个角色权限的，那么其在发起的时候能够选择的责任人是能够在什么范围内进行选择呢？
　　回到场景，显然发起人能够选择的责任人范围应该是能够在全公司内进行选择。要特别说明的是，这是在没有项目组功能前提下。
　　再次回到场景，我们会发现实际的任务中并不常常是一个责任人在执行完成任务，往往是多个人员共同执行一个任务。比如一个大扫除的任务，往往是多个人共同完成拖地这个任务。
　　那么我们设计成可以选择多个责任人可不可以？
　　答案是不行，我认为原因有两点：
　　第一点，设定成多个责任人之后，那么之后在分配任务相关的编辑权限时候，只能授予相同的权限，那么问题来了，如果拥有相应权限的责任人到达一定数量很容易导致，任务进度更新、状态变更的混乱。
　　第二点，多个责任人的设计，会导致其他人找任务相关人员的时候找不到需要的人员，在界定责任的时候也容易造成混乱，这不符合这一模块提高效率的需求目的。
　　那么为了解决这个问题，就需要另外增加一个参与人的选项。参与人类似一个弱化的，权限更低的责任人，因此与责任人一样，发起人能够在全公司的范围内进行选择，更重要的是能够多选。因此，发起人、责任人和参与人三者构成了任务核心。当然参与人是不强制选择的。
　　图1。1明道云任务新增窗口
　　1。2增加其他任务成员
　　在我们原先的任务管理模块中，还有一个审批人的角色，这个角色在我们原原先的设计当中有三个作用。
　　对任务发起进行同意退回。
　　对任务取消进行同意退回。
　　对任务的完成进行同意退回。
　　在分析竞品的过程中我发现，今目标存在着这样的一个角色。
　　图1。2发起人对已完成的任务进行审核
　　这个角色是由发起人重合的的，在责任人点击完成任务之后，会有发起人对任务的完成情况进行审核，是通过不通过。
　　但是我们原先这样的设计不仅笨重，而且会让任务流程显得太过于像一个工作流程。而今目标虽然有审批人这个角色，但是因为其功能简单，并且与发起人重合，所以并没有太过笨重。
　　图1。3存在审批的任务主流程
　　在我们分析过后，我们认为应该直接删除审批人这个角色和审批功能。不仅是出于让任务更轻的目的。而是我们的产品面对企业是施工企业，我们已经有专门的模块放置众多详细且复杂工作流程。不需要在这个模块中与之重合。
　　图1。4无审批的任务主流程
　　删去了审批这个节点之后，任务流显得十分清晰（不包含取消和修改）。
　　1。3其他任务信息
　　任务其他信息内容填写，就是一些比较基本的东西，比如任务的名称、任务内容、任务重要级别、任务日期等等。
　　一个比较细节的地方在于，在新增的时候，会希望能够给用户一个足够简单直接内容填写。这是因为一个任务的创建的时候，通常细节的部分并不一定已经决定的十分清晰，同时创建任务越是简单，用能够降低用户使用这个功能的成本，是符合任务管理提高效率的核心需求的。
　　图1。5teambition任务新增
　　Teambition在创建任务的时候只要输入任务主题，就能够创建，甚至责任人都能在任务发起之后进行选择或是等人认领。
　　这是一点交互的细节，毕竟一个OA软件的核心目标之一就是提高效率，如果这个任务协同模块显得十分繁杂的话，也就失去一个原来的意义。
　　2。任务状态
　　任务有三种基本的状态：进行中、已完成、已取消。
　　首先要说明的是任务状态的是由两个方面决定的。
　　第一，组成任务成员有哪些。比如上文如果增加了审批人。那么任务状态至少需要增加一个待审批状态。
　　第二，由是否增加同意拒绝这个功能决定。比如，今目标在发起任务之后，任务达到责任人手中时，需要责任人点击同意才能。这样就衍生出了两个状态。未同意拒绝之前的待接受和拒绝之后的已拒绝。
　　我个人不同意增加多个任务状态，从时间延迟这个点考虑，每多加一个状态，就会让时间延迟延长。想一想，要是最后审批人一直忘记审批，是不是任务就一直处于待审批的状态了。
　　3。角色权限
　　权限总的可以分为三种：任务取消、任务修改、任务完成、任务查阅。
　　我们先看看今目标和明道云的权限怎么分配。
　　图3。1今目标和明道云的任务权限分配
　　可以看到相比于今目标，明道云的任务权限分配的更加广泛一些。我们改善后的任务模块是与今目标一致，但是没有审批和同意这个功能。对于角色权限的分配这一块，基本上跳不出这个框架，在实际设计过程中还是要根据所面对的企业用户来衡量设定。
　　4。总结
　　在设定任务管理这个模块中的时候，还是不能忘记B端产品中重要的角色权限和流程准确的特点。
　　因此思考的时候，先确定任务成员，继而在确定任务状态和角色权限。要记住梳理完成之后，一定要重新在将各个流程过一遍。对于一些细节，比如任务提醒，任务不同状态下，各个成员所能决定的权限等等。都要准确的定义下来。