“效率”这个词在工作中出现的频率有多高，我相信大家也都了解，大多数效率低下的情况大多数是因为没有合理的计划和任务分配。那么如何提高单位时间完成的工作量，提高工作效率？这就是任务管理工具的目的所在。
理解业务
在清楚地知道目标之后，我不能够马上把原型、文档全部安排上，更重要的是我需要先理解“任务管理”的业务含义。
在20世纪初，科学管理的方法由美国人弗里德里克·温斯罗·泰勒提出他详细为记录每个工作的步骤及所需时间，设计出最有效的工作方法，并对每个工作制定一定的工作标准量，归划为一个标准的工作流程；将人的动作与时间，以最经济的方式达成最高的生产量。而泰勒在科学管理理论中所倡导的管理方法其实就是现在的任务管理法。
产品整体设计
在对任务管理有一个初步的理解之后，就可以开始发散思维了。所以我可以使用思维导图先把我理解的任务管理工具搭出来，之后再慢慢进行调整。
我先搭建一个MVP，在实际开发之前我需要有一个最低成本的试错方案。但是在思考一下以上关于任务的架构来说，这样的设计未免太过简陋了，如果我们自己团队搭建一个系统自己使用的话也还凑合，如果要把这当成一个市面上的产品推广出去肯定是没法正常使用的。
产品定位
在清楚业务之后，我们需要先解决一些问题。
1、我们的产品能解决用户什么需求？
那我们要怎么做才能get到用户的痛点呢？我们先假设用户需要一款工具提高他们的工作效率，我们都知道工作效率=工作量÷工作时间，在工作量不变的情况下，节约了工作时间，那工作效率就提上去了。
那么有什么情况会导致时间的浪费呢？
1） 工作没有形成流程，工作杂乱无章，缺少团队配合。
2） 工作没有计划。所谓磨刀不误砍柴工，研究显示每天花10分钟时间制定工作计划，可以节约2小时的工作时间。
3） 在任务分配不当的情况下，缺少灵活调整机制，导致问题一直搁置直到无法解决的处境。
所以我们的产品需要做的就是帮助用户节约工作时间，提高工作效率，同样的，企业也能够节约人力成本。
2、我们的产品面向怎样的用户群体？
基于第一个问题，我们把产品用户定位于服务互联网中小企业。
首先，选择中小企业的原因主要是因为我们就大型企业调查显示，大型企业对人员管理、任务管理基本有自己的一套流程，他们更趋向于定制化并且很多已经搭建了自己的管理工具，所以就我们团队本身的开发资源和大型企业的获客成本考虑，我们至少在初始阶段暂时pass了大型企业的情况。
其次，任务管理在很多行业都是行得通的，我们选择从互联网入手有两个原因。第一，B端的产品相对于C端需要更多的学习成本，与之相对应，互联网公司的学习氛围是高于其它传统公司的；第二，互联网开发流程，从需求的提出到项目的上线，在开发过程中所运用的模式和任务管理的模式是相匹配的。
3、对比市面上的竞品，我们有什么优势或劣势？
先说优势，我们公司除了我们团队之外还有很多其它项目的开发团队，就是说我们可以先在公司内部推广，在产品迭代成熟之后才走向市场。相当于说我们是自带种子用户的。并且，公司在发展过程中积累的资源可以为产品带来一些价值。
再说劣势，现在市面上已经有成熟的产品，作为晚辈，我们肯定不能太过造次，也造不了什么次，我们肯定没办法一开始就在功能层面上和竞品硬刚，而且就单单任务管理我们也没办法和其它产品竞争的。所以，我们计划增加产品的可扩展性，并以任务管理为核心将其它工具引入我们的产品，目的在于以低成本效率工具作为切入点进入市场。当然了，必须先把核心功能做好。
系统框架
B端产品的整体设计讲究体系性和结构性，我们可以采用先总后分的形式，先考虑大体的功能再慢慢填充细节。基于产品定位，重新梳理一下思维导图。
我们可以发现产品的蓝图已经丰满了一些，而且并不是说在设计任务管理工具的时候只把目光局限在这个点上，可能我们可以多考虑一些其它方面，像基础功能、项目管理都是根据核心功能任务管理衍生出来的。在把框架搭好之后，我们就可以先对核心功能开始细节设计。
产品细节设计
在系统框架定下来之后，接下来的工作就是基于产品蓝图，逐一分析业务细节，设计产品的具体功能。这时候就如同建造一栋房子，我们已经把房子的地基打好了，钢筋水泥也安排上了，怎么让这个房子看起来更美观、住起来更舒服就是现在该做的事情。
流程
任务管理流程方面有两种设计思路，一种是系统默认配置流程，用户直接使用就可以，优点是减少用户自助配置流程产生的学习成本，缺点是系统的灵活性降低，用户个性化流程的需求无法达到满足；另一种是用户自助配置流程，优缺点和第一种方法的相反。
在项目前期，我们优先选择了第一种设计思路，原因如下：
1、 在项目上线初期，我们不希望用户一进系统就被一堆复杂的概念和流程逼走，而是用轻量化的设计和简易的操作流程把用户留住，尽量降低用户的学习成本。
2、 自定义流程的开发成本远远大于系统默认流程的开发成本。
3、 我们将用户定位在互联网中小企业，因为他们的开发流程相对简单，系统默认流程配置就可以满足用户的需求。
在需求调研初期，我们先了解用户在开发过程中所涉及到的角色，主要包括项目经理、产品经理、开发人员、测试人员、UI设计师等。比如项目经理需要给开发人员分配任务，产品经理需要把需求告诉测试人员，我们发现不同的角色在流程中可能处在一个相同的节点，所以我们可以根据不同的场景把角色稍加整合并将任务分为四个节点，分别为任务创建人、任务处理人、任务审核人、任务结束。这样的话，我们就可以处理一下这些节点的关系，比如任务创建人分配任务给任务处理人，任务处理人完成任务之后把任务给到任务审核人审核，任务审核人审核通过之后任务结束。在把主流程确定下来之后，就可以确定其它子流程了。
权限
设置权限的目的是为了明确任务管理工具的“管理”功能，而且管理者和被管理者应该拥有不同的权限设置。不过，一个管理者对应多个被管理者的情况很常见，多个管理者对应多个被管理者的情况也是存在的，所以在管理者前面我们设置了超级管理员，超级管理员只能有一个，拥有系统中的所有权限。
在最开始设计权限控制的时候，我们没有把权限控制的范围缩到最小，而且采用了“项目总监”、“项目经理”、“产品经理”这样的名称来进行权限设置，这就导致了权限被多次分割，不同的角色的权限重叠程度高，这就是设计事故了。
后来整合不同角色的权限还不得不多花了一些时间，也更加明白了权限的控制是为了用户更好地使用工具，切忌在设计初期就制定多个不同维度的权限区分导致用户权限混乱。
字段
字段和我们的业务挂钩，在对业务的提炼中，我们可以知道在提交任务的时候，我们要知道“这是个什么任务？这个任务应该由谁来完成？”，所以，任务名称和任务处理人是必不可少的，是提交任务的必填项，但这还不足以完整地诠释任务的含义。
计划时间
大家都知道，制定工作计划的重要性是毋庸置疑的，没有计划的工作就想拿着一把钝刀砍柴，杂乱的工作内容会让我们不知道应该在什么时间点做什么事情。所以，计划时间对于任务来说是重要的，管理者可以根据计划时间判断被管理者的工作情况。
优先级
每个人的工作时间都是有限的，但是为什么别人能够在相同的时间内获得比较多的工作成果呢？在时间管理理论中一个核心的点就是四象限法则，这个法则把要做的事情按照紧急、不紧急、重要、不重要的排列组合分为四个象限，包含紧急且重要的事情、紧急不重要的事情、重要不紧急的事情、不紧急不重要的事情。
我们将四象限法则加入我们的系统，并将其浓缩为急、高、中、低四个优先级。项目成员在工作时可以根据实际情况确定工作的重点，优先处理相对较急的任务，这样的话，即使工作时间有限也可以在工作中生产最大的价值。
任务状态
“这个任务是待解决还是待审核”，任务状态可以给管理者和被管理者一个反馈的作用，表明这个任务还没有结束，还需要有人去处理或者审核这个任务。
任务类型
同类的工作放在一起做可以大大减少工作时长、提高工作效率。反之，杂乱无序的工作任务再加上突发的情况，很有可能让我们感到头大并且削减我们的工作热情。
我们将不同类型的任务加以区分，不管这个任务是处理BUG还是分析需求，这都是对任务的分类，方便任务的处理人对不同类型的任务进行统一处理。
从0到1之后
在产品设计完成之后，在开发完成之后，在产品上线之后，在产品开始推广之后，我们面临越来越多的问题，面临越来越多的需求，面临越来越多的挑战，这时候我们才发现这只是我们迈出的第一步，前面的道路如何我们未曾知晓，等到走过了自然也就知道了。
