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