B端简单的责任治理模块的搭建

这段韶光紧张做了一件事情，重新改进了我们公司的产品中的一个任务协同模块。
当然这个模块并没有像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端产品中主要的角色权限和流程准确的特点。

因此思考的时候，先确定任务成员，继而在确定任务状态和角色权限。
要记住梳理完成之后，一定要重新在将各个流程过一遍。
对付一些细节，比如任务提醒，任务不同状态下，各个成员所能决定的权限等等。
都要准确的定义下来。

作者：十一笔产品路上的新人，微信公众年夜众号：产品汪的个人教化。
我会定期发布自己的产品感想，渴望与你一起互换。

本文由 @ 十一笔 原创发布于大家都是产品经理。
未经容许，禁止转载

题图来自Unsplash，基于CC0协议