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