如何提升软件工程师沟通能力：运用修辞情境改善内部沟通

提升软件工程师的沟通能力，可以从理解和运用“修辞情境”这一框架入手。无论是代码审查、站会汇报，还是故障复盘，明确沟通目的、了解目标受众，并结合具体语境选择表达方式，都有助于改善技术团队内部沟通。

2022年底，我花了几个小时与公司的工程部门负责人交流，了解团队在技术能力提升方面的需求。我希望弄清楚：为了实现公司2023年及以后的技术战略目标，我们的软件工程师需要掌握哪些技能？

在一次交谈中，一位负责人提出，工程师需要提升沟通能力。另一位负责人则持不同意见，认为工程师应当专注于编写代码这项核心工作。

对此，我得提出一点异议。工程师每天都在与人沟通：撰写代码审查意见、在站会上汇报进展、向非技术人员解释技术概念、说明交付延期的情况、演示产品……这样的例子不胜枚举。

与其他职业的从业者一样，工程师也并非总能把沟通做好。沟通不畅会给软件开发带来怎样的负面影响，早已为人所知，读者想必也深有体会。因此，我们需要找到改善沟通的方法，并用工程师能够理解和接受的方式，解释有效沟通是如何实现的。

如何提升软件工程师沟通能力：运用修辞情境改善内部沟通
提升沟通能力，从培养修辞意识开始
提升沟通能力的一大难点在于，有效沟通本身并不容易。

人们常有一种误解，认为善于沟通的人天生如此，表达起来毫不费力。但真正优秀的沟通者最清楚，要取得良好的沟通效果，必须投入大量心力，运用复杂的认知能力和熟练的分析技巧。

好消息是，软件工程师在日常开发中已经在运用这些能力。因此，帮助他们提升沟通水平，可以从他们熟悉的分析方法和创造性思维入手。

此外，我们还有丰富的知识资源可供借鉴。几千年来，人们围绕修辞与写作积累了大量理论和研究成果，能够为沟通教学提供支持。具体而言，我们可以向软件工程师介绍“修辞情境”，帮助他们理解如何在工作中那些具体而又反复出现的情境下进行有效沟通。

什么是修辞？

修辞既可以指旨在说服受众或产生感染力的语言表达，也可以指有效运用口头或书面语言的艺术。本文所说的修辞，关注的是如何根据具体情境组织表达，实现沟通目的。

什么是修辞情境？理解沟通的五个要素
对软件工程师而言，修辞情境提供了一个分析框架，可以帮助他们有意识地选择沟通方式，使信息更有效地传达给目标受众。

美国修辞学家劳埃德·比泽尔（Lloyd Bitzer）在1968年发表的论文《修辞情境》中，对这一概念作出了奠基性的阐述。在写作教学中，我们可以将修辞情境通俗地理解为“沟通发生时的具体情境”。本文采用便于教学和实践的五要素框架，从文本、作者、目标受众、目的和语境五个方面展开讨论。

下面，我们逐一解释这些要素，并看看工程师如何将它们运用于工作中的沟通。

1. 文本：采用什么表达形式
   这里的“文本”并不局限于书面文字，而是泛指承载意义、用于交流的表达作品。小说、简历和演讲是文本，雕塑、涂鸦和歌曲也可以被视为文本。

不同类型的文本各有特征，包括语言风格、语气、格式、篇幅、结构，以及发表或呈现的场合。遵循一定社会惯例、具有共同特征的表达形式，可以归为同一种“体裁”（genre）。

软件工程师在工作中经常使用的书面或口头文本包括：

工单描述
工单评论
每日站会汇报
代码提交说明
拉取请求说明
代码审查意见
迭代成果演示
面向客户的演示
项目进展汇报
技术文档
版本发布说明
这些沟通形式各有约定俗成的规范。如果工程师不了解或没有遵循相应规范，就容易造成沟通障碍。

研发管理工具也可以为这些表达提供具体的承载场景。例如，使用 PingCode 管理需求、开发、测试和发布流程时，团队可以根据不同环节的沟通目的组织信息，并通过 Wiki 沉淀知识与经验。需求描述应帮助协作者理解要解决的问题，测试记录应清楚说明验证情况，知识文档则应便于后续查阅和复用。工具承载了信息，而信息是否清楚、完整，仍取决于团队如何组织表达。

2. 作者：由谁发起沟通
   作者是文本的创作者，可以是个人，也可以是群体。在口头沟通中，发言者同样承担着作者的角色。作者的个人特点、知识背景、立场和偏见等，都会影响文本。

