正文
这种沟通方式对于像我们这样以远程办公为主的公司来说是特别有问题的，因为团队成员分布在许多不同的时区。当你所在的时区处于深夜时，但是此时别的时区已经就某个话题已经讨论完了，你如果也想参与，那应该怎么办呢？
正如Samuel Hulick在他著名的与app的“分手”信中所写的那样：
我发现，“总是在”这种倾向是一个自我延续的反馈循环:越多的人参与，就会有更多的对话。对话越多，参与的人就越多。泡沫,冲洗,重复。
研究发现，Slack用户平均花在应用上的时间为每天10个小时！当然，这并不是说人们没有很多任务需要处理，但研究表明，不断的上下文切换——比如当你停下你正在做的事情来查看团队其他成员的通知时——会扼杀工作效率，导致你有“更多的压力、更大的挫败感、时间压力和努力”。
对团队来说，这并不健康，因为它不能真正帮助我们专注于推动项目前进的艰苦工作中去。
简短对话成就了Slack
Slack对快速检索很有用，但是当遇到需要进行大局讨论时，它就有很多问题了。群组聊天界面是为了快速的发送消息而设计的，想从始至终维持完整的对话几乎不可能。
我们也有过类似的经历，如Dave Teare，AgileBits的创始人：
在您完全理解正在讨论的问题之前(更别说找到解决方案了)，总是有人会开始新的对话，或者重新开始之前已经讨论过的话题。
即使对话还是围绕在主题上面，但是所有的事情仍然需要立即回应。使用Slack的话，如果想回退，或者想思考一下正在讨论什么，以及后续应该做什么，完全没有时间去做这些动作。我们仍然需要一些独立的工具，比如电子邮件和Wedoist，在我们的工作中当需要有更深入的交流时，我们还是需要使用。这意味着我们的对话被分解成很多难以整理的部分。
这样的交流只能探讨一些表面的东西，而且容易脱离主题。 这就让我们引出了下一个观点。
容易跑题
如果在一个Slack频道里发生了多个同步的对话，那么就会发生丢失的情况，找不到任何的交流的踪迹。我们提出了一些想法，并且进行了讨论，然后我们就陷入了困惑。我们不可能再回头看已经做出的决定，也不可能为了让其他人在以后能够找到它去保存信息。
有一个支持我们观点的团队将在支持频道中报告一个bug的经验比作试图跳上移动的火车。一旦他成功地吸引了开发人员的注意力，就没有简单的方法来跟踪这个问题的状态。
由于想重新回过头去查找某一个话题是否被讨论过并不是一件轻松的事情，因此可能就会导致相同的问题会被不同的人多次提出来。对于这个问题，我们也只能想办法让自己逐渐去适应这种情况，而不是说通过建立一个知识库，以方便人民去检索相关信息这种方式去解决。
