工程领导者如何运用沟通框架提升沟通能力

你是否认真投入过时间，提升自己的沟通能力和软技能？

作为软件工程师，我们很容易优先关注技术能力：学习新的编程语言、熟悉新的开发框架、研究新的架构模式。

但随着职业发展，我们终究会面对一个问题：

为什么沟通能力与技术能力同样重要，甚至可能更加重要？

对于工程领导者来说，技术能力决定了你能否理解问题，而沟通能力则决定了你能否推动团队共同解决问题。

我曾经一心想成为“全栈高手”

从 1997 年开始，我一直以软件开发为职业。

这些年来，我已经记不清自己以参与者或演讲者的身份参加过多少技术聚会和行业会议，也记不清看过多少视频、读过多少技术文章。

我做这一切，都围绕着同一个目标：

提升开发能力，成为所谓的“技术大神”“编程忍者”“摇滚明星工程师”或“全栈开发者”。

软件行业里，许多开发者将自己视为艺术家，把自己的作品看作神圣的创造。他们相信，优秀的软件源于个人强大的意志力，而这种能力只能通过多年的不懈投入获得：白天以软件开发为职业，晚上继续参与开源项目。

我过去也深受这种观念影响。

直到 2012 年，我开始更多地参与工作之外的技术社区，才逐渐意识到：试图成为一名无所不知的全栈开发者，或许从一开始就是一个无法实现的目标。

“全栈开发者”本身就是一个模糊概念

几年后，我在软件开发社区认识了许多能力出色、同时又十分谦逊的工程师。

他们和我一样重视软件质量，但这些交流也让我越来越清楚地认识到：试图成为技术栈每个层面的专家，往往源于一种不切实际的自我期待。

构建世界一流的软件，是一项复杂、有时甚至十分混乱的工作。

它可能同时涉及：

• 后端开发；
• 前端开发；
• 用户体验；
• 隐私保护；
• 无障碍设计；
• 持续集成与持续交付；
• 基础设施；
• 运维与可靠性；
• 安全与合规。

任何个人都不可能掌握成为所有这些领域专家所需的全部知识。

人们通常把“全栈开发者”理解为能够独立完成一款应用从前端到后端开发的人。

但这种解释过于简单。

一个人的技术能力并不是一个单一数值，而是由多个维度构成的。

你可能非常擅长后端开发，却对前端生态了解有限；也可能熟悉基础设施和持续交付，却不擅长用户体验设计。

那么，一个人的“全栈水平”究竟应该如何衡量？

是取最擅长领域的水平？这样，只要具备 T 型能力，就可以称为全栈开发者。

还是取最薄弱领域的水平？这意味着你必须精通所有领域，才有资格使用这个称号。

抑或是对所有能力取一个平均值？

只要稍微深入思考，就会发现，“全栈开发者”这个标签本身就存在问题。

技术能力还取决于业务领域

开发软件所需的能力，不仅取决于技术栈，也取决于软件所服务的业务领域。

如果你长期从事电子商务项目，可能会对以下方面积累深厚经验：

• 性能优化；
• 支付系统；
• 用户体验流程；
• 转化率优化；
• 高峰流量处理。

如果你主要开发银行内部系统，那么你的专业知识可能集中在：

• 数据一致性；
• 权限管理；
• 审计与合规；
• 交易安全；
• 风险控制；
• 遗留系统集成。

即使两个人使用相同的编程语言和开发框架，他们的实际能力也可能因为行业背景不同而存在巨大差异。

技术能力始终与具体行业、系统环境和问题领域紧密相关。

技术能力的有效期非常有限

讨论技术能力时，还需要考虑第四个重要维度：时间。

一个人的能力取决于他把多少时间投入到哪些领域。

但由于任何人都不可能同时提升所有能力，不同技术领域的熟练程度会随着职业发展不断变化。

当你专注学习后端架构时，可能会逐渐跟不上前端生态的发展；当你深入研究云原生基础设施时，过去熟悉的某些开发框架可能已经发生巨大变化。

软件行业变化极快。

