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

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

作为软件工程师，我们很容易优先关注技术能力：学习新的编程语言、熟悉新的开发框架、研究新的架构模式。但随着职业发展，我们终究会面对一个问题：

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

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

我曾经执着于成为“全栈开发者”

自 1997 年开始以软件开发为职业以来，我已经记不清自己参加过多少场技术聚会和行业会议，也记不清看过多少技术视频、读过多少篇博客文章。

我做这些事情，始终是为了同一个目标：不断提高自己的开发能力，成为人们口中的“技术大神”“编程忍者”“摇滚明星”，或者一名无所不能的全栈开发者。

很多开发者会把自己视为艺术家，把写出的软件看作某种神圣的创造。为了打磨这些作品，他们依靠近乎英雄主义的意志力持续投入：白天从事专业的软件开发工作，晚上继续参与开源项目，年复一年地磨炼技术。

2012 年，我开始更多地参与工作之外的开发者社区。正是在这个过程中，我逐渐意识到：试图成为一名真正意义上的全栈开发者，可能从一开始就是一场注定无法完成的追逐。

别再执着于“精通全栈”

几年之后，我在软件开发社区中认识了许多才华横溢、谦逊低调的人。他们和我一样重视软件质量，但与他们交流得越多，我就越意识到：

试图成为技术栈每一个层面的专家，往往源于一种不切实际的自我想象。

构建世界一流的软件，是一项复杂、混乱且高度协作的工作。它可能同时涉及后端、前端、用户体验、隐私、安全、无障碍访问、持续集成与持续交付、系统运维等众多领域。

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

人们通常把“全栈开发者”理解为能够独立完成一个应用从前端到后端全部开发工作的人。但这种定义过于简单。

所谓“全栈”，实际上包含多个差异巨大的能力维度。你的技能水平并不是一个单一数值，而是一组高低不同、不断变化的能力组合。

那么，一个人的整体技术水平究竟应该如何衡量？

是取所有能力中最高的一项，因为你具备所谓的 T 型能力结构？还是取最低的一项，因为只有精通所有环节，才有资格称自己为全栈开发者？又或者，应该计算所有能力的平均水平？

无论采用哪一种标准，都能看出，“全栈开发者”这个标签本身就存在问题。

技术能力无法脱离业务场景

如果进一步思考开发软件所需的能力，还必须把具体业务领域纳入考虑。

技术能力从来不会脱离行业场景独立存在。

如果你长期从事电子商务项目，可能会对系统性能、支付流程和用户体验积累深厚认知；如果你负责金融机构的内部系统，你需要掌握的业务知识、合规要求和技术重点则会完全不同。

因此，一个人的技术能力不仅取决于掌握了哪些语言、框架和工具，也取决于他长期服务于怎样的行业，以及解决过哪些具体问题。

脱离业务场景谈论“全栈”，本身就很难得出有意义的结论。

技术技能的有效期十分有限

除此之外，还需要考虑另一个重要维度：时间。

你的技能水平取决于你在某个领域投入了多少时间。但任何人的时间都是有限的，你不可能同时提高所有能力。

因此，在整个职业生涯中，你在不同技术领域的熟练程度必然会不断变化。有些能力会持续增强，有些能力则会因为长期没有使用而逐渐退化。

更重要的是，软件行业变化极快。

今天被认为先进的技术框架、平台和工程实践，几年后就可能过时。而几年时间，不过是整个职业生涯中的一小部分。

这意味着，你几乎不可能真正成为一名所谓的“首席全栈开发者”。

很遗憾，但事实就是如此。

意识到这一点后，我决定把自己的学习重点放在三个要素的交集上：

• 我擅长什么；
• 我真正对什么感兴趣；
• 市场愿意为什么样的能力付费。

对我来说，这意味着努力成为一名优秀的云原生解决方案架构师和开发者，同时保持对前端技术趋势的基本关注，而不是试图精通所有技术领域。

软件开发为什么依赖团队协作

直到 2017 年，我依然没有完全意识到另一个问题：我仍然习惯孤立地看待自己的职责。

现在看来，这个道理似乎再明显不过：

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

大多数项目的规模和复杂程度，都决定了不可能由一个人独立完成全部工作，也不可能由一个人做出所有技术决策。

但我花了很长时间，才真正理解并接受这一点。我相信，我并不是唯一经历过这一过程的开发者。

仅凭个人力量，很难创造出真正卓越的软件。

在软件开发中，你永远会缺少某些重要能力，而这些能力恰恰可能决定产品最终能否达到更高水平。因此，你必须依靠其他人共同完成工作。

与此同时，你的经验越丰富，其他人也越会依赖你，希望你帮助他们发挥出最佳水平。

软件开发是一项团队运动。没有任何人能够独自掌握完成优秀产品所需的一切。

工程团队最难解决的是人的问题

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

我有时甚至希望自己能遇到更多软件问题。

软件问题确实可能非常棘手，但通常总能找到某种解决方法：修复它、绕过它，或者放弃当前方案，换一条路径重新实现。

人际关系问题却完全不同。

