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

笔者分享了搭建一个基础的任务协同模块中重要的部分和细节点，具体可分为三个部分。让我们来看看吧。

这段时间主要做了一件事情，重新改善了我们公司的产品中的一个任务协同模块。当然这个模块并没有像teambition这么庞大的以项目为主体的任务协同系统，而是类似于今目标、销售易下的一个子模块应用。这个模块虽然看似简单，但是我在实际设计的时候，还是踩了不少的坑，需求方案总共经过了两次大改。到现在整体的框架已经完成。

因此这篇文章的主要目的是对这段时间的一个复盘总结，讲一讲我认为在搭建一个基础的任务协同模块中重要的部分和细节点。

1. 构成任务的成员

先从实际的场景出发，在实际的工作中场景中任务形式会根据不同公司不同部门，任务形式会千差万别。总结起来，大致有以下几个场景。

场景一：发起人直接分配任务给责任人，并且发起人能够实时查看任务进度和完成情况。

场景二：发起人发起任务给自己，即责任人是自己，但是需要一定的其他人员有查阅的权限。

场景三：发起人带上级或者他人进行发起，需要这个上级有查阅的权限。

1.1 发起人、责任人和参与人

在这三个场景中，发起人和责任人之间的关系有可能是上下级关系，也有可能是同部门的同事，或者发起人和责任人。在我们原先的产品任务模块的发起的权限逻辑中，发起人在创建任务的时候能够选择责任人只能是自己或者直接下属。但是这样的设定太过死板并且是不符合实际的场景的。

这是任务模块的第一个细节点，即一个发起人在整个产品中是有其对应的一个角色权限的，那么其在发起的时候能够选择的责任人是能够在什么范围内进行选择呢？

回到场景，显然发起人能够选择的责任人范围应该是能够在全公司内进行选择。要特别说明的是，这是在没有项目组功能前提下。

再次回到场景，我们会发现实际的任务中并不常常是一个责任人在执行完成任务，往往是多个人员共同执行一个任务。比如一个大扫除的任务，往往是多个人共同完成拖地这个任务。

那么我们设计成可以选择多个责任人可不可以？

答案是不行，我认为原因有两点：

第一点，设定成多个责任人之后，那么之后在分配任务相关的编辑权限时候，只能授予相同的权限，那么问题来了，如果拥有相应权限的责任人到达一定数量很容易导致，任务进度更新、状态变更的混乱。

第二点，多个责任人的设计，会导致其他人找任务相关人员的时候找不到需要的人员，在界定责任的时候也容易造成混乱，这不符合这一模块提高效率的需求目的。

那么为了解决这个问题，就需要另外增加一个“参与人”的选项。参与人类似一个弱化的，权限更低的“责任人”，因此与责任人一样，发起人能够在全公司的范围内进行选择，更重要的是能够多选。因此，发起人、责任人和参与人三者构成了任务核心。当然参与人是不强制选择的。

---

很赞哦！ (0)