微软兼容性客户体验改善程序
我管理着一个技术内容团队，是Microsoft的Cloud and Enterprise小组的一部分。 大约十四个月前，团队遇到了一些严重的沟通和协作问题。
缺乏开放性是他们的根源。
这就是我的团队如何重新发现其目标，如何通过协作获得新的成功以及如何以新颖高效的方式与外部贡献者和客户互动的故事，这一切都要归功于开放的方法。
合作难题
在Microsoft，技术内容团队作为大型工程团队的一部分，以文档记录可供下载的产品。 与其他软件公司和组织一样，我们也销售旨在实现一定商业价值的产品。 因此，技术内容团队必须清楚地说明如何使用软件有效地完成我们告诉客户的可能。
我们主要通过书面文档来完成此操作。 随着时间的流逝，对该技术内容的微小更新是不够的。 因此，作为技术交流者，我们必须不断评估客户需要做的事情，将这些信息与我们知道产品可以做的事情进行比较，并说明如何使用产品，这样客户才能成功并希望返回到未来的产品。 。 此类工作可能需要经常对主要文档进行大修。
我的团队知道这一点。 但是我经常看到一些团队成员只是在修改一些很小的更新—更改一个或两个单词，然后简单地复制和粘贴技术专家的更新。 这项工作反映出缺乏就客户应如何处理我们正在记录的产品形成观点的意愿。
最重要的是，每个人都在他们非常有意识地保护的工作孤岛内以独立承包商的身份工作。 该团队最近将内容从一个封闭的系统移到了GitHub上，但仍然只是口口相传，认为作家可以接受任何地方任何人的贡献。 实际上，团队成员对他们“创作”的内容拥有极大的所有权。
我知道我们的团队文化和行为必须改变。 我们需要接受愿意花时间做出贡献的任何人的贡献。 我们需要考虑一个评估贡献的工作流程，并创建一个鼓励贡献的社区。 我们还必须开始在内部进行更多的协作。
为了有效地完成这些工作，我知道我需要帮助团队重新发现其目的。
公开寻找目标
我们的共同目标表明了对开放的承诺。 在我们的案例中，“开放”意味着我们通过易于学习的降价文件格式接受了贡献，对内部和外部贡献者的贡献进行了宣讲，并允许外部观众看到我们的内部评论。 这也意味着人们必须对他人的反馈持开放态度。
从XML过渡到降价意味着团队中每个人的工作流程都发生了变化。 我们将自己的专有文件管理系统替换为GitHub，因此检查内部和外部请求请求已成为每个人现在都要做的一项新任务。 成为git的专家需要时间。 当一切都变得如此新奇时，团队会竭力调整。
随着内容发布工作流变化给人们带来压力，与利益相关者的合作也变得紧张。 由于现在人们的工作时间减少了，因此他们没有在内容质量上投入太多。 “社区不可以提供帮助吗？” 一些人问起何时谈论质量问题。 但是管理层的变动和其他因素导致这些声音变得无声无息。
但是，从XML到markdown以及从专有文件管理系统到GitHub所需的工作流更改比使团队更开放地反馈有关我们发布的内容所需的文化更改更容易管理。
诚实地看
很长时间以来，技术内容团队并未诚实地了解哪些方面运作良好，哪些方面需要改进。 普遍的信念是，批判意味着不友善。 但是，一些长期的团队成员设法提供了建设性的反馈，从而为更开放的团队文化打开了大门。
看到机会，我也开始提供更多反馈：我开始使用不同的词语来描述我们的工作。 内容开发者不再是作者 ; 他们是维护者 。 职责扩展到包括审核文稿，并且文稿来自GitHub。 随着时间的流逝，使用git的经验有望增长。 我们都为自己在git hell中的经历而笑。
作为经理，我没有发送要求更改的电子邮件。 我发布了评论并推送了提交。 我标记了其他人以查看贡献。 无论结果如何，我都与冒险的人分享了积极的反馈意见。 我更改了队友的任务，直到看到该人的工作与他们的成长潜力保持一致。 我尽可能在社区中工作以鼓励贡献。
发生的事情导致了组织的变化，这种变化继续令人惊讶和受到指导。
重构的新方法
在仅10个月的时间里，五个人离开了最初由10人组成的团队。西雅图一家科技公司的员工流失并不罕见。 也就是说，当团队的一半离开时，您作为经理和领导者就有机会以对客户和留在团队中的员工有影响的方式重塑组织。 您还要考虑谁留在团队中以及如何保留想要保留的人才。 我知道我们可以通过加倍对开放的承诺来做到这一点。
寻找员工加入团队需要时间。 每次出发后留下的较小团队都会团结起来为我们的客户做我们需要做的事情。 是的，我们在弥合差距的同时尝试学习如何表现出对开放的外部承诺时犯了错误。 但是为了使贡献和协作更加容易，我们更改了存储在GitHub中的文档集的结构。 这些更改需要花费几个月的时间来实施，因为我们在进行更改的同时进行了持续的更新和内容重构。
当团队决定重构内容时，即修改和重写内容以提高清晰度而又不影响技术准确性，则无法保证重构将达到团队预期的成功。 例如，几年前，我在一个团队中工作，该团队花了18个月的时间根据大量的客户研究来重构内容。 进行更改时，尽管进行了认真的研究和计划，但客户仍然不满意，我的团队不得不根据明确的迹象撤消更改，这些迹象表明更改导致对产品的巨大且持续的不满。
因此，当我目前的团队重构内容时，我们没有在幕后进行大胆，大胆的更改，而是在准备好交付少量新内容时，推动了较小的迭代更改。 如果要查看我们所做的每日更新，则只会看到看起来很小和很小的更改。 但是在六个月的时间内，这些“小”变更的总和就构成了质量改进的一大步。 采取这种迭代的日常方法的潜在弊端是，您可能会在稍后的过程中学习到一些东西，从而迫使您重新考虑早期的更改。 但是这种“我们为什么不等？” 片刻没有发生。 通过按位大小的块进行更新，我们发现在事情未按计划进行时，恢复起来会更容易。
例如，在我们的第一个更新中，当我们实时发布更改时，所有内容都脱机了。 我们的服务水平协议（SLA）表示，除非我们预先宣布维护窗口，否则我们将100％地在线。 脱机很重要 。 我们很快意识到配置设置是中断的根本原因。 四十五分钟后，我们回到了网上。 也就是说，在45分钟内，我们的内容处于脱机状态，并且客户注意到了。 我的团队没有发布借口，而是认为在进行改进的过程中，我们遇到了无法预料的问题，并致力于尽快进行修复。 球队幸存下来。
大约一个月后，当一个长期，值得信赖的贡献者建议进行更改时，我合并了提交，但未完成有关验证的尽职调查。 一天之内，我意识到通常值得信赖的贡献者提交了错误的信息，于是我提出了更正。 读者注意到了这些变化，并认为我们没有充分地解释这些变化。 关于此问题的Reddit主题很快就出现了，大约48小时内进行了许多有趣的内部和外部讨论。 我还好
这些类型的情况继续教会我们有关更新技术内容的知识。
坚持（开放）路线
但是，发生的更有趣的讨论之一与内容根本无关，而与客户可以在GitHub上阅读的更新有关。 具体来说，来自内部贡献者的提交消息开始显示在Bing搜索结果中。 团队觉得他们的私人信息正在公开。 我们讨论了是否应该找到抑制某些信息在外部共享的方法。
在讨论的最后，我们选择保持开放。
这些现在公开的摘要说明了我们作为团队所经历的事情。 在管理团队时，我犯了更多的错误。 但是通过所有这些，我学到了以下课程：
- 我始终致力于为不习惯可能被视为负面的事情的人们提供建设性反馈。 有些人积极回应并感谢我的意见。 其他人觉得我在基地之外。 有些人很安静，但是我可以看到他们的行为发生了变化，这使我明白他们已经听到了我的声音。
- 我要求提供反馈，并在收到反馈时听。 有人告诉我，对人太在意，与别人保持距离可以帮助我有更多的固定工作时间。 白天，我倾向于将大部分时间都花在与人交谈上。 我发现在电子邮件和在线聊天中，人们可能会沟通不畅。 亲自交谈或使用音频或视频会议与人交谈，可以减少沟通不畅，并提高生产力和员工敬业度。 我团队中的人们一直依赖电子邮件，以至于我经常花时间与人们交谈的想法是出乎意料的。 我担心自己将太多时间浪费在“生产性工作”上，所以我最初犹豫与人交谈。 但后来我想起与我合作过的最好的团队花了更多时间进行口头和面对面交流，而不仅仅是在线交流。
- 在管理风格和方法方面，我学会了成为合作伙伴和促进者 。 当团队承受很大压力时，（作为经理）有进行微观管理的趋势。 我不喜欢被微观管理，所以我抵制采用那种管理风格的冲动。 和我在一起的团队成员以及其他人一起离开的团队成员开始成为彼此信任的团队。
开放的承诺意味着我们（在内部和外部）都听取了别人的意见，但这不是每个人对最终结果感到满意的责任。 我记得开放的组织不是过于依赖共识的组织。 开放组织的重点是协作 。
经过14个多月，团队正在发生变化。 是的，原团队的一半已经离开。 但是新的团队成员并不是唯一的变化。 留在团队中的原始成员现在更有可能自由表达自己并嘲笑错误。 我可以提出这样的问题，即在经历开始时会导致沉默。 今天，这些问题通常会引发激烈的讨论。 人们愿意冒险，因为他们相信我们在犯错误时会学习。 我们以小组形式解决问题，并分享我们认为客户的需求。 由于人们倾向于共享工作并且不害怕被拆散，因此孤岛数量减少了。 我们彼此建立并向贡献者社区开放，他们关心我们发布的内容。
本文是“ 开放组织工作簿”项目的一部分 。
翻译自: https://opensource.com/open-organization/17/10/microsoft-collaboration-case-study
微软兼容性客户体验改善程序
7397
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
