工程领导力：如何用沟通框架提升团队协作与沟通能力

对于工程师和技术管理者来说，除了技术能力，沟通、团队协作和冲突处理能力同样决定着领导力的上限。

作为工程师，我们往往会优先提升技术能力。但为什么沟通能力同样值得投入时间，甚至会随着职业发展变得越来越重要？

对于高级工程师、技术负责人和工程管理者来说，工作早已不只是解决技术问题。如何与团队沟通、推动协作、处理分歧并帮助他人做出更好的决策，往往同样影响着项目和团队的最终表现。

从 1997 年开始，我就一直以软件开发为生。这些年来，我已经数不清参加过多少场技术聚会和会议、看过多少视频、读过多少篇博客文章。

无论是作为参与者还是分享者，我做这些事情似乎都只有一个目标：

不断提升自己的开发能力，努力成为所谓的“互联网大神”“忍者”“摇滚明星”，或者全栈开发者。

很多开发者甚至会把自己视为艺术家，把代码看作某种神圣的作品。这些作品似乎来自个人超凡的意志力，而这种能力需要多年磨炼才能获得：白天做一名领取薪水的软件工程师，晚上继续参与开源项目。

但后来，我逐渐意识到，这种想法本身可能就有问题。

别再执着于成为“全栈开发者”

2012 年，我开始更多地参与工作之外的技术社区，也逐渐意识到：一味追求成为所谓的“全栈开发者”，很可能是一场徒劳的竞赛。

几年后，在结识了许多优秀而谦逊、同样重视软件质量的开发者之后，我越来越确信：

试图成为整个技术栈所有领域的专家，本身就是一种不现实的期待。

构建世界一流的软件，本来就是一个复杂、甚至有些混乱的过程。

一款真正成熟的软件产品，往往需要同时涉及：

• 后端开发；
• 前端开发；
• 用户体验；
• 隐私与安全；
• 可访问性；
• 持续集成与持续交付；
• 运维；
• 性能；
• 数据；
• 以及更多专业领域。

这些领域中的任何一个，都足以成为一个人长期深入钻研的方向。

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

人们常常把“全栈开发者”理解为能够独立完成一款应用从头到尾所有开发工作的工程师。

但这种定义本身就过于简单。

现实中，我们在不同技术领域的能力从来都不是一个统一的数值，而是一组有高有低、并且会随着职业发展不断变化的技能。

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

是取所有领域中能力最强的那一项？

如果是这样，只要拥有典型的 T 型技能结构，就可以称自己为全栈开发者。

还是应该看最弱的那一项？

如果这样定义，那就意味着必须精通所有领域，才能称自己为全栈开发者。

或者，我们应该取所有能力的平均水平？

只要稍微深入思考，就会发现：“全栈开发者”这个标签本身就很难给出一个真正可靠的定义。

而且，事情还不止于此。

工程师的技术能力离不开具体业务场景

如果进一步思考软件开发究竟需要哪些能力，就会发现，除了技术栈之外，还有一个经常被忽略的维度：

业务领域。

你的技术能力始终与所在行业和业务场景密切相关。

如果你长期从事电子商务项目，你可能会积累大量关于性能、支付系统、转化流程和用户体验方面的知识。

如果你主要开发金融机构的内部系统，那么你擅长的领域很可能完全不同。

换句话说，一个工程师的能力，并不能脱离具体的业务场景来讨论。

而且，还有第四个非常重要的维度：

时间。

技术技能的保质期比你想象得短

你的能力取决于你在某个领域投入了多少时间。

但一个人的时间是有限的。

当你把精力投入某项技能时，就意味着无法把同样的时间投入另一项技能。因此，在整个职业生涯中，你所谓的“全栈能力”必然会不断起伏变化。

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

今天炙手可热的框架、工具和实践，几年之后就可能被新的技术取代。

于是，一个略显尴尬的事实出现了：

很多技术技能的有效期，也许只有几年。

而几年，只是整个职业生涯中的一小段时间。

这意味着，从严格意义上来说，你几乎不可能真正成为所谓的“首席全栈开发者”。

抱歉。

