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

对任务、项目管理设计的理解 背景 项目管理，任务管理是一个已经被各个产品玩烂了的概念，但是玩烂了并不意味着玩好了 ~ 即便是 目前的网络上充斥着各式各样的这类工具，每个工具都有着自己的侧重点，但是如果想要拿来去套 上我司的场景来用，似乎都显的很乏力 ~ 为啥 ~用户场景太多太复杂 ~ 简单的玩不转，复杂的又难用 ~ 那要怎么搞？！ 在做这部分之前，我们多次走访了核心用户，听他们对产品的设想，对产品的需求，设计方案更是 一改再改，但是似乎总有一些场景让我们的设计无法应对，总有一些场景我们无法去满足 ~很头疼 ~ 现在回想过来，我们当时陷入了一个为了解决单个问题而设计的误区，针对用户的问题一个一个去 解决，是不会形成一套完整有效的方案的。 没有全局的视角 ~ 永远不能解决核心的问题。 灵感 Phabricator 当Phabricator 引入到公司后，这种新式的玩法刺激了很多人的神经，大家开始研究它与其他工具的 不同，能够让 facebook 用来作任务管理的软件，绝对不会只是因为它能够跟 git 、代码关联这么简单 ~ 个人认为 Phabricator 之所以能够玩转，是因为它将任务与项目进行了解耦，很多工具对于任务的 认知，认为任务必须依托于项目而存在，总要有一个 space 去承载它，殊不知，这本身就是一个很 强烈的绑定。在 phabricator 中，任务不在需要这种强烈的绑定，任务与项目变成了同级关系，中间 只是一个简单的类似于 tag 的简单关联，并且随时可以解开。这样任务就变成了一个单体，用户不需 要奔走于各个项目之间来看自己的任务，只需要在任务页面，就可以掌握这些任务的归属。 Phabricator 中的任务 Redmine 我们团队一直在用 Redmine ，虽然在用户体验方面，很多同学都有吐槽，但是 redmine 在任务管理上 的设计，充分说明了它对任务这个名词的理解。用过 Redmine 的同学都知道， Redmine 里面最常见 的两个对象：项目和 issue 。所有的一切都是 issue ，无论你是需求、是任务、是 bug~Redmine 只认 为这是 issue 的一个属性，仅此而已，可以去更改，可以去变化，但是内容还是那个样子。 Redmine 提供的另外一个很有效的设计，就是父子产品和父子任务的概念，市面上很多项目管理的 工具都将没有对这部分概念做过多的介入，因为一旦有了父子级，产品界面的展示、父子之间的 继承、产品中的各类配置都将明显的提升产品的复杂度，尤其是大部分产品中，任务与项目都是有 着强烈的绑定关系，这样会更加限制任务的创建，用户查看任务的视角将会变的更加跳跃。 发现 结合这两个产品对于项目、任务管理的理解，以及分析了诸如 Teambition 、Worktile 、trello~ 等任务 、项目的管理工具，结合我司特有的用户场景，我们发现： 设计 任务部分 综合上述结论，我们对任务做了如下的设计： 任务列表 - 交互稿 项目部分 对于项目而言，除了在展示上面继承了任务的设计之外，我们还对项目进行了如下的设计： 项目 list- 交互稿 看板 -交互稿 其他 当然，上述的设计点大部分面向普通用户，对于一些高级功能的设计，比如自定义字段的定义和 使用，比如高级查询以及搜索条件的保存，比如看板的隐藏与显示等等，我们将这些高级功能进行 了必要的隐藏，对于高级用户而言，这些功能将会提供定制化的便利性，从而实现他们对于产品的 要求。 产品总结 所以，将对项目、任务的设计进行总结，项目管理应该具有的特点： 通过这些特点，赋予用户更多的可玩性，让任务管理与后续的开发流程不在强制绑定，让各类用户 更加专注自己的工作。 个人感触 灵活，是让用户能够通过我们提供的功能，形成自己