为什么熟悉度能让协作更轻松？
在分布式软件团队中，成员常常分开工作，无法依赖走廊里的随意交谈。熟悉度之所以有帮助，是因为它建立了共享心智模型——关于谁做什么、工作如何流转、他人需要什么的共同预期[1]。当队友已经了解彼此的习惯以及各自参与过的软件部分时，他们可以用更少的明确来回沟通来完成协作。一项针对软件团队的研究发现，先前对相同软件部分和项目的熟悉度能减少协作投入[1]。
这并不意味着熟悉度消除了沟通的需要。相反，它改变了所需沟通的类型：队友不必事无巨细地说明，而可以依赖默契理解。当工作本身较为熟悉时，这种效果最强，因为团队成员既能预判任务，也能预判彼此[2]。
任务熟悉度和团队熟悉度有区别吗？
有区别。一项针对地理上分散的软件团队的实地研究考察了任务熟悉度（对工作的经验）和团队熟悉度（一起工作的经验），发现它们会与协作复杂度相互作用，从而影响绩效[2]。通俗地说，一个了解代码库但从未合作过的团队可能仍然举步维艰，而一个彼此熟悉但面对全新任务的团队可能需要更多明确协作。
同一项研究还表明，熟悉度的价值取决于协作挑战有多复杂。当协作较简单时，熟悉度可能帮助不大；当协作复杂时，熟悉度能帮助团队避免误解[2]。这与以下观点一致：熟悉度之所以起作用，是因为它减少了每次交接都要从头协商的需要。
对工具和技术的熟悉度呢？
熟悉度不仅关乎人。在横跨在岸和离岸站点的全球分布式团队中，协作还取决于成员对所使用工具和技术的熟悉度与专业能力[5]。当离岸团队成员熟练掌握公司工具后，他们能与在岸同事更顺畅地协作，因为他们共享一套技术词汇，并理解所使用系统的限制。
这种工具熟悉度补充了团队熟悉度：了解技术减少了需要解释的事项，从而把沟通释放出来，用于工作中真正新颖或模糊的部分[5]。
过度熟悉会适得其反吗？
在另一个情境中——英格兰超级联赛足球——研究人员发现，当前的团队熟悉度对协作有一种先升后降的曲线效应：中等熟悉度有帮助，但极高的熟悉度与更差的协作相关[4]。该研究还发现，先前的团队熟悉度对协作没有主效应，而当先前熟悉度较低时，失去一名团队成员对结果的负面影响更强[4]。这些发现来自运动队而非软件团队，因此应将其视为一种警示，而不是对分布式软件工作的直接预测。
对软件团队而言，这意味着熟悉度不是一种简单的“越多越好”的资源。当任务变化或团队构成变动时，它可能需要更新，因为熟悉的惯例可能变得过时或与新工作不匹配[2][4]。对于分布式软件团队，熟悉度从何时开始不再有帮助、转而造成损害，目前尚无定论。
本文引用的文献
共享心智模型、熟悉度与协作：分布式软件团队的多方法研究
先前对相同软件部分和项目的熟悉度通过支持共享心智模型，减少了软件团队中的协作投入。
地理分布式软件开发中的熟悉度、复杂度与团队绩效
任务熟悉度和团队熟悉度会与协作复杂度相互作用，影响地理分布式软件团队的绩效。
地理分布式软件开发中的团队知识与协作
分布式软件团队的协作需求受团队知识塑造，包括成员间的共享词汇和熟悉度。
团队熟悉度如何缓解团队构成中断的负面后果：对英超球队的分析
在英格兰超级联赛足球中，当前的团队熟悉度对协作有一种先升后降的曲线效应，而先前的团队熟悉度调节了团队成员流失对结果的间接影响。
全球分布式团队的协作：离岸外包的共同演化视角
全球分布式在岸—离岸团队的协作涉及对所用工具和技术的熟悉度与专业能力的获取。