真正让我失眠、焦虑和倍感压力的，往往不是程序错误，而是人与人之间的矛盾和冲突。

我们无法强迫别人按照自己的意愿行动，只能努力达成共识，共同解决问题。无论我们多么确信自己的判断是正确的，最终都无法直接改变另一个人。

但作为工程师，我们经常会把处理技术问题的思路错误地套用在人身上。

我们下意识地认为，只要足够耐心、足够缓慢、足够详细地向对方解释他们哪里做错了，问题就会自然消失。

遗憾的是，人并不是可以通过调试修复的软件。

过去，我很少花时间系统学习如何与他人协作、沟通和处理冲突。而且，我相信这并不是我一个人的问题。

开发者通常愿意花钱、花时间学习技术知识，却很少以同样的投入提升沟通和协作能力。

这并不完全是因为雇主没有提供相关培训。事实上，很多企业同样很少为员工提供系统的技术培训。

真正的问题在于，我们自己也没有把沟通能力视为一项值得长期训练的专业技能。

我希望这种情况能够改变。这也是我写下这篇文章的原因。

工程领导者应该从哪里提升沟通能力

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

随着时间推移，我逐渐学会了如何通过社交媒体、协作社区和视频平台发现有价值的技术内容。我知道应该关注什么，也能凭借长期训练形成的模式识别能力，快速判断一项内容是否值得阅读。

但在协作、沟通和领导力方面，我长期缺乏这种“第六感”。

我不知道应该关注哪些概念，也不知道如何判断一套方法是否适合自己。

过去几年，我开始主动探索这一领域，并接触了一些能够帮助人们改善沟通、减少冲突和提升协作效率的沟通框架。

为什么工程团队需要沟通框架

前面提到，人的问题与软件问题截然不同，因此不能简单套用同一套解决原则。

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

面对一件事情，我可能会感到愤怒、受伤、烦躁或羞愧。别人需要为自己的行为负责，而我也需要为自己的情绪、表达方式和下一步行动负责。

我无法改变对方，但可以决定如何理解和回应对方的行为。

尽管人的问题无法像软件一样被精确解决，我们仍然可以借鉴软件开发中的框架思维，采用或扩展一些成熟的沟通方法。

软件框架能够帮助开发者避免反复犯同样的错误，并提供一组经过验证的实践；沟通框架也有类似作用。

它们可以帮助我们更准确地理解信息，更清晰地表达需求，并减少在沟通过程中反复出现的误解与冲突。

以下是我接触过的一些适合工程领导者和工程团队使用的沟通与协作框架。

非暴力沟通

非暴力沟通帮助我识别自己的情绪，并将情绪与客观信息区分开来。

它提供了一套清晰的表达路径：

1. 描述观察到的事实；
2. 识别自己的感受；
3. 理解感受背后的需求；
4. 提出明确而具体的请求。

这种方式能够帮助我们表达感受，而不是直接指责对方。

在实际沟通中，很多信息都会被情绪包裹。表面上听起来像批评、抱怨或攻击的话，背后往往隐藏着尚未被满足的需求。

非暴力沟通提供了一个分析过程，帮助我们剥离情绪化表达，寻找信息背后真正的诉求。

一些海外工程管理从业者也曾讨论，如何将非暴力沟通应用于团队反馈和工程团队中的摩擦处理。这些实践对于减少指责式沟通、提高反馈质量很有价值。

不过，在我的使用过程中，它有时更像一种单向分析工具：我独自分析一段沟通，却未必能与对方共同探讨彼此的表达方式。

因此，它很有帮助，但并不能解决所有问题。

沟通四面模型

沟通四面模型是对非暴力沟通的有益补充。

这个模型认为，一条信息通常同时包含四个层面：

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

发送者可能把这些内容混合在一起，而接收者也可能只注意到其中某一个层面。

例如，一句看似客观的陈述，可能同时表达了发送者的不满、对双方关系的判断，以及希望对方立即采取行动的诉求。

多年前，我在学习传播学课程时第一次接触这一模型。

尤其是在书面沟通中，将一条信息拆分为不同层面，可以帮助我们更准确地理解对方真正想表达什么，也能避免因为过度关注某个词语或语气，而忽略信息背后的真实意图。

五种爱的语言

“五种爱的语言”最初用于解释亲密关系，但其中关于“人们以不同方式感受到认可”的观点，同样适用于职场协作和工程团队管理。

大多数人工作都不仅仅是为了获得薪酬。他们也希望自己的努力被看到、被认可，并感受到自身贡献具有价值。

但不同的人感受到认可的方式并不相同。

有人重视直接的语言肯定，有人更看重实质性的支持；有人希望获得高质量的陪伴和关注，也有人更在意具体的行动或具有象征意义的表达。

作为工程领导者或团队合作者，理解一个人的动力来源，以及什么样的反馈能够让他真正感受到自己的工作被重视，非常重要。

其中最值得记住的一点是：

对方希望获得认可的方式，很可能与你希望获得认可的方式完全不同。

因此，你需要有意识地使用对方能够理解和接受的方式，表达肯定、尊重与感谢，而不是只采用自己习惯的方式。

