不要一直单打独斗

巴士系数

有一个系数叫“巴士系数”：

巴士系数
多少关键开发者被巴士撞了会让项目停摆。

该系数可用于衡量项目持续性，当只有一个人知道该项目的底细时，这个项目往往很难维持下去。

小步快跑

除了尽可能保障“测试左移”外，在项目进行时也需要通过团队合作，保障项目能一直运行在相对正确的轨道，在紧凑的反馈环中解决漏洞、对齐需求。一般来说，将4~8人的小团队集中到一个环境中，往往是比较有效的。

如何打造稳定的团队

打造稳定的团队，首先需要了解团队社交的三大支柱：谦虚、尊重和信任。另外也需要学会批评与接受批评，打造无指责的回顾文化，比如保持撰写好的回顾分析文档的习惯。同时不要惧怕快速失败和迭代，相反的，每次错误尝试又意味着往前迈了一步。

一份好的回顾文档
一份好的回顾文档应该包含下面这几个部分：

• 事件的简短摘要
• 事件的时间表，从发现调查到解决
• 导致该事件的主要原因
• 影响和破坏评估
• 可立即修复问题的行动事项
• 防止事件再次发生的行动事项
• 经验教训

这里可以参考“谷歌范儿 (Googley)”，它为团队文化提供了一个良好的参照：

• 在变化莫测的环境中施展才能：在环境不断应对的情况下，能处理相互冲突的信息或方向，建立共识，并针对问题取得进展。
• 让反馈变得有价值：谦虚地接受和反馈，理解反馈对个人和团队发展的价值。
• 挑战现状：能制定雄心勃勃的目标，并追求目标，即使有阻力或惰性。
• 用户优先：对用户有同情和尊重，并采取符合他们最大利益的行动。
• 关心团队：对同事有同情心和尊重，积极主动地帮助同事，提高团队凝聚力。
• 做正确的事：对所做的每件事都保有强烈的道德感，愿意做出困难或令人不舒服的决定，保护团队和产品的完整性。

知识共享的挑战

在知识共享过程中，会出现诸多挑战：

• 缺乏心里安全感：害怕在别人面前犯错误而收到惩罚，表现为恐惧文化/避免透明度倾向。
• 信息孤岛：知识碎片化，各部门之间彼此不通信，也不使用共享资源，且做事方式高度差异化，包括信息碎片化、信息重复、信息偏差等现象。
• 单点故障SPOF：体现为关键信息只能从单个人处获得，而无法培养后继人才，从而出现瓶颈。
• 专家或新手：一群人被粗暴地切分为两个部分，专家或新手，这导致两类人群之间的鸿沟难以弥补，且新手团队无法发展。
• 鹦鹉学舌：没有理解的模仿，表现为在不理解模式或代码用途的情况下无意识地复制模式或代码。
• 闹鬼墓地：人们因为恐惧和迷信而避免采取行动，比如避免接触和更改代码。

设计知识共享

知识共享的基调：心理安全

心理安全对促进学习环境的形成至关重要，尤其是针对大型群体的心理安全。下表就列出了一些推荐的群体互动模式供参考：

推荐模式 (合作)	反模式 (对抗)
基本的问题或错误被正确引导	基本的问题或错误被挑剔，提问者被责骂
解释的目的是帮助提问者学习	解释是为了炫耀自己的知识
回应是亲切的、耐心的和有帮助的	回应是居高临下、尖刻、没有建设性的
互动是寻找解决方案的共享讨论	互动是“赢家”和“输家”的争论

这里也提供 Recurse Center 的社交规则：

• 不要假装惊讶：假装惊讶是心理安全的障碍，且会让团队成员害怕承认自己缺乏知识。
• 不要故弄玄虚：卖弄学问的纠正，往往是哗众取宠，而不是提供精确答案。
• 不要乱出主意：打断既有讨论，提供意见，但不对谈话内容负责。
• 不要有微妙的言语表达：带有偏见的一些表达会使人感到不受欢迎、不被尊重或没有安全感。

如何实现知识共享

充实自身

知识分享从自身开始，不仅要理解新事物，还要理解现有设计和实现背后决策的缘由。这里介绍“切斯特森围栏 (Chesterson’s Fence)”原则，即理解上下文：

切斯特森围栏 (Chesterson’s Fence)
在去除或改变某事物前，首先了解它为什么在那。

提问和分享

进一步的，当自身无法解决问题或对知识学习有困难时，可以向社区提问。现在有多种方式进行提问，比如群聊、邮件、问答平台等等。同时也有多种渠道进行分享，比如Office Hours、技术讲座与课程、文档、代码等等。

这里特别强调文档部分的共享：

• 更新文档：请在发现问题时，在任何合适的时候更新文档，并提供一些评审建议。
• 创建文档：请确保在执行事务的过程中始终有对应的文档从而方便参照，并确保有一个反馈机制。
• 文档推广：文档推广是一个值得激励的事，编写文档有助于团队和组织中知识共享的规模化。

组织知识发展

知识共享应该建立在善意和尊重的基础上，且需要提供一定的激励与奖赏。同时，也需要建立足够规范的信息源，作为规范集中的信息库。这个过程有助于知识的扩展，专家可以利用公共的、可拓展的资源来识别和解决特定的信息需求。

另外，还有一些值得特别提出的方法，比如使用静态分析同居，这有助于增加工程师的知识，可以让一个组织能更有效和一致地使用到更多的最佳实践。

另外，让信息流动起来也至关重要，比如适时提供资讯，进行一些诸如马桶测试、厕所学习等喜闻乐见的方式。

提升可读性：通过代码评审规范化指导

可读性流程

代码评审非常重要，每个CL都需要经过可读性评审，可读性评审由持有可读性人认证的人员进行(现在也可以依靠AI Assistant了)。可读性认证通常指拥有“某种语言”的可读性认证。将CL提交到可读性认证申请流程后，即可开始评审。随着作者对可读性指南掌握得越来越熟练，他们收到的CL评审意见会越来越少。

可读性是一个人为驱动的流程(现在也应该可以设计AI Flow进行了)，旨在以既标准化又个性化的方式扩展知识。可读性流程融合了书面知识和部落知识的优点，既能提供书面的评审意见，又能通过专家评审员传播最佳实践，从而保证规范指南和语言建议被完整地记录下来。

另外，建议进行集中评审，因为程序会随着组织的增长而增长，集中评审更容易强制代码的一致性、避免孤岛以及不符合规范的地方。同时如果需要进行评审的规模较大，为评估其必要性，可以通过设置工程生产力研究(EPR)团队进行评估。