许多今天非常重要的技术能力，几年后可能就会过时。而几年，只占整个职业生涯中很短的一部分。

这意味着，你几乎不可能在整个职业生涯中始终掌握完整的技术栈，更不可能真正成为一名长期有效的“首席全栈开发者”。

抱歉，事实就是如此。

认识到这一点后，我开始重新调整自己的学习方向。

与其追求掌握所有技术，不如把精力集中在三个方面的交集上：

• 我真正擅长什么；
• 我对什么感兴趣；
• 我能够如何将这些能力转化为职业价值。

对我来说，这意味着专注成为一名优秀的云原生解决方案架构师和开发者，同时尽可能跟上前端领域的重要变化。

软件开发从来不是个人项目

即使在 2017 年，我也还没有完全意识到另一个更重要的事实。

当时，我似乎仍然把自己的职责视为孤立的个人工作。

今天看来，这个事实或许显而易见：

软件开发是一项团队工作。

一个项目达到一定规模后，任何个人都不可能独自完成所有技术决策，也没有人能够仅凭一己之力创造真正卓越的软件。

每个人都会缺少一些关键能力。

你需要依靠他人补充自己的知识盲区；随着经验增长，其他人也会越来越依赖你的判断和支持，才能充分发挥自己的能力。

资深工程师的价值，不只是自己能够完成更多工作，也在于能否帮助身边的人取得更好的成果。

如果让我把职业生涯中遇到的问题分成两类：软件问题和人的问题，那么真正困难的，往往都是人的问题。

工程团队中的人际问题更难解决

软件问题当然也可能十分棘手。

但大多数软件问题最终都有某种解决方式：

• 修复它；
• 绕过它；
• 重构它；
• 替换它；
• 放弃原来的方案，采用另一种方式。

人的问题则完全不同。

真正让我感到压力，甚至夜不能寐的，往往是人际关系、沟通失误和团队冲突。

我们无法像修改代码一样修改一个人，也不能强迫别人按照自己的意愿行事。

我们能做的是努力理解彼此、寻找共识，并共同解决问题。但归根结底，我们无法直接改变对方。

工程师很容易把解决软件问题的思维方式错误地应用到人身上。

我们可能会认为：

“只要我足够耐心、足够详细地解释他哪里错了，问题就会消失。”

但现实通常并非如此。

沟通不是单纯的信息传输。它还受到情绪、身份、信任、权力关系、个人经历和组织环境的影响。

过去，我投入了大量时间学习技术，却很少系统学习如何协作、沟通和处理冲突。

我相信，我并不是唯一这样做的工程师。

工程师为什么容易忽视沟通能力

开发者通常愿意花钱、花时间学习技术知识。

我们会购买课程、参加会议、订阅技术内容，或者投入大量业余时间研究新的工具和框架。

但我们很少以同样认真的态度提升沟通与协作能力。

这并不是因为雇主从不提供这类培训。事实上，很多公司同样很少提供系统的技术培训，但工程师仍然会主动寻找技术学习资源。

真正的问题在于，我们往往没有把沟通视为一项需要刻意练习的专业能力。

我希望这种情况能够改变。

这也是我写这篇文章的原因。

工程领导者如何开始提升沟通能力

软件行业里充满了围绕技术能力建立的社区、博客、聚会和会议。

经过多年积累，我已经能够轻松地从社交媒体、技术社区和视频平台中发现有价值的技术内容。

因为我知道应该关注什么，也能够借助长期训练形成的模式识别能力，快速判断哪些内容与自己有关。

但对于协作、沟通和领导力，我过去并没有形成类似的敏感度。

我不知道应该寻找什么，也不知道如何判断一种沟通方法是否值得学习。

过去几年里，我开始有意识地探索不同的沟通框架。

这些框架未必适合所有人，也无法解决所有问题，但它们为理解沟通与冲突提供了一套结构化的方法。

为什么工程领导者需要沟通框架

前面提到，人的问题与软件问题并不相同，因此我们不能直接套用同一套处理原则。

我无法控制他人的行为，但必须为自己的反应负责。

当别人的言行影响到我时，我可能会感到愤怒、受伤、烦躁或羞愧。