核心协议

几年前，我花时间阅读了《核心协议》。

这套方法试图通过一组高度明确的规则，规范团队成员之间的互动方式。它对沟通问题的描述非常直接，也提出了清晰的处理机制。

不过，在我看来，这套方法相对僵硬。

它可能适合某些高度自律、愿意严格遵守共同规则的团队，但对于许多真实组织而言，执行成本很高。

在缺乏足够信任和心理安全感的情况下，过度结构化的互动规则甚至可能产生一种令人不适的“恐怖谷效应”：

所有人的表达看似规范，却显得机械、拘谨，甚至缺乏人情味。

根据我参与组织辅导的经验，这类系统并不一定适合需要渐进式改变的多元化团队。

一方面，很难向尚未接触过这套方法的人解释为什么必须这样沟通；另一方面，严格执行这些规则，也可能让团队成员感到自己受到过度控制。

尽管如此，这本书仍然是一份很有价值的参考资料，因为它非常明确地揭示了沟通中常见的问题，并提出了一套完整的应对思路。

结构化 RFC 流程

一些海外工程实践者曾提出结构化的 RFC 流程，用于改善工程团队在技术讨论和决策环节中的沟通质量。

这类方法的价值在于，它们不仅关注技术方案本身，还会明确：

• 谁参与讨论；
• 讨论需要回答哪些问题；
• 采用什么标准做出判断；
• 谁拥有最终决策权；
• 反对意见如何被记录和回应。

决策是工程团队冲突最常见的来源之一，也是组织权力关系最容易暴露的时刻。

当决策流程模糊时，团队成员很容易陷入无休止的争论：

谁有权决定？哪些意见应该被采纳？反对意见是否得到了充分回应？最终结果是通过共识形成，还是由负责人拍板？

结构化 RFC 流程能够让这些隐性规则变得更加透明，从而减少因为权力不清、责任不明和流程模糊造成的冲突。对于规模较大的研发团队，还可以借助 PingCode 这类研发管理工具，把需求背景、方案评审、任务执行、测试发布和最终决策串联起来，并通过 Wiki 沉淀讨论依据和决策记录，避免重要信息长期散落在会议和即时消息中。

领导力阶梯

“领导力阶梯”是一个非常有力量的沟通与授权模型。

它描述了团队成员在决策过程中可以拥有的不同自主程度。

一个人可能处于以下不同阶段：

• 等待指令；
• 询问应该做什么；
• 提出可选方案；
• 给出自己的建议；
• 表达自己准备采取的行动；
• 在职责范围内自主行动；
• 完成行动后同步结果。

这个模型的精妙之处在于，它为不同程度的自主权提供了明确的语言。

团队不再只是模糊地讨论“你能不能更主动一点”或者“这件事情你自己决定”，而是可以清楚说明：

你现在处于哪一个决策层级？下一步需要具备什么能力，才能获得更大的自主空间？

这使围绕决策和授权的隐性规则变得透明，也为团队成员逐步承担更大责任提供了一条清晰路径。

在具体执行中，管理者还需要把这种授权关系落实到目标、任务、负责人和协作节奏中。借助 Worktile 这类通用项目协作工具，团队可以将目标、任务、文档、日历和项目进度放在统一空间中，让每个人都清楚自己拥有怎样的决策权、需要承担什么责任，以及何时应该主动同步进展。

它既能避免管理者过度干预，也能防止团队成员在缺少必要信息和能力时被突然推向完全自主。

工程领导者为什么要长期训练沟通能力

我对沟通、协作和领导力的探索才刚刚开始，却已经积累了足够我学习很多年的材料。

我也建议你在参加开发者社区或开放讨论活动时，发起一场关于沟通与协作的讨论。

这不仅能够帮助更多人开始关注这个话题，也能让你收集其他人正在使用的工具、框架和学习资源。

我曾在一次海外开发者社区活动中组织过类似讨论。那次交流为我带来了一份很有价值的书单，其中包括：

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

这些书不会让人一夜之间成为沟通专家，却能够帮助我们建立一套新的观察视角：

如何理解冲突，如何提出问题，如何表达不同意见，以及如何帮助他人找到自己的答案。

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

我希望这篇文章能够促使你投入更多时间，提升那些真正决定长期职业发展的能力。

技术能力当然重要。

但随着经验增长，你所创造的价值将越来越少地来自“自己能够写多少代码”，而越来越多地取决于以下问题：

你能否帮助团队做出更好的决策？

你能否在冲突中保持清晰和尊重？

你能否让不同背景、不同专业能力的人有效合作？

你能否让团队成员感受到自己被重视、被倾听和被理解？

你的沟通方式和处理冲突的能力，会深刻影响你本人和整个团队的工作状态。

它们决定了团队能否建立一个真正安全的工作环境：人们可以坦率表达担忧，提出不同意见，指出潜在问题，甚至提出那些尚不成熟、却可能带来创新的想法。

对于工程领导者来说，沟通能力和冲突处理能力不是技术能力之外的附加项。

它们本身，就是领导力。