我作为 Microsoft 云和企业部门的一员，管理着一个技术内容团队。大约在十四个月前，该团队在沟通和协作方面遇到了一些严重的问题。
缺乏开放性是这些问题的根源。
这是一个关于我的团队如何重新发现其目标，通过协作找到新的成功，并以新的和富有成效的方式与外部贡献者和客户互动的故事——这一切都要归功于一种开放的方法。
协作难题
在 Microsoft，技术内容团队作为更大的工程团队的一部分工作，负责记录可供下载的产品。与其他软件公司和组织一样，我们销售旨在交付特定业务价值的产品。然后，技术内容团队必须清楚地解释如何使用软件来有效地完成我们告诉客户可能实现的事情。
我们主要通过书面文档来做到这一点。随着时间的推移，对技术内容的少量更新是不够的。因此，作为技术传播者，我们必须不断评估客户需要做什么，将这些信息与我们知道产品可以做什么进行比较，并解释如何使用产品，以便客户能够成功，并希望在未来继续使用该产品。这种工作可能需要频繁地进行重大的文档修改。
我的团队知道这一点。但通常我观察到一些团队成员仅仅是在修补非常小的更新——更改一两个词，并简单地从技术专家那里复制和粘贴更新。这项工作反映出缺乏构建关于客户应该如何使用我们正在记录的产品的观点的意愿。
最重要的是，每个人都在独立运作，就像在一个工作孤岛中，他们非常有意识地保护着自己的工作。团队最近已将内容从封闭系统转移到 GitHub——但仍然只是口头上说说作者会接受来自任何地方的任何人的贡献。实际上，团队成员对他们“创作”的内容拥有极大的所有权。
我知道我们的团队文化和行为必须改变。我们需要接受任何愿意花时间贡献的人的贡献。我们需要考虑一个评估贡献的工作流程，并创建一个鼓励贡献的社区。我们还需要开始在内部进行更协作的工作。
为了有效地完成任何这些工作，我知道我需要帮助团队重新发现其目标。
在开放性中找到目标
我们的共同目标变成了展示对开放性的承诺。在我们的案例中，“开放性”意味着我们通过易于学习的 markdown 文件格式接受贡献，为来自内部和外部贡献者的贡献进行宣传，并允许我们的内部评论对外可见。这也意味着人们必须对来自他人的反馈持开放态度。
从 XML 过渡到 markdown 意味着团队中每个人的工作流程都发生了变化。我们用 GitHub 替换了我们专有的文件管理系统，因此检查内部和外部的拉取请求成为现在每个人都要承担的新任务。成为 git 专家需要时间；当一切都感觉如此新鲜时，团队都在努力适应。
当人们因内容发布工作流程的改变而感到压力时，与利益相关者的协作也变得紧张。由于人们现在做工作的时间减少了，他们对内容质量的投入也减少了。“社区不是可以帮助贡献吗？”当一些人谈到质量问题时，他们会这样问。但管理层的变动和其他因素导致这些声音变得微弱和沉默。
但是，从 XML 迁移到 markdown，以及从专有文件管理系统迁移到 GitHub 所需的工作流程变更，比使团队更开放地接受关于我们正在发布的内容的反馈所需的文化变更容易得多。
诚实地审视
长期以来，技术内容团队没有诚实地审视哪些方面做得好，哪些方面需要改进。普遍的看法是，批评意味着不友善。但一些长期团队成员设法以一种建设性的方式提供反馈，从而打开了通往更开放的团队文化的大门。
看到机会后，我也开始提供更多反馈：我开始使用不同的词语来描述我们的工作。内容开发者不再是作者；他们是维护者。职责扩大到包括审查贡献，而贡献则通过 GitHub 提交。随着时间的推移，git 的经验预计会增长。我们都嘲笑我们在 git 地狱中的经历。
作为一名经理，我没有发送包含请求更改的电子邮件。我发布了评论并推送了提交。我标记了其他人来查看贡献。我与承担风险的人分享积极的反馈，无论结果如何。我更改了团队成员的任务，直到我看到该人的工作与其成长潜力相符。我尽可能多地参与社区，以鼓励贡献。
发生的事情导致了一次组织变革，这种变革仍在继续令人惊讶和指导。
一种新的重构方法
在短短十个月的时间里，最初由 10 人组成的团队离开了 5 人。在西雅图的科技公司，员工离职率并不罕见。也就是说，当一半的团队离开时，作为一名经理和领导者，您有机会以一种对客户和留在团队中的员工产生影响的方式重塑组织。您还要考虑谁留在团队中，以及如何留住您想要保留的人才。我知道我们可以通过加倍努力来实现我们对开放性的承诺。
找到员工加入团队需要时间。在每次离职后留下的较小团队团结起来，为我们的客户做我们需要做的事情。是的，当我们努力弥合差距，同时学习如何展示对外开放的承诺时，我们犯了一些错误。但为了使贡献和协作更容易，我们改变了存储在 GitHub 中的文档集的结构。这些更改花费了数月时间才得以实施，因为我们是在进行持续更新和内容重构的同时进行更改的。
当团队决定重构内容时——也就是说，修改和重写内容以提高清晰度，而不会对技术准确性产生负面影响——它不能保证重构会像团队预测的那样成功。例如，多年前，我曾在一个团队工作，该团队根据重要的客户研究花费了 18 个月的时间重构内容。当更改上线时，尽管进行了仔细的研究和计划，但客户仍然不满意，我的团队不得不撤销更改，因为有明确迹象表明这些更改导致了对产品的长期持续不满。
因此，当我的当前团队重构内容时，我们没有在幕后进行大的、大胆的更改，而是在我们准备交付较小批量的新内容时，推送较小的、迭代的更改。如果您查看我们每天进行的更新，您只会看到似乎很小且微不足道的更改。但在六个月的时间里，这些“小”更改的总和加起来就是大量的质量改进。采用这种迭代的、每日方法的一个潜在缺点是，您可能会在过程的后期了解到一些东西，迫使您重新思考早期的更改。然而，这种“我们为什么不等待？”的时刻并没有发生。通过以小批量更新的方式进行更新，我们发现当事情没有按计划进行时，更容易恢复。
例如，在我们的第一次更新中，当我们推送更改上线时，我们的所有内容都离线了。我们的服务级别协议 (SLA) 规定，除非我们预先宣布维护窗口，否则我们将 100% 在线。离线是一件大事。我们很快意识到配置设置是中断的根本原因。四十五分钟后，我们重新上线。即便如此，在 45 分钟内，我们的内容都处于离线状态——客户注意到了。我的团队没有找借口，而是承认，在改进的过程中，我们遇到了一个意想不到的问题，并努力尽快解决它。团队幸存了下来。
大约一个月后，当一位长期合作的、值得信赖的贡献者推荐一项更改时，我在没有完成关于验证的尽职调查的情况下合并了提交。一天之内，我意识到这位通常值得信赖的贡献者提交了错误的信息，我推送了一个更正。读者注意到了这些更改，并认为我们没有充分解释这些更改。很快就出现了关于此问题的 Reddit 帖子，并且在 48 小时左右的时间里进行了许多有趣的内部和外部讨论。我没事。
这些类型的情况继续教会我们关于更新技术内容的事情。
坚持（开放）路线
然而，更有趣的讨论之一与内容完全无关，而是与客户可以在 GitHub 上阅读的更新有关。具体来说，来自内部贡献者的提交消息开始显示在 Bing 搜索结果中。团队感觉他们的私人消息正在变得公开。我们讨论了是否应该找到一种方法来阻止某些信息被外部共享。
在讨论结束时，我们选择保持开放。
这些现在公开的片段说明了我们作为一个团队所经历的事情。当我管理团队时，我犯了更多的错误。但通过这一切，我吸取了以下教训
- 我仍然致力于为不习惯任何可能被视为负面事物的人提供建设性的反馈。有些人反应积极，并感谢我的意见。另一些人则认为我离题了。有些人很安静，但我可以看到他们的行动发生了变化，这让我明白他们听到了我的话。
- 我要求反馈——并在收到反馈时倾听。有人告诉我，我太关心人了，保持一点距离可能有助于我拥有更规律的工作时间。在白天，我倾向于将大部分时间花在与人交谈上。我发现在电子邮件和在线聊天中，人们可能会沟通不畅。与人交谈，面对面或使用音频或视频会议，可以减少沟通不畅，并提高生产力和员工敬业度。我的团队成员长期以来一直依赖电子邮件，以至于我会花时间定期与人交谈的想法是出乎意料的。我担心我花费了太多时间在“生产性工作”之外，所以我最初犹豫是否要与人面对面交谈。但后来我想起，我合作过的最好的团队花费了更多时间进行口头和面对面的沟通——而不仅仅是在线沟通。
- 在管理风格和方法方面，我学会了成为一名合作伙伴和促进者。当团队承受很大压力时，（作为经理）有一种进行微观管理的倾向。我不喜欢被微观管理，所以我抵制采用这种管理风格的冲动。与我一起留下的团队成员——以及在其他人离开后加入的团队成员——开始成为一个彼此信任的团队。
对开放的承诺意味着我们（内部和外部）倾听他人的意见，但这并不是我们有责任让每个人都对最终结果感到满意。我记得，一个开放的组织不是一个过度依赖共识的组织。开放组织的重点是协作。
经过 14 个多月的时间，团队正在发生变化。是的，最初团队的一半已经离开。但新的团队成员并不是唯一的变化。留在团队中的原始成员现在更愿意自由表达自己，并嘲笑错误。我可以提出在这次经历的开始时会导致沉默的问题。今天，这些问题更经常引发热烈的讨论。人们愿意承担风险，因为他们相信我们在犯错时会学习。我们以小组形式解决问题，并分享我们认为客户需要什么。当人们倾向于分享他们的工作并且不害怕被拆散时，孤岛现象减少了。我们互相鼓励，并向关心我们发布的内容的贡献者社区敞开自己。
本文是开放组织工作手册项目的一部分。
8 条评论