意识到这一点之后，我开始重新思考自己的学习方向。

与其什么都学，不如把有限的时间投入几个真正值得长期发展的交叉领域：

我擅长什么、我对什么感兴趣，以及哪些能力真正具有职业价值。

对我而言，这意味着更加深入地发展云原生解决方案架构和开发能力，同时保持对前端技术发展的基本了解。

但当时的我仍然忽略了一个更加重要的问题。

软件开发是一项团队协作

现在看来，这件事情似乎显而易见：

软件开发是一项团队运动。

绝大多数真实项目的规模和复杂度，都决定了任何一个人不可能独自做出所有技术决策。

但我花了相当长的时间，才真正意识到这一点。

而我相信，我并不是唯一经历过这个过程的开发者。

单凭个人能力，很难创造真正卓越的软件。

你永远会缺少某些重要能力，因此必须依靠其他人，才能共同完成最好的作品。

而且，你的经验越丰富，别人也会越依赖你，帮助他们发挥出最好的水平。

这意味着，当一个工程师逐渐走向高级工程师、技术负责人或者工程领导者的位置时，真正重要的问题已经不只是：

“我的代码写得够不够好？”

还包括：

“我能不能和别人一起把事情做好？”

工程领导者真正棘手的，往往不是技术问题

如果让我把职业生涯中遇到的问题分成两类——“人的问题”和“软件的问题”——那么真正让我觉得困难的，几乎总是前者。

事实上，我甚至希望自己能遇到更多纯粹的软件问题。

因为软件问题虽然有时非常困难，但通常总能找到某种解决办法：

修复它；

绕过它；

重构它；

或者干脆放弃原来的方案，换一种实现方式。

但人与人之间的问题完全不同。

真正让我夜不能寐、压力倍增的，往往是那些人际关系和沟通问题。

因为你无法像修改程序一样“修改”另一个人。

你不能强迫别人按照你的意愿行动。

你所能做的，是努力沟通、寻找共识，与对方一起解决问题。

至于对方最终如何选择，你无法控制。

但工程师很容易犯一个非常典型的错误：

把解决软件问题的方法，也用在人身上。

我们下意识地认为，只要足够耐心、足够详细地向别人解释：

“你这里错了，正确答案应该是这样。”

问题自然就会消失。

现实显然没有这么简单。

回头看，我过去花了大量时间学习技术，却很少真正花时间学习如何协作、如何沟通，以及如何处理冲突。

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

我们很愿意花钱、花时间去参加技术培训、阅读技术书籍、观看课程。

但说到沟通、协作和领导力，我们投入的时间通常少得可怜。

这并不是因为公司一定会替我们提供这些训练——事实上，很多公司连系统的技术培训都未必提供。

更重要的原因可能是，在我们的潜意识里，技术能力一直被视为一种“真正的专业能力”，而沟通能力则容易被归入某种模糊的“软技能”。

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

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

工程师如何提升沟通能力？

技术行业从来不缺学习资源。

技术社区、博客、聚会、会议、视频、课程……几乎随处可见。

随着时间推移，我也培养出了一种快速发现技术内容的直觉。

浏览各种社区、社交平台或视频网站时，我很清楚自己应该关注什么。多年积累下来的模式识别能力，让我几乎可以瞬间判断：

“这个东西值得看看。”

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

我甚至不知道自己应该搜索什么。

过去几年里，我开始有意识地补上这一课。其中一个重要方法，就是学习各种已有的沟通框架。

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

前面说过，人的问题和软件问题不同，因此不能直接套用解决软件问题的方法。

但这并不意味着沟通完全没有规律可循。

有一件事尤其重要：

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

当一件事情发生时，我可能会生气、受伤、恼怒或者羞愧。但这些感受，以及我最终如何处理它们，仍然是我自己的责任。

在这一点上，我们其实可以借鉴软件开发中的思路：

既然开发软件时可以使用框架，为什么沟通不能？

一个好的软件框架，可以帮助我们避免反复解决同样的问题，同时沉淀最佳实践。

沟通框架也是如此。

