我作为 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 条评论