背景

项目管理，任务管理是一个已经被各个产品玩烂了的概念，但是玩烂了并不意味着玩好了~即便是目前的网络上充斥着各式各样的这类工具，每个工具都有着自己的侧重点，但是如果想要拿来去套上我司的场景来用，似乎都显的很乏力~为啥~用户场景太多太复杂~简单的玩不转，复杂的又难用~

那要怎么搞？！

在做这部分之前，我们多次走访了核心用户，听他们对产品的设想，对产品的需求，设计方案更是一改再改，但是似乎总有一些场景让我们的设计无法应对，总有一些场景我们无法去满足~很头疼~

现在回想过来，我们当时陷入了一个为了解决单个问题而设计的误区，针对用户的问题一个一个去解决，是不会形成一套完整有效的方案的。

没有全局的视角~永远不能解决核心的问题。

灵感

 Phabricator

当Phabricator引入到公司后，这种新式的玩法刺激了很多人的神经，大家开始研究它与其他工具的不同，能够让facebook用来作任务管理的软件，绝对不会只是因为它能够跟git、代码关联这么简单~

个人认为Phabricator之所以能够玩转，是因为它将任务与项目进行了解耦，很多工具对于任务的认知，认为任务必须依托于项目而存在，总要有一个space去承载它，殊不知，这本身就是一个很强烈的绑定。在phabricator中，任务不在需要这种强烈的绑定，任务与项目变成了同级关系，中间只是一个简单的类似于tag的简单关联，并且随时可以解开。这样任务就变成了一个单体，用户不需要奔走于各个项目之间来看自己的任务，只需要在任务页面，就可以掌握这些任务的归属。

Phabricator中的任务

 Redmine

我们团队一直在用Redmine，虽然在用户体验方面，很多同学都有吐槽，但是redmine在任务管理上的设计，充分说明了它对任务这个名词的理解。用过Redmine的同学都知道，Redmine里面最常见的两个对象：项目和issue。所有的一切都是issue，无论你是需求、是任务、是bug~Redmine只认为这是issue的一个属性，仅此而已，可以去更改，可以去变化，但是内容还是那个样子。

Redmine提供的另外一个很有效的设计，就是父子产品和父子任务的概念，市面上很多项目管理的工具都将没有对这部分概念做过多的介入，因为一旦有了父子级，产品界面的展示、父子之间的继承、产品中的各类配置都将明显的提升产品的复杂度，尤其是大部分产品中，任务与项目都是有着强烈的绑定关系，这样会更加限制任务的创建，用户查看任务的视角将会变的更加跳跃。

发现

结合这两个产品对于项目、任务管理的理解，以及分析了诸如Teambition、Worktile、trello~等任务、项目的管理工具，结合我司特有的用户场景，我们发现：

设计

 任务部分

综合上述结论，我们对任务做了如下的设计：

任务列表-交互稿

 项目部分

对于项目而言，除了在展示上面继承了任务的设计之外，我们还对项目进行了如下的设计：

项目list-交互稿

看板-交互稿

 其他

当然，上述的设计点大部分面向普通用户，对于一些高级功能的设计，比如自定义字段的定义和使用，比如高级查询以及搜索条件的保存，比如看板的隐藏与显示等等，我们将这些高级功能进行了必要的隐藏，对于高级用户而言，这些功能将会提供定制化的便利性，从而实现他们对于产品的要求。

产品总结

所以，将对项目、任务的设计进行总结，项目管理应该具有的特点：

通过这些特点，赋予用户更多的可玩性，让任务管理与后续的开发流程不在强制绑定，让各类用户更加专注自己的工作。

个人感触

灵活，是让用户能够通过我们提供的功能，形成自己的使用习惯，就像是乐高积木一样，我们提供多种素材，怎么玩，看用户自己，我们需要保证的，就是用户在玩的过程中，不会因为产品的限制而玩不下去，不会因为产品的用户体验而放弃这个玩具。

不失准则，是在满足大部分用户的场景下，减少定制功能的产出，功能只要产出，就需要在产品中占据一定的位置，而这些定制功能，并不能够给大部分用户带来便利，相反，如果放在界面中，甚至会引起迷惑的效果，这就需要我们去坚守自己的设计准则，在两者不可兼顾的情况下，遵循二八原则，产品，并不是为了所有人设计的。

灵活而不失准则，与诸位奋斗在需求海洋中的设计师共勉~