对任务、项目管理设计的理解.pdfVIP

对任务、项目管理设计的理解 背景 项目管理 ，任务管理是一个已经被各个产品玩烂了的概念 ，但是玩烂了并 意味着玩好了~即便是 目前的网络上充斥着各式各样的这类工具 ，每个工具都有着自己的侧重点 ，但是如果想要拿来去套 上我司的场景来用 ，似乎都显的很乏力~为啥~用户场景太多太复杂~简单的玩 转 ，复杂的又难用~ 那要怎么搞 ？！ 在做这部分之前 ，我们多次走访了核心用户 ，听他们对产品的设想 ，对产品的需求 ，设计方案更是 一改再改 ，但是似乎总有一些场景让我们的设计无法应对 ，总有一些场景我们无法去满足~很头疼~ 现在回想过来 ，我们当时陷入了一个为了解决单个问题而设计的误区 ，针对用户的问题一个一个去 解决 ，是 会形成一套完整有效的方案的。 没有全局的视角~永远 能解决核心的问题。 灵感 Phabricat o r 当Phabricat o r引入到公司后 ，这种新式的玩法刺激了很多人的神经 ，大家开始研究它与其他工具的 同 ，能够让f aceboo k用来作任务管理的软件 ，绝对 会只是因为它能够跟git 、代码关联这么简单 ~ 个人认为Phabricat o r之所以能够玩转 ，是因为它将任务与项目进行了解耦 ，很多工具对于任务的 认知 ，认为任务必须依托于项目而存在 ，总要有一个space去承载它 ，殊 知 ，这本身就是一个很 强烈的绑定。在phabricat o r中 ，任务 在需要这种强烈的绑定 ，任务与项目变成了同级关系 ，中间 只是一个简单的类似于t ag的简单关联 ，并且随时可以解开。这样任务就变成了一个单体 ，用户 需 要奔走于各个项目之间来看自己的任务 ，只需要在任务页面 ，就可以掌握这些任务的归属。 Phabricat o r中的任务 Redmine 我们团队一直在用Redmine ，虽然在用户体验方面 ，很多同学都有吐槽 ，但是redmine在任务管理上 的设计 ，充分说明了它对任务这个名词的理解。用过Redmine的同学都知道 ，Redmine里面最常见 的两个对象 ：项目和issue。所有的一切都是issue ，无论你是需求、是任务、是bug~ Redmine只认 为这是issue的一个属性 ，仅此而已 ，可以去更改 ，可以去变化 ，但是内容还是那个样子。 Redmine提供的另外一个很有效的设计 ，就是父子产品和父子任务的概念 ，市面上很多项目管理的 工具都将没有对这部分概念做过多的介入 ，因为一旦有了父子级 ，产品界面的展示、父子之间的 继承、产品中的各类配置都将明显的提升产品的复杂度 ，尤其是大部分产品中 ，任务与项目都是有 着强烈的绑定关系 ，这样会更加限制任务的创建 ，用户查看任务的视角将会变的更加跳跃。 发现 结合这两个产品对于项目、任务管理的理解 ，以及分析了诸如Teambit io n、Wo rkt ile、t rello~等任务 、项目的管理工具 ，结合我司特有的用户场景 ，我们发现 ： 解耦任务与项目之间的关系很重要。 同时我们也发现 ，所谓的任务、需求、缺陷等等只 过是任务的一个属性 ，我们无需去限制用户 提交的是什么 ，用户可以根据自己的定义来确定它的类别。 在项目与任务的层级上 ，添加一层父子关系可以更有益于用户对于项目和任务的分类和扩展 ，也 更能符合我们用户的使用场景。 标签是一个有效的分组工具 ，我们曾经尝试让用户自己去分组管理自己的任务、项目 ，但是发现 很多场景下 ，任务可能需要出现在多个分组中 ，常见的分组模式无法满足这些需求。但是分组、分 类这种管理方式又存在其特有的便利性 ，这时我们引入了标签 ，标签的妙用我曾经在“标签”在对象 展示中的应用中提到过~标签可以看成是一个很轻量级的分组方式 ，同时其带来的可读性并 比分 组来的差 ，扩展性反而更强。 设计 任务部分 综合上述结论 ，我们对任务做了如下的设计 ： 轻量化任务的创建过程 ，给任务赋予更多的属性类型 ，例如需求、缺陷 ，让任务面向的用户群更 加广。 解耦任务与项目的关系 ，任务可以 依赖于任何项目、任何产品而存在。同时 ，任务又可以关联 到多个产品和多个项目。 任务可以拆解成多个子任务 ，为了避免层级关系过于复杂 ，我们只保留但是一层父子关系 ，子任 务默认继承父任务的部分属性。 允许任务添加标签 ，打标签的操作完全放开给用户。 在展示上 ，我们一改长久以来“列表”对于工具类产品的统治 ，采用新的it em方式展示任务列表以及 父子级的展示效果。 色彩上 ，通过颜色来区