协作和信息孤岛在当今大多数组织中都是现实存在的问题。人们倾向于将它们视为创新和组织效率的巨大障碍。它们也是各种软件工具供应商解决方案的热门目标。
然而，工具本身很少（即使有的话）能解决像组织孤岛这样的问题。原因很简单：孤岛是由人组成的，而人际关系动力是孤岛存在的首要驱动因素。
那么答案是什么呢？
成功的社区是打破孤岛的关键。工具在这个过程中扮演着重要的角色，但是如果你不围绕这些工具建立成功的社区，那么你将面临一场艰苦的战斗，成功的机会有限。工具赋能社区；它们不会建立社区。这需要一种深思熟虑的方法——一种首先关注文化，其次关注流程，最后关注工具的方法。
然而，这是一个挑战，因为在大多数情况下，这并不是大多数企业中流程的运作方式。太多的公司在开始解决孤岛问题的旅程时，首先考虑的是工具，并考虑一些无法评估成功正确因素的指标。通常，人们选择工具仅仅是出于成本、合规性或工作量方面的考虑——而不是考虑用户群的需求和愿望。但是，像“客户/用户满意度”这样的主观衡量标准对于这些内部工具来说是一个真正的因素，并且可能会决定工具采用和提高协作的目标是否成功。
至关重要的是要理解，最好的技术工具（或企业可能认为最具成本效益的工具）并不总是推动社区、透明度和协作前进的解决方案。“影子 IT”——用户选择自己的工具解决方案，围绕它们建立社区和临界质量——之所以存在并如此有效是有原因的：选择自己工具的人更有可能保持参与并带动其他人，从而有机地打破孤岛。
这是一个关于 Autodesk 如何最终在企业规模上采用 Slack 来帮助解决我们的透明度和信息孤岛问题的故事。有趣的是，Slack 在 Autodesk 并不是（现在也不是）IT 支持的应用程序。它是一个企业解决方案，由一群热情的志愿者采用、构建并仍在运行，他们致力于“默认开放”的范式。
利用 Slack 使透明度在我们这里成为现实。
聊天灾难
首先，提供一些背景信息：我在 Autodesk 的工作是运营我们的 Open@ADSK 计划。我最初受聘推动我们的开源战略，但我们很快扩大了我的角色，包括推动内部开发（内部开源）的开源最佳实践，以及转变我们作为一个组织在内部进行协作的方式。最后一部分是我们开始讲述公司采用 Slack 故事的地方。
但在我们开始谈论我们使用 Slack 的旅程之前，让我们先解决为什么缺乏透明度和开放性对我们来说是一个挑战。是什么使透明度成为组织中如此令人向往的品质？当我刚到 Autodesk 时，我面临着什么？
每家公司都说他们想要“更好的协作”。就我们而言，我们是一家拥有 35 年历史的软件公司，在向包括建筑、工程、施工、制造和娱乐等多个行业销售桌面“收缩包装”软件方面取得了巨大的成功。但是，没有一家成功的公司会固步自封，Autodesk 领导层认识到，将我们的产品转向基于云的解决方案是公司未来增长的关键，包括通过需要云计算和深度产品集成才能实现的产品组合来开拓新市场。
进行这种转变的挑战远不止技术或架构方面——它根植于公司的 DNA 中，从我们的组织方式到我们集成产品的方式，方方面面都受到了影响。我们桌面产品集成的基本形式是文件导入/导出。虽然这无疑很重要，但它导致了一种高度专业化的团队文化，这些团队在一个比我们期望的更封闭的环境中工作，并且不共享信息（或代码）。在转向基于云的方法之前，这并不是什么大问题——但是，在需要组织行为更像开源项目的环境中，透明度、开放性和协作从“锦上添花”变成了“业务关键”。
与许多我们这样规模的公司一样，Autodesk 多年来也曾使用过许多不同的协作解决方案，其中一些是商业化的，还有许多是自主开发的。然而，它们都没有有效地解决多对多的实时协作挑战。其中一些原因是技术性的，但很多原因是文化性的。
当有人第一次指派我尝试为此寻找解决方案时，我依靠的是我在职业生涯的挑战性经历中形成的一种理念：“文化第一，工具最后。” 这对像我这样的工程人员来说仍然是一个挑战。我们希望立即将工具作为任何问题的解决方案。然而，至关重要的是要评估公司的精神（文化）以及现有流程，以确定哪种工具可能适合。不幸的是，我见过太多领导者从上往下指定工具选择的情况，而这仅仅是基于前面讨论的因素。我需要一种不同的方法，这种方法更多地依赖于将工具融入我们想要形成的文化中，而不是反过来。
我在 Autodesk 发现的是，有几个小团体的人在使用像 HipChat、IRC、Microsoft Lync 等工具来尝试满足他们的需求。然而，我发现最有趣的事情是公司内部有 85 个独立的 Slack 实例！
尤里卡！我偶然发现了一个病毒式成功案例（这得益于 Slack 能够轻松启动“免费”实例的能力）。我也完全陷入了我喜欢称之为“孤岛之地”的地方。
所有这些实例彼此之间都不互通——因此，实际上，我们创建了孤立的信息岛屿，这些岛屿虽然对其中的人有用，但无法改变我们作为企业运营的方式。本质上，我们现有的组织文化在这些独立的 Slack 系统中以数字形式重新创建。我们的组织混合使用了这些小型免费实例以及多个付费实例，这也意味着我们没有利用共同的计费安排。
我的第一个（开源）想法是：“嘿，为什么我们不使用 IRC 或其他一些开源工具来做这件事呢？” 我很快意识到这并不重要，因为使用 Slack 的人不仅仅是我们的开源工程师。来自公司各个领域的人——甚至包括高级领导层——都在大量采用 Slack，并且在某些情况下，说服他们的管理层为它付费！
我的第二个（工程）想法是：“哦，这很简单。我们只需将所有 85 个实例合并到一个统一的 Slack 实例中。” 很快变得明显的是，这只是解决方案的简单部分。更困难的是劝说、说服和将人们转移到一个单一的、透明的实例中。构建“护栏”以使闭源工具能够提供这种透明度是关键。这些护栏以流程、指南和社区规范的形式出现，而这些是转型中最困难的部分。
真正的工作开始了
当我开始慢慢帮助用户迁移到通用实例时（付费也是一个挑战，但那是另一天的话题），我发现了一群专注的超级用户，他们在我们新的 Slack 通用实例上的 #adsk-slack-help 频道中互相帮助。实际上，这些超级用户正在通过他们的努力建立我们透明度和社区的根基。
我内心的开源社区经理很快意识到，这些用户是在 Autodesk 成功扩展 Slack 的途径。我招募了他们中的五位来帮助我，我们一起着手构建工具推广的社区结构。
在这里，我应该注意社区结构/治理模型与传统 IT 策略之间的区别：除了安全和数据隐私/法律策略之外，志愿者管理员和用户社区成员完全定义和管理我们的 Slack 实例。我们在 Slack 上取得成功的关键之一（目前大约有 9,100 名用户和大约 4,300 个公共频道）是我们如何让用户参与构建这些治理结构。诸如频道命名约定和我们不断增长的常见问题列表等都是自然形成的，并且一直保持着相同的风格。我们的社区成员感到他们的声音被听到了（即使有些人不同意），并且他们已经成为我们部署 Slack 成功的参与者。
然而，我们在此过程中确实学到了关于透明度和公司文化的重要一课。
重点不是工具
当我们第一次启动我们的主 Slack 实例时，我们保留了任何人将频道设置为私有的功能。在使用大约三个月后，我们看到了一个明显的趋势：创建私有频道（和消息）的人比创建公共频道的人更多（私有频道与公共频道的比例约为二比一）。由于我们合并 85 个 Slack 实例的目的是为了提高参与度和透明度，我们迅速调整了我们的策略，并为普通用户关闭了此功能。相反，我们实施了一项由管理员团队审查的政策，并为私有频道定义了明确的标准（财务、法律、人事讨论等原因）。
这可能是整个过程中我唯一一次感到后悔的事情。
我们因为这个决定而受到了大量的批评，因为我们正在处理一种习惯于在彼此之间几乎没有互动的独立部门工作的企业文化。我们明确方向的关键时刻（以及事情开始好转的转折点）发生在一个全体员工会议上，当时我们的一位高级主管要求我回答一个关于 Slack 的问题。我站起来回答问题，并说道（根据记忆概括）：“重点不是工具。我可以给你们所有现有的最好的、镀金的协作平台，但如果我们不改变我们的协作方式并学会默认开放，我们就不会成功。”
我没有对这句话想太多——直到那位高级主管开始在他的幻灯片、员工会议以及与他遇到的每个人中使用“默认开放”这个短语。那一刻定义了我们一直在 Slack 上尝试做的事情：工具并不是我们成功的唯一原因；而是我们围绕建立一个自我维持的社区所采取的方法，这个社区不仅想使用这个工具，而且渴望它让他们能够轻松地跨企业工作。
我们学到了什么
我一直说，这本可以用其他类似的工具（Hipchat、IRC 等）来实现，但它在这种情况下特别有效，因为我们选择了一种支持用户社区为满足自身需求而采用的解决方案的方法，而不是严格按照公司如果决策来自组织结构顶层可能会选择的方式。我们投入了大量工作使其成为公司可以接受的解决方案（从安全性、法律、财务等方面来看），但最终，我们的成功来自于我们作为一个社区而不是传统的企业 IT 系统来构建这次推广（并继续运行该工具）。
我从这一切中学到的最重要的一课是，透明度和社区是渐进的，而不是革命性的。你必须了解你的文化现状，你希望它走向何方，并利用社区自身正在采用的杠杆点来取得持续和显着的进步。在无政府状态和一个蓬勃发展的社区之间存在一个微妙的平衡点，我们试图将我们的方法建立在当今蓬勃发展的开源社区的成功实践之上。
社区是人性化的。工具来来去去，但将你的社区放在你推动透明化的最前沿是成功的关键。
本文是开放组织工作手册项目的一部分。
8 条评论