它们无法消除人与人之间的差异，却能帮助我们减少一些反复出现的沟通错误，并提供一套可以参考的方法。

最终目标很简单：

减少沟通中的冲突，让人与人之间的协作更加顺畅。

下面是一些曾经对我有所帮助的沟通框架和方法。

非暴力沟通

非暴力沟通（Nonviolent Communication，NVC）帮助我学会识别自己的情绪，并把事实、感受和判断区分开来。

它还提供了一种非常实用的表达方式：

清楚说明自己的感受和需要，而不是直接指责对方。

很多沟通中的真正信息，其实都包裹在情绪之中。

当一个人愤怒地表达观点时，我们很容易只注意到他的愤怒，却忽略愤怒背后真正想传递的信息。

非暴力沟通提供了一套拆解沟通内容的方法，帮助我们穿过情绪，找到背后的事实、感受、需要和请求。

当然，它也有局限。

很多时候，这仍然是由我自己完成的分析过程，而不是双方共同分析彼此的沟通方式。

尽管如此，它依然是理解和减少团队冲突非常有价值的工具。

海外一些工程管理实践者，也曾分享如何把类似的反馈方法运用到工程团队摩擦和日常职场沟通中。

沟通四面模型

另一个很有价值的框架，是沟通四面模型。

它可以看作对前面方法的一种补充。

这个模型认为，一条信息往往并不只有一个层面的含义，而是同时包含多个维度。

例如，当一个人说出一句话时，其中可能同时包含：

事实信息；

关于自己的信息；

对双方关系的暗示；

以及希望对方做什么。

信息发送者可能无意中把这些内容混在一起，而接收者又可能只听到了其中某一个层面。

于是，误解就出现了。

我很早就在专业学习中接触过这个模型。尤其是在书面沟通中，尝试识别一段话中包含的不同层次，可以帮助我们更准确地理解对方真正想表达什么。

五种爱的语言

“五种爱的语言”原本主要用于亲密关系，但其中有一个观点，对团队协作同样很有启发：

不同的人，感受到“被认可”的方式并不相同。

大多数人在工作中，都希望自己的贡献能够得到某种形式的认可。

但问题是：

你表达认可的方式，未必就是对方真正能够感受到认可的方式。

有些人希望得到公开表扬；

有人更看重直接而具体的反馈；

有人更重视实际帮助；

也有人最在意别人愿意投入时间认真倾听。

作为管理者或者团队合作者，了解一个人的驱动力，以及什么样的表达方式能让对方真正感受到自己的工作受到重视，非常重要。

这里最值得记住的一点是：

别人希望得到认可的方式，很可能与你完全不同。

因此，表达感谢和肯定，也需要站在对方的角度。

核心协议

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

它对团队互动进行了非常明确、甚至相当严格的规范。

这样的结构对某些人可能非常有效，但根据我的经验，它对参与者的自律程度要求很高。

如果执行得过于机械，很容易让一些人产生一种不自然的感觉——仿佛人与人之间的互动被流程控制得过了头。

在实际组织辅导中，我发现这种高度结构化的方法，并不一定适合那些需要渐进式改变、成员背景又非常多元的团队。

对于没有接触过这套方法的人来说，相关做法也不太容易解释。

有时候，它甚至会让正常的人际互动显得不够自然，甚至缺少一些人情味。

尽管如此，这套方法依然值得研究，因为它非常明确地指出了许多沟通中的典型问题，并尝试给出系统性的应对方式。

结构化 RFC 流程

另一种很值得工程团队借鉴的方法，是结构化 RFC（Request for Comments，征求意见）流程。

RFC 的重点并不只是“写一份文档”。

它更重要的价值，是把讨论和决策过程显性化。

这尤其重要，因为在工程团队中，决策往往正是冲突最容易发生的地方。

谁拥有决定权？

谁应该参与讨论？

谁的意见必须被考虑？

讨论什么时候结束？

如果无法达成一致，最终由谁拍板？

这些问题背后，其实都隐藏着团队中的权力关系和决策机制。

如果规则始终是隐性的，团队就很容易陷入无休止的讨论和摩擦。

结构化的 RFC 流程，可以帮助团队提前明确：