作者在组织中的角色，也会影响其通常负责哪些类型的文本。例如，大型公司的首席技术官一般不会亲自撰写代码提交说明，而初级开发人员也较少牵头起草技术征求意见稿（RFC）。这种差异反映了不同角色的职责与工作重点。

3. 目标受众：与谁沟通
   目标受众是作者希望通过文本与之沟通的人，包括读者、听众或观看者。

创作文本时，作者应当明确受众是谁，并考虑他们的知识背景、立场、预期和可能存在的偏见。这些因素会影响受众如何理解和回应信息，也应当影响作者对内容和表达方式的选择。

例如，首席工程师或高级工程师在审查初级工程师的拉取请求时，应当考虑对方已有的知识，以及对方可能如何理解这些反馈、产生怎样的感受，据此调整解释的详略和措辞。

4. 目的：希望达到什么结果
   目的是作者希望通过文本达到的结果。它不仅涉及要传达什么信息，还涉及希望受众理解什么、作出什么判断，或采取什么行动。

目的是文本创作的驱动力。作者通常需要先明确目的，再决定采用哪种体裁，以及如何选择和组织内容。而沟通目的往往源于外部要求或实际工作需要。

例如，一位首席工程师受命培训同事使用一项新服务。明确这一目的后，他需要思考：“面对这些受众，采用哪种沟通形式，最有助于他们学会使用这项服务？”

5. 语境：沟通发生在什么条件下
   语境是指沟通发生时的具体条件，包括促成这次沟通的需求，以及影响沟通的各种环境因素。这些因素可能作用于作者、目标受众和沟通目的，也可能直接影响文本本身。

很多时候，沟通目的正是由语境决定的。例如，通常只有当项目进展面临风险，或相关工作受到格外关注时，工程师才可能被要求每天向管理层汇报进度。

应用案例：故障排查与故障复盘中的团队沟通
在这五个要素中，作者、目的、目标受众和语境相互作用，共同影响文本应当包含哪些内容、采用什么形式，以及如何表达。

我们需要帮助工程师将已有的分析能力运用于沟通：明确自己的角色和沟通目的，了解目标受众，并分析具体语境。在此基础上，他们就能结合实际条件，选择合适的体裁和表达方式，更有效地实现沟通目标。

故障排查：围绕定位问题组织信息
不妨设想这样一个场景：应用程序完全瘫痪，客户无法使用。通常，少数相关人员会迅速组成应急小组，集中排查问题。

此时，沟通很可能以口头交流为主，目的是汇集有助于定位故障的信息。受众是参与排查的其他成员，他们大多具备专业技术知识。因此，每位发言者都需要有意识地组织信息，让交流在紧张、高压的环境下仍能推动问题解决。

如果有人不断提起代码库中与此次故障无关的问题，或用玩笑、闲聊打断讨论，其他人就很难集中精力查明故障原因。

故障复盘：让不同背景的受众理解情况
再设想一下：问题已经查明并解决，现在需要向整个组织通报情况。

通常，应急小组中的一名成员会负责撰写故障复盘报告，说明事件经过及根本原因。这时，受众已不再局限于参与排查的技术专家，而是同时包括技术人员和非技术人员。

受众和目的发生了变化，文本也必须随之调整。报告应当遵循故障复盘报告的常用格式，交代必要的背景，用清晰易懂的语言解释关键技术问题，并保持简洁，让没有参与现场处置的人也能理解发生了什么。

如果复盘后还需要多个部门共同推进改进，可以借助 Worktile 的文档、任务和项目协作功能，记录复盘结论，并将后续行动拆解为明确的任务。面向跨部门协作者，任务说明应写清预期结果、负责人和完成时间，让受众知道接下来需要做什么。

同一次故障，在处置过程中和处置结束后，需要采用不同的沟通方式。修辞情境框架能够帮助工程师理解这种差异，并据此作出恰当的表达选择。

管理者如何帮助工程师提升沟通能力？
在目前的工作中，我为软件工程师举办了相关研讨会，介绍修辞情境这一框架，并鼓励他们在每次沟通时，都考虑作者、受众、目的和语境之间的关系，进而判断应当如何组织信息、选择表达形式。

当工程师开始从这些角度审视沟通时，常常会露出恍然大悟的神情。因此，我建议你也向团队介绍这一概念，并带领大家分析有效和无效的沟通实例，理解不同的表达选择为什么会带来不同的结果。

实践时，可以先从一条代码审查意见或一份项目进展汇报开始：由谁表达？面向谁？希望达到什么结果？有哪些实际条件需要考虑？据此判断，当前的内容和形式是否合适。