在《Google软件工程》里了解如何在团队内进行学习和分享

《Google软件工程》这本书朋友推荐给我的时候内心里是懵的，咱就是说就我这coding level可万万不敢看狗哥软件工程。结果对方表示可以「少量多次，温水送服，按需阅读，比如只看第二部分」。

本着看看又不吃亏的原则，在物流原因买不到中文版的情况下还是忍不住看了一小章英文。

先说结论：这书，得推荐。

就算你完全不写代码，只要所在的实验室、团队或者公司涉及到软件相关或者扩大到脑力劳动和知识管理相关的工作，这书都应该读（至少第二部分）。

为什么学习和分享会是挑战

比如，你可以在这本写软件工程的书里搞清楚为什么在一个组织内部学习和分享会变成一种挑战。

在第二部分的第三章「Knowledge Sharing」，首先写了Google总结出的6条为什么在一个组织内部学习和分享会变成一种挑战的原因，包括：缺乏心理安全、存在信息孤岛和存在有或无专长等等。

为了不剧透就稍微扩展一点。

信息孤岛的存在会客观上带来三个问题：信息碎片化（每个岛屿对于整体都有不完整的描述）、信息重复（每个岛屿都重新发明了自己的做事方式）和信息偏倚（每个岛屿做同一件事情的方法可能并不完全兼容）。

而所谓「有或无专长」，则是组织内部被分成两类成员，一派是“无所不知”的人，另一派则是菜鸟，但是很少有中间状态。

如果专家总是自己做每一件事，而不花时间通过指导或文档来培养新的专家，这个问题往往会加剧。在这种情况下，知识和责任继续积累在那些已经拥有专业知识的人身上，而新成员或新手只能自己照顾自己，并以缓慢的速度成长。

如何营造一个心理安全的空间

如何应对这些问题呢？仅举例如何营造一个相对心理安全的空间，书中提到了几种推荐模式和反对模式。

**推荐模式（合作）**包括：

• 基础问题或错误需要被引导到正确的方向上

• 解释的目的是为了帮助提出问题的人学习

• 回应是亲切的、耐心的、有帮助的

• 互动是通过共同讨论来寻找解决方案

**反对模式（对抗）**包括：

• 挑剔基础问题或错误，并责备提问的人

• 解释的目的是为了炫耀自己的知识

• 回应是居高临下、刻薄、没有建设性的

• 互动是有「赢家」和「输家」的争论

不过，需要注意的是，反对模式往往都是在无意中出现的：有人可能试图提供帮助，但却意外看起来不受欢迎。Google在实际操作中，发现Recurse中心提供的三条社交规则，在组织内部很有帮助。

不要假装惊讶。 不要说「什么，我不相信你不知道……」这样的话。当人们说他们不知道一些事情时，你不应该表现出惊讶的样子。因为假装惊讶通常是为了让自己感觉更好而让别人感觉更糟。即使这不是目的，也总是最终的效果。

不要轻易说「好吧，实际上」。 当对方说的内容几乎是正确的但又不完全正确时，不要轻易说「好吧，实际上是…」然后给出一个小更正。尤其是当纠正对实际对话不会产生影响时。

不在后座上开车。 无意中听到别人在解决问题时，不应该断断续续地半参与对话。打断现有讨论又不投入到对话中的行为就像是坐在后座上开车。提供帮助和建议以及加入对话，这些都是被提倡和鼓励的，只是想帮助他人或与他人合作时，应该全力以赴而不是偶尔插手。

另外，在这一部分里，还写到了如何在组织中学习和分享等一系列话题。粗粗浏览感觉就很受用，如果看了上述部分让你产生了一点兴趣，也不妨找到这本书来读读。

本文作者：思考问题的熊

版权声明：本博客所有文章除特别声明外，均采用 知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议 (CC BY-NC-ND 4.0) 进行许可。

· 分享链接 https://kaopubear.top/blog/2022-07-16-book-software-engineering-at-google/