Communication Skills in Software Engineering: A Multivocal Review
这篇多声部文献综述综合了碎片化的学术文献与灰色文献，旨在表明尽管两者都一致认为沟通是软件工程中的一项核心能力，但在侧重点上存在差异，即学术界优先考虑概念化与实证证据，而工业界文献则强调实际应用与新兴实践。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
将软件工程想象成一场规模宏大、赌注极高的交响乐演出。长期以来，人们一直认为唯一重要的事情是每位音乐家演奏其乐器的水平（即编程和技术能力）。但本文认为，即使是最出色的小提琴手，如果无法倾听指挥、无法阅读大提琴手分享的乐谱，或者无法解释自己为什么漏掉了音符，也会失败。
作者们是一个来自巴西的研究团队，他们决定调查一个重大问题：“老师们”（学术界）和“舞台上的音乐家们”（行业专业人士）在讨论软件工程中沟通技巧的重要性时，是如何交流的？
为了找到答案，他们不仅仅查看了一类书籍。他们进行了一场“多声部综述”（Multivocal Review），这就像是从两个不同的图书馆中收集观点：
- 学术图书馆： 正式的研究、科学论文和大学研究。
- “灰色”图书馆： 博客、行业报告、Stack Overflow 讨论以及由从业开发者撰写的文章。
以下是他们的发现，通过简单的概念进行了拆解：
1. 巨大的共识：每个人都需要扩音器
科学家和行业专业人士在一点上达成了高度一致：沟通不仅仅是一个“锦上添花”的额外技能；它是一项核心要求。
- 学术观点： 他们将沟通视为一种科学事实。他们拥有数据证明，职位公告将沟通列为顶尖技能，其重要性甚至超过了技术技能。他们证明了沟通良好的团队出错更少，项目完成得更快。
- 行业观点： 他们将沟通视为一份生存指南。他们的博客和文章会说：“如果你不能解释你的代码，你就无法晋升，”或者“糟糕的沟通会导致被解雇。”他们关注的是沉默或混乱带来的直接、现实世界的后果。
隐喻： 把沟通想象成将软件粘合在一起的胶水。学术界通过测试证明了这种胶水很强韧；而行业从业者则亲眼目睹了当胶水缺失时，建筑是如何崩塌的。
2. 目标相同，视角不同
虽然他们在“重要性”上达成了一致，但他们通过不同的镜头来看待这个问题，就像两位摄影师从不同的角度拍摄同一座山。
“科学”视角（学术界）：
- 焦点： 他们将沟通拆解为微小且具体的组成部分。他们研究“同步与异步”对话、“跨文化胜任力”和“积极倾听”。
- 证据： 他们使用数字、百分比和调查。他们说：“80% 的职位广告要求这项技能。”
- 目标： 为大学如何教授这些技能建立结构化的课程体系。
“街头智慧”视角（灰色文献）：
- 焦点： 他们谈论的是感觉和结果。他们关注“讲故事”、“如何在不伤害感情的情况下给予反馈”以及“确保老板理解计划”。
- 证据： 他们使用故事和个人经历。他们说：“我见过一个项目因为没人明确需求而失败。”
- 目标： 提供快速、实用的建议，帮助开发者在日常工作中生存并蓬勃发展。
3. 哪里不太匹配（细微差别）
论文指出，他们在讨论该话题时存在一些细小的差异：
- “英语”因素： 学术论文非常担心全球化团队中的语言障碍和文化差异。他们将“说英语”和“理解文化”视为沟通技能集的一部分。而行业博客通常假设每个人都已经会说英语，并将其视为一项独立的技能，更多地关注沟通的行为本身，而非语言。
- “氛围”因素： 行业作者经常谈论良好的沟通如何让办公室变得更快乐、减轻压力并建立信任。学术界则倾向于关注更硬性的指标，如“生产力”和“项目成功率”，有时会忽略情感层面的“士气”。
4. 总结
论文得出结论，这两个群体之间并不存在冲突。他们并没有在争吵，他们只是在用不同的方言说着同一种语言。
- 学术界提供了蓝图（理论与衡量标准）。
- 行业界提供了施工队（现实世界的应用与故事）。
最终隐喻：
想象软件工程是一艘船。学术界是造船师，他们设计船体并证明如果沟通渠道是水密的，船就可以漂浮。行业专业人士是船长和船员，他们知道如果船员在风暴中没有清晰地呐喊，船就会撞上岩石。
论文指出：停止争论沟通是否重要。 双方都同意这是最重要的技能。下一步是将建筑师的蓝图与施工队的经验相结合，去建造更好的软件团队。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。