修改时序约束改变slack_改变我们使用Slack的方式解决了我们的透明度和筒仓问题

修改时序约束改变slack

协作和信息孤岛是当今大多数组织中的现实。 人们倾向于将它们视为创新和组织效率的巨大障碍。 对于所有类型的软件工具供应商来说，它们也是解决方案的最爱目标。

但是，工具本身很少（如果有的话），无法解决诸如组织孤岛这样的问题。 原因很简单：筒仓是由人组成的，而人类动力首先是筒仓存在的关键驱动力。

所以，答案是什么？

成功的社区是打破孤岛的关键。 工具在此过程中发挥着重要作用，但是如果您不围绕这些工具建立成功的社区，那么您将面临艰难的战斗，获得成功的机会有限。 工具使社区成为可能； 他们没有建立它们。 这采取了一种深思熟虑的方法-首先关注文化，其次是过程，最后是工具。

成功的社区是打破孤岛的关键。

但是，这是一个挑战，因为在大多数情况下，这不是大多数企业中该过程的工作方式。 太多公司通过首先考虑工具并考虑无法评估成功因素的度量标准来开始修复孤岛。 人们常常出于纯粹基于成本，基于合规性或基于工作量的原因而选择工具，而不是考虑用户群的需求和期望。 但是，诸如“客户/用户喜好”之类的主观衡量指标是这些内部工具的真实因素，并且可以成功或失败地采用工具以及增强协作目标。

了解最佳技术工具（或企业可能认为最具成本效益的方法）并不总是推动社区，透明度和协作向前发展的解决方案，这一点至关重要。 有一个原因是“影子IT”（用户选择自己的工具解决方案，在他们周围建立社区和关键群体）如此存在且如此有效：选择自己的工具的人更有可能保持参与并与他人一起使用，从而破坏有机地降低筒仓。

这是一个有关Autodesk最终如何在企业范围内采用Slack来帮助解决我们的透明度和筒仓问题的故事。 有趣的是，Slack不是（也不是）Autodesk的IT支持的应用程序。 这是一种企业解决方案，由一群热心的志愿者采用，构建和运行，他们致力于“默认情况下开放”范式。

利用Slack使我们实现透明。

闲聊

首先，有一些看法：我在Autodesk的工作是执行Open @ ADSK计划。 我最初是被聘用来推动我们的开源战略，但后来我们Swift扩大了作用，包括为内部开发（内部源代码）推动开源最佳实践，并转变了我们作为组织进行内部协作的方式。 这是我们在公司中采用Slack的故事的最后一部分。

但是，在我们甚至开始谈论使用Slack的旅程之前，让我们先谈谈为什么缺乏透明度和开放性对我们构成挑战。 是什么使透明度成为组织中理想的质量，当我在Autodesk工作时遇到了什么？

每个公司都表示他们希望“更好的协作”。 在我们的案例中，我们是一家拥有35年历史的软件公司，在将台式机“收缩包装”软件销售给多个行业（包括建筑，工程，建筑，制造和娱乐）方面，已经取得了巨大的成功。 但是，没有一家成功的公司为荣，Autodesk领导层认识到，为我们的产品转向基于云的解决方案是公司未来发展的关键，包括通过需要云计算和深度产品集成的产品组合来开拓新市场。

采取这一举措的挑战不仅限于技术或体系结构，它还植根于公司的DNA中，从我们的组织方式到产品集成方式，无所不包。 我们的桌面产品中集成的基本格式是文件导入/导出。 尽管这无疑是重要的，但它导致了一支高度专业化的团队的文化，这种团队在比我们想要的更孤立，并且不共享信息（或代码）的环境中工作。 在转向基于云的方法之前，这并不是什么大问题，但是在要求组织行为像开源项目那样的环境中，透明度，开放性和协作源于“好拥有”到“关键业务”。

像我们这么多规模的公司一样，多年来，Autodesk拥有许多不同的协作解决方案，其中有些是商业的，而很多是他们自己开发的。 但是，它们都无法有效解决多对多实时协作难题。 某些原因是出于技术原因，但其中许多是出于文化原因。

我依靠自己在职业生涯中富有挑战性的经验所形成的理念：“文化至上，工具至上”。

当某人最初要求我设法找到解决方案的任务时，我依靠的是我在职业生涯中富有挑战性的经验所形成的哲学：“文化至上，工具至上”。 对于像我这样的工程人员来说，这仍然是一个挑战。 我们希望立即跳入工具作为解决任何问题的方法。 但是，至关重要的是评估公司的风气（文化）以及现有流程，以确定哪种工具合适。 不幸的是，我已经看到很多情况下，领导者根据前面讨论的因素从上面决定了工具的选择。 我需要一种不同的方法，该方法更多地依赖于将工具适合于我们想要成为的文化，而不是相反。

我在Autodesk上发现的是几个小团体，他们使用HipChat，IRC，Microsoft Lync等工具来满足他们的需求。 但是，我发现最有趣的是公司中有85个单独的Slack实例 ！

尤里卡！ 我偶然发现了一个病毒式的成功（Slack能够轻松启动“免费”实例的能力使它获得了成功）。 我也正直落在我喜欢的“孤岛”上。

