我所认识的Worktile---Worktile图解

一个小团队能否把一件事做得又好又快，无外乎就是两个因素决定：团队的人和事，而团队的人看的是执行力，团队的事看的是信息流通效率。同时这两者又是紧密联系着的，因为一个团队的信息流通效率会大大影响一个团队的执行力，反过来也一样。

本文将重点从信息流通方面来八一八我所认识的Worktile。

关于Worktile平台与平台之间的对比

传统的团队管理模式下团队内部信息和外部信息交错臃肿，干扰因素较多；而团队成员之间的信息交流呈现步骤繁冗，执行流程不明确，工具使用多样化的现象，大大降低了团队的信息流通效率和团队执行力。

Worktile将团队产生的信息有效整合成一个巨大的协同信息池，使团队信息从产生到流通都形成一个闭环，不依赖于其他第三方平台，为团队信息流通的安全性，一致性，高效性提供了最好的体验和保障。在整个项目执行的过程中，参与进来的项目成员彼此平等透明，始终面对Worktile的协同信息池，就像同时与各个成员面对面一样，可以实时，一目了然地了解到各成员和项目的信息动态。

与Trello的对比，anytao在协同之道：worktile为什么不同？---trello篇阐明得很清晰，Worktile的使用场景和面向的用户是不同的，面向中小团队的Worktile更2B；面向个人的Trello更2C，所以，在Trello形成的信息池中，基本不会与其他的用户形成信息流通，整合与共享。

与Slack的对比，Slack擅长于将存在于茫茫信息海洋的有效信息流提取出来，供团队使用。整合了其他第三方平台的有效信息和团队成员在Slack上产生的信息，形成的Slack信息池更大的依赖于第三方的信息流整合，而Worktile的“一站式”信息池从产品定位上就与Slack有着这本质的区别。

关于Worktile的团队，项目

一个团队可以有多个不同的项目，而项目成员必须来自团队。

Worktile弱化了个人与个人之间的维度关系而强调团队与团队之间的维度关系，两个不同的团队之间是几乎不会有信息流通的。

现实中，成员跨团队的情况还是存在的

对于成员跨团队的情况，Worktile可能更倾向于将两个团队看成一个团队，而跨团队看成跨项目，个人认为这种逻辑还是可取的，因为在新建项目时的三个项目选项(私有项目，团队可见，公开项目)就能很好解决跨项目的问题；这样既减少成员的邀请，又解决了成员跨团队的问题。

关于Worktile的人，角色，权限

Worktile的人大概分为四种角色：团队管理员（团队创建者），项目负责人，团队成员，项目成员

团队管理员的权限操作：邀请成员，创建项目，移交权限，解散团队（慎重）。

团队成员的操作权限：只能作为项目成员参与该团队的项目中，对该团队的团队设置，移交权限，解散团队，邀请成员等没有操作权限。

项目负责人的权限操作：项目成员管理，项目设置，删除项目，清空项目回收站。

项目成员的权限操作：创建任务，新建文档，上传文件，参与讨论，浏览简报，新建日程等通用性操作。

关于Worktile的特色---关注机制

无处不在，无所不能，简直BUG级别的关注机制，让你轻松在文件，文档，话题，任务，日程这几大团队要素中实时跟进项目进度。

个人认为，Worktile之所以能够提供如此高效的协同工作，离不开关注机制的引入，在整个Worktile的信息池中，关注机制更是起到了三个重要的核心作用。

信息精准分类：信息的产生来自哪里，是来自任务，文档，话题还是日程？通过关注可以很清晰地分辨出各信息的有关来源。

减少信息冗余：在合适的的任务，文档，话题，文件，日程下添加需要关注的项目成员，而没有添加关注的项目成员不会收到信息干扰。

信息高效流通: 通过关注可以实现实时更新动态，实时推送动态，让项目动态无所遁形。

写在最后

在这个唯快不破的互联网时代，一个小团队如何能做到同时兼顾团队执行力和信息流通效率，从而提高团队的战斗力去抗衡各种高大上的团队就是每一个团队面临的客观问题。那么，你该试试协同，你该试试Worktile。

PS：本文只代表个人观点，不代表Worktile官方利益。
原文来自http://www.jellybool.com/post/To-Understand-Worktile