谁提出方案；

谁提供反馈；

讨论持续到什么时候；

谁负责最终决策；

以及决策结果如何记录。

因此，它不仅是一种技术设计方法，也是一种非常有效的团队沟通机制。

如果团队希望让这些讨论、评审和决策真正沉淀下来，而不是散落在聊天记录和个人文档中，也可以借助 PingCode 这类研发管理工具，把需求、研发过程与 Wiki 知识沉淀连接起来，让 RFC、技术方案和关键决策拥有统一的上下文，方便后续追踪和复用。

领导力阶梯

另一个给我很大启发的概念是领导力阶梯。

它试图回答团队中一个非常重要的问题：

到底谁可以做决定？

传统的管理方式经常在两个极端之间摆动。

一个极端是员工问：

“我应该怎么办？”

然后管理者直接给出答案。

另一个极端则是管理者说：

“你自己决定。”

但真正成熟的授权，往往发生在这两个极端之间。

一个人的表达方式可能经历这样的变化：

“告诉我该怎么做。”

“我看到了几个可选方案。”

“我建议我们这样做。”

“我准备这样做，除非你有不同意见。”

“我已经这样做了，结果如下。”

随着团队成员的能力提升，他们可以逐渐沿着这个“阶梯”向上移动。

这种方法最有价值的地方在于：

它把团队中原本隐性的决策权限，变成了明确的沟通规则。

管理者可以更清楚地知道，什么时候应该直接提供答案，什么时候应该给予建议，以及什么时候应该真正放手。

团队成员也会越来越清楚：

“这件事，我究竟能不能自己决定？”

这正是培养团队自主性非常重要的一步。

沟通能力值得像技术能力一样学习

我才刚开始认真探索这个领域，就已经发现了足够学习很多年的内容。

而且，最有效的方法之一，就是主动与其他人讨论这个话题。

你甚至可以在公司内部、技术社区或者开放讨论活动中发起一场讨论：

“为了提升协作和沟通能力，你学习过哪些方法？”

这不仅能够让更多人开始关注这个话题，也能帮助你收集来自其他人的资源和经验。

对于日常团队协作而言，沟通能力也需要有合适的工作方式来承载。例如使用 Worktile 这样的项目协作工具，将任务、项目、文档、目标和团队沟通放在统一的协作环境中，可以减少信息散落带来的误解，让团队成员更容易围绕同一份上下文展开讨论。

在类似的交流中，我也陆续发现了一些很有价值的书，例如：

《关键对话》（Crucial Conversations）、《化敌为友》（Adversaries into Allies）以及《教练的习惯》（The Coaching Habit）。

这些资源关注的并不是新的编程语言，也不是最新的框架。

它们关注的是人与人之间最基本、却也最困难的问题：

如何对话；

如何产生影响；

如何提供反馈；

如何处理冲突；

如何帮助别人成长。

而这些能力，会随着你的职业发展变得越来越重要。

工程领导力的核心：沟通、协作与冲突处理

我希望这篇文章能够让你愿意投入更多时间，去提升这些真正重要的能力。

随着工程师经验增加，技术能力当然依然重要。

但越来越多时候，真正决定你和团队能否成功的，并不是你是否又掌握了一个新的框架，而是：

你如何与人沟通，以及如何处理冲突。

这些能力会直接影响你自己和团队成员的工作体验。

它们决定了你能否创造一个这样的环境：

员工感到自己的贡献受到重视；

他们觉得自己的声音能够被听见；

他们知道自己的观点会被认真理解；

他们能够安全地表达担忧；

能够提出批评意见；

也敢于提出那些还不成熟、甚至有些大胆的创新想法。

归根结底，技术领导力从来不只是“拥有更多技术知识”。

真正优秀的工程领导者，需要让自己和周围的人都能够发挥出最佳水平。

正如一位工程从业者曾总结的那样：

如果过度关注技术，你最终可能拥有资深工程师的技术能力，却仍然只有初级员工处理人与协作问题的经验。

真正成熟的工程师，不只是更会解决技术问题。

也更懂得如何与人一起解决问题。