所有这些实例都没有互相交谈，因此，有效地，我们创建了孤立的信息孤岛，这些信息孤岛虽然对其中的那些有用，但却无法改变我们作为企业运作的方式。 本质上，我们在这些单独的Slack系统中以数字格式重新创建了我们现有的组织文化。 我们的组织容纳了这些小型免费实例以及多个付费实例的混合，这也意味着我们没有利用通用的计费安排。

我的第一个（开源）想法是：“嘿，为什么不为此使用IRC或其他开源工具？” 我很快意识到这并不重要，因为我们的开源工程师并不是唯一使用Slack的人。 公司各个领域的人，甚至是高级领导，都纷纷采用Slack，在某些情况下，说服其管理层为此付出代价！

我的第二个想法（工程）是：“哦，这很简单。我们只是将所有85个实例折叠成一个内聚的Slack实例。” 很快变得显而易见的是，这是解决方案的简单部分。 劝说，说服并把人们转移到一个透明的实例上的工作要困难得多。 建立“防护栏”以使封闭源工具能够提供这种透明度是关键。 这些防护栏以流程，指南和社区规范的形式出现，这是此转变中最困难的部分。

真正的工作开始了

当我开始慢慢地帮助用户迁移到普通实例时（为此付费也是一个挑战，但又是一个话题），我发现了一群专门的高级用户，他们在＃adsk-slack-help中互相帮助新的Slack常见实例上的频道。 实际上，这些超级用户通过他们的努力为我们的透明度和社区奠定了基础。

我内部的开源社区经理Swift意识到，这些用户是在Autodesk成功扩展Slack的途径。 我征集了五个人来帮助我，并且我们一起开始为工具的推出构建社区结构。

但是，我们在此过程中确实学习了有关透明度和公司文化的重要课程。

在这里，我应该指出社区结构/治理模型与传统IT策略之间的区别：除了安全性和数据隐私/法律策略外，志愿者管理员和用户社区成员完全定义并管理我们的Slack实例。 Slack（目前拥有大约9,100个用户和大约4,300个公共频道）成功的关键之一就是我们如何让用户参与并使他们参与构建这些治理结构。 诸如频道命名约定和我们不断增加的常见问题列表之类的事情都是有机的，并且以同样的方式继续存在。 我们的社区成员感到自己的声音被听到（即使有些人不同意），并且他们已经成为我们Slack部署成功的一部分。

但是，我们在此过程中确实学习了有关透明度和公司文化的重要课程。

不是工具

当我们首次启动主要的Slack实例时，我们让任何人都可以将频道设为私有。 经过大约三个月的使用，我们看到了一个明显的趋势：创建私人频道 （和消息）的人数超过了公共频道 （私人与公共比率约为2：1）。 由于我们合并85个Slack实例的工作旨在提高参与度和透明度，因此我们Swift调整了政策并为普通用户关闭了此功能。 相反，我们实施了由管理团队审核的政策，并为私人渠道定义了明确的标准（财务，法律，人员讨论等原因）。

这可能是整个过程中唯一让我后悔的事情。

我们为此做出了惊人的断言，因为我们正在处理一种企业文化，该文化习惯于在彼此之间具有最小交互的独立部门中工作。 我们明确的明确时刻（以及事情开始变得更好的转折点）发生在全体会议上，当时我们的一位高管要求我解决有关Slack的问题。 我站起来回答这个问题，然后说（从记忆中解脱出来）：“这与工具无关。我可以为您提供最好的，镀金的协作平台，但是如果我们能成功，我们将不会成功。不要改变我们的协作方式，并学会默认打开 。”

我对那句话没有更多的想法，直到高级主管开始在他的幻灯片，员工会议以及与他遇到的每个人中使用“默认打开”一词。 那一刻已经定义了我们一直在尝试使用Slack进行的工作：该工具并不是我们成功的唯一原因； 这是我们围绕建立一个自我维持的社区而采取的方法，该社区不仅要使用此工具，而且渴望获得赋予他们在整个企业中轻松工作的能力。

我们学到了什么

该工具并不是我们成功的唯一原因。 这是我们围绕建立一个自我维持的社区而采取的方法，该社区不仅要使用此工具，而且渴望获得赋予他们在整个企业中轻松工作的能力。

我一直说，使用其他类似工具（Hipchat，IRC等）可能会发生这种情况，但是在这种情况下它确实有效，因为我们选择了一种支持用户社区为他们的需求所采用的解决方案的方法，而不是严格地如果决策来自组织结构图的顶部，公司可能会选择什么。 我们做了很多工作，使其成为公司可以接受的解决方案（从安全性，法律，财务等方面），但最终，我们的成功源于我们建立了这一部署（并继续运行该工具）作为社区，而不是传统的公司IT系统。

我从所有这些中学到的最重要的教训是透明度和社区是进化的，而不是革命的。 您必须了解您的文化所在，您想去的地方，并利用社区所采用的杠杆点来取得持续而重大的进步。 在无政府状态和繁荣的社区之间有一个很好的平衡点，我们已经尝试根据当今繁荣的开源社区的成功实践来建立我们的方法。

社区是个人的。 工具来来去去，但是让您的社区始终处于推动透明度的最前沿是成功的关键。

本文是“ 开放组织工作簿”项目的一部分 。

翻译自: https://opensource.com/open-organization/17/12/chat-platform-default-to-open

修改时序约束改变slack