这些感受是真实的，但如何理解和处理它们，是我自己的责任。

就像软件开发中会采用现有的技术框架一样，沟通中也可以借助成熟的方法和模型。

软件框架能够帮助我们避免反复犯同样的错误，并为常见问题提供最佳实践。

沟通框架也有类似的价值：帮助我们识别问题、组织表达，并减少与他人沟通时产生的不必要冲突。

非暴力沟通：减少工程团队冲突

非暴力沟通帮助我识别自己的情绪，并把观察、感受、需要和请求区分开来。

它鼓励人们清晰地描述事实，表达真实感受，说明背后的需要，并提出具体请求，而不是直接指责对方。

例如，与其说：

“你从来不尊重我的意见。”

不如说：

“在今天的会议中，当我两次发言都被打断时，我感到有些沮丧，因为我希望自己的观点能够被完整听到。下次能否让我先把想法说完？”

这种方式提供了一套拆解沟通内容的流程。

许多信息最初会被情绪包裹，让人难以识别真正的问题。非暴力沟通可以帮助我们逐层分析，理解自己究竟观察到了什么、感受到了什么、需要什么，以及希望对方做什么。

不过，这种方法也有一定局限。

很多时候，分析主要由我独自完成，并没有与对方共同探索他们的沟通方式、感受和需要。

因此，它可以帮助我们改善自己的表达，却不能替代双方真正的对话。

海外一些工程领导力从业者曾分享过如何将非暴力沟通运用于工程团队的反馈和摩擦处理，为职场应用提供了有价值的参考。

沟通的四层信息模型

另一种有用的方法，是把一条信息理解为同时包含四个层面：

• 事实信息；
• 自我表达；
• 关系信息；
• 行动诉求。

这一模型有助于识别发送者混合在一起的不同信息，也能帮助接收者理解：自己听到的内容，可能只是对方表达的一部分。

例如，某位同事说：

“这个功能怎么还没有完成？”

这句话表面上是在询问进度，但其中可能同时包含：

• 他认为项目已经延期；
• 他对当前状态感到焦虑；
• 他怀疑团队是否能够按时交付；
• 他希望你采取行动或重新确认交付时间。

尤其是在书面沟通中，由于缺少语气、表情和其他非语言信息，人们更容易只从某一个层面理解内容。

有意识地拆解这些信息，可以帮助我们减少误解，也能更准确地回应对方真正关心的问题。

用不同方式表达认可和肯定

“五种爱的语言”原本主要用于亲密关系，但它所揭示的一个核心观点，也适用于职场：

不同的人感受到认可和重视的方式并不相同。

大多数人工作时，都希望自己的投入和贡献能够得到某种形式的肯定。

有些人重视直接的语言认可，有些人更看重实际帮助；有些人希望获得高质量的交流时间，还有人更重视具体的机会、礼物或公开表扬。

作为领导者和合作者，了解一个人受到什么驱动，以及什么方式能让他真正感受到自己的工作被重视，非常重要。

你习惯采用的认可方式，可能与对方真正看重的方式完全不同。

例如，你可能认为把重要任务交给对方，就是在表达信任；但对方可能更需要直接听到你对其工作的认可。

因此，在表达感激和肯定时，不能只使用自己最自然的方式，还应该考虑对方能否真正接收到这份认可。

核心协议：高度结构化的团队沟通方法

我曾经花时间研究过一套被称为“核心协议”的团队协作方法。

它通过明确的行为规则来规范人际互动，试图减少沟通中的模糊与误解。

这种方法结构清晰，对某些团队可能非常有效。

但在我的经验中，它要求参与者具备很强的自律性，并严格遵守一套相对固定的互动方式。

如果运用不当，团队成员可能会觉得自己受到过度控制，沟通也会产生一种不自然的感觉。

对于人员背景多样、需要逐步改变工作习惯的团队而言，这种高度规范化的方法往往很难直接落地。

它也很难向没有接触过这套体系的人解释，甚至可能让互动显得缺乏人情味。

尽管如此，这套方法仍然是一份值得参考的资料，因为它非常明确地列出了许多常见沟通问题，以及可以采取的具体应对方式。

结构化 RFC 流程：改善技术决策沟通

海外一些资深工程师曾提出结构化的 RFC 流程，用于改善技术讨论和决策沟通。

这种方法之所以重要，是因为决策往往是冲突最容易出现的环节，也是团队内部权力关系最容易暴露的时刻。

谁有权提出方案？

谁能够否决决定？

哪些人需要参与讨论？

什么时候应该结束讨论并开始执行？

结构化 RFC 流程通过明确以下内容，减少决策过程中的混乱：

• 需要解决的问题；
• 提案负责人；
• 需要参与评审的人；
• 收集反馈的方式；
• 最终决策者；
• 决策期限；
• 提案被采纳或拒绝的原因。

对于复杂研发项目，也可以借助 PingCode 将 RFC、需求、技术任务、评审意见和最终决策关联起来，并将相关经验沉淀到 Wiki 中。这样不仅能让参与者看到决策过程，也能帮助后来加入的成员理解方案为什么形成，以及后续工作如何从讨论进入实施。

这种结构无法消除分歧，但能让团队更清楚地知道：分歧应该如何表达，讨论应该如何推进，决定最终又将如何形成。

领导力阶梯：提升团队自主性

“领导力阶梯”是一种非常有价值的沟通模型。

它描述了团队成员在决策中承担的不同程度的自主权和责任。

例如，一个人可能会说：

• “请告诉我应该做什么。”
• “我发现了一个问题。”
• “我看到了几种可能的方案。”
• “我建议采用其中一种方案。”
• “我打算这样做，除非你反对。”
• “我已经作出决定并开始执行。”

这些表达代表了不同程度的决策自主权。

这一模型的价值在于，它把团队中原本隐性的决策规则明确化。

管理者可以清楚说明，自己希望成员达到哪一级；团队成员也可以通过调整表达方式，逐步承担更多判断和决策责任。

在日常协作中，还可以通过 Worktile 等项目协作工具明确任务负责人、决策权限、依赖关系和检查节点，让团队成员不仅知道自己要做什么，也清楚哪些事情可以自主决定、哪些需要提前同步，以及遇到问题时应该向谁升级。

它提供了一种让所有人参与决策的沟通模式，也为成员提升自主性建立了一条清晰路径。

对工程沟通与协作的探索才刚刚开始

我对沟通和协作领域的探索才刚刚开始，但已经积累了足够多的资料，可能需要很多年才能真正消化和实践。

我也建议工程师在参加开放讨论、行业活动或社区聚会时，主动组织关于协作与沟通的分享。

这样做不仅能够传播这个话题，也能收集其他人正在使用的资源和方法。

我曾在一次海外社区活动中组织过类似讨论，并因此获得了一份很有价值的推荐书单，其中包括：

• 《关键对话》；
• 《化敌为友》；
• 《教练的习惯》。

这些资源从不同角度讨论了困难沟通、影响力、教练式领导和冲突处理。

沟通能力是工程领导者的核心能力

我希望这些经历能够鼓励更多工程师，投入时间提升真正影响职业发展和团队表现的核心能力：

沟通方式和处理冲突的能力。

这些能力会深刻影响你的个人工作体验，也会影响整个团队的状态。

良好的工程团队沟通能够帮助组织建立一种健康的工作环境，让每个人都感到：

• 自己受到重视；
• 自己的意见被认真倾听；
• 自己得到了理解；
• 可以安全地提出担忧；
• 可以公开表达批评；
• 可以大胆提出创新想法。

随着职业发展，技术能力依然重要。

但工程领导者的影响力，越来越少来自亲自编写了多少代码，而更多来自能否帮助一群人理解彼此、作出决定，并围绕共同目标开展合作。

正如一位海外工程领导者所说：

“过度关注技术，可能会让你拥有资深工程师的技能，却只有初级员工的经验。”

真正成熟的工程领导力，不仅体现在你知道什么，也体现在你如何倾听、如何表达，以及如何帮助他人共同取得成功。