科技行业“软技能”愈加重要，靠“硬技能”吃饭的你焦虑吗？

编者按：软技能又称非技术技能，与求职者在某专业领域从事工作、进行研究而应当具备必要的“硬技能”相对，主要是指调动别人的资源和知识的能力以及调动自己知识进行创造性思维的能力。软技能在各个领域的重要性越来越高，而对这一趋势，硬技能人群也流露出了焦虑的情绪。本文作者 Yonatan Zunger 观察了科技圈内技术专业人群的这一焦虑心理，对这一心理背后的深层原因进行了分析，并就如何解决这种焦虑情绪进行了探讨。

最近，我看到来自科技圈很多人的回复都透露出十分焦虑的情绪，他们担心自己的“核心技能”可能会贬值，尤其是如果他们不具备的那些技能备受青睐，那这种焦虑的情绪就更加强烈。最重要的是，在关于“硬技能”与“软技能”的话题讨论中，这种焦虑的情绪愈发显现出来，而这可能是因为我们并没有认真地看待软技能。所以今天，我想分享一下我自己对于当下的所思所想，探讨一下我们该采取什么措施去解决这一焦虑问题。

1、一些观察数据

据我观察，要想在网络上看到这种焦虑性反应，最稳妥的方式之一就是暗示软技能对工程师的重要性可能会超越硬技能。关于“焦虑性反应”，我并不是指“意见分歧”，而是特指一种“情绪宣泄下的分歧”，情绪宣泄是一个非常重要的数据点。

我对很多情况进行过观察，发现了一个非常可靠的模式，那就是人们对一个观点所流露出的情绪反应强度可以告诉你这一观点中的内容与他们最担心的事情有多接近。这样说出来似乎很显而易见，但如果你把它作为一种检测方法来使用，那效果非常强大：强烈的反应可以让你了解对于这个人来说，真正的问题、真正的威胁所在。（这是我从心理学，尤其是心理治疗中学到的一个诀窍，根据情绪反应来找出对于治疗对象来说，最突出的事件和问题。根据经验来看，谈论某件事情的难度越大，这件事情可能就越重要。）

这种情况下有趣的一点在于，人们非常关心得是软技能和硬技能的相对价值，而不是整体的经济波动或工程师的过度供应问题，这两个方面明明也很容易威胁到工程师的地位。

我们可以将这种强烈情绪反应的频率看作是一种隐秘的群体智慧信号。在文化问题上，群体智慧信号效果更好，因为文化就是由这些人来组成的。通过对过去几年的对话和回应模式进行浏览，其中回应的焦虑程度展现出了一种模式：很多人都有这样一个直觉，软技能的重要性将日益渐长，但他们也害怕，不知道这对于他们而言究竟意味着什么。

2、深层原因

软技能的地位将越来越高，这并没有什么可惊讶的。“厉害但脾气暴躁的独行者”会越来越少，原因在于现在几乎没有什么技术是一个人就可以完成的。我之前的工作很大一部分内容就在于让数百人，有时甚至是数千人建立起一种共识并且保持这一共识，从而朝着一个方向前进。这是一件非常困难的事情，正如我们领域的大多数人所想的一样，这与我之前掌握的技能相差甚远，我们感觉到自己在硬撑，在假装，并且希望没人会发现。

当你和一大批人一起工作的时候，交流和协作的复杂性很快就会成为决定成功或失败的主要因素。像“心理安全感”和“相互信任”这样的概念会成为主导你日常工作的最重要的因素，远远超过任何的技术挑战。在初级职位阶段，之所以会这样是因为它会影响到你的生活质量：一方面要努力做好技术工作，一方面周围可能都是讨厌你的人，这非常困难，也非常可怕。到高级职位层次时，交流和协作会越来越成为需要你去创造并且管理的一个责任方面。这一差别与初级和高级职位之间的深层差异密切相关：初级职位工作人员的任务是找到问题的答案，而高级职位工作人员的工作就是找到正确的问题。一旦你通过一定的门槛，需要特定层次技术水平才能解决的纯粹技术性问题会大大减少，而无论是可靠的编译程序还是 Stack Exchange 这样的问答网站越来越普遍，这也就意味着越来越多的硬技术问题很容易就能找到答案。

当然，总是存在各种困难的问题，这些问题可能非常重要，但没什么经验的人无论如何也解决不了。也正是因为如此，我们才需要继续发展我们的专业技能。但是，如果你继续发展你的技能，你很快就会发现，为解决这些及其困难的技术问题而花费的时间往往比一份全职工作的时间要少得多，影响系统的关键（并且也是很难的）问题在很大程度上取决于这个系统与外部世界（越来越多的人）的交互方式。

有趣的是，硬技能和软技能之间的交集比许多人意识到的还要多：当你开始将你的系统看作是包括人类元素在内的一个更大系统的组成部分时，你会开始好奇人类之间如何交互，以及他们的行为怎样这些问题，然后你会发现许多相同的“硬技能”系统设计方法有他们的道理所在，并且也能为传统意义上纯粹的“软技能”问题提供更好的答案。防止多用户系统滥用以及各种结果的排名就是两个典型的例子；在这两种情况下，既有对于用户需求一种非常“软”的直觉，同时对于这些直觉又有非常“硬”的技术表达，在两种技能之间自由转换的能力是无价之宝。

除了这些技术工作本身需要软、硬技能重叠的情况之外，现在所需的很多“软技能”其实与人事管理有很大的关系。工程师群体之前在人事管理领域一直代表性很差，因为历史上人事管理工作一直是由那些没有工程技能的人来从事，而且关键的一点在于，这些人可能缺乏对上述技能以及拥有这些技能的人群的尊重。这是因为，很多的管理层是从 20 世纪初的工业管理层演变而来，也就是工业管理领域提出了“人力资源”这样的词汇：他们将工人们看作是一种烦恼、一种消耗，是一个必须要通过“管理”来保持高产量工作的群体。

这种所谓的“管理”其实很糟糕，它其实就是由这样一些人所创建起的一个领域，这些人往往认为自己有很好的软技能，但现实是他们的软技能非常糟糕，甚至有些病态。如果员工觉得自己的上级管理者并不尊重自己，那这本身就是一个很严重的危险信号：毕竟，一名管理者的基本工作就是协调不同的员工，让他们作为一个团队来工作，所以如果他们自己都做不到互相尊重，那他们不可能在员工中创造出这样的氛围。

事实上，我们现在所探讨的“软技能”并不是任何人轻而易举就能获取到的技能，不是我们在“礼仪课程”中能学到的东西。这些“软技能”来自于对人的研究，需要去关注他们，在他们自己都表达不出自己需求的时候你却能理解他们的需求，这些技能的获取非常困难，与任何专业技能的获取一样困难。如果我们还是按照之前的习惯去对待这些技能，认为它们并不是“真正的”技能，认为它们无法与专业技能相提并论或者是贬低它们，那对我们没什么好处。当需要我们发挥这样的软技能去处理工作的时候，你就会发现它们绝对不是微不足道的地位。

（我想起了一件事，我认识的某位工程师将团队搬到了一个新的办公楼，并表示：室内建筑装修应该很容易，他自己就是工程师，不需要再找别人来做这件事，结果可想而知。这让人感觉很有意思，工程师、科学家和管理人员似乎都倾向于认为别人的专业技能应该很容易。）

3、好消息：总有办法

我认为有一个非常“简单”的方法可以来改善这一状况，那就是开始将这些软技能像“正儿八经”的专业技能一样对待，重视这些技能，并且为这些技能提供培训，聘请有这样技能的新员工，就像我们对待其他关键性技能一样。

一个好的开端能够确保我们拥有并共享一种语言，如果你都说不上来某样东西的名字，那就很难让人去重视这样东西。我们经常忽略的一些常见任务是“让每人都能立刻看到项目内部的进展情况，”“为核心技术理念创建一种共享语言，让每个人都能对相同的一件事情做出解释，”“确保每个人的声音都能被听到，并且确保不会错过重要的提醒（害怕说出），”并且“确保所有的利益相关者对项目都有一种个人所有的感觉，感受到自己的成功与项目的成功息息相关。”我们经常忽略的一些常见的措施是“用户/客户在使用本产品的过程中出现沮丧或是负面情绪的频率有多高？这对他们的长期使用有什么影响？”或者是“当用户在使用该产品时有一次负面体验，那接下来每个时间段（从 10 分钟到一周）他们的体验怎样呢？这会如何影响他们对于该产品的体验呢？”

其实这些都涉及到不同的专业技能，从项目管理到用户体验研究。但是，如果一个团队，将这些看作是不相干的问题，并不认为是决定自己成败的核心问题，那他们很可能会陷入一场灾难：错过里程碑；不同团队创建起的系统存在些许不同，在最终整合时期只会产生冲突；关键的问题没有得到及时解决；一个项目被隐晦地破坏掉，只是因为一个团队不想让它成功；用户遇到一个小 bug，最终演变成一场大的灾难（用户大批流失或是惹上法律、监管的麻烦）；用户的信任被缓慢地侵蚀掉。我见过因为上述任何一个原因而失败的项目，即便是那些纯粹“技术性”工程工作无可指摘的项目也摆脱不了上述原因的影响。

要想将这些看作是核心问题，而不是外围、无关紧要的问题，就要求团队每个人都对这些问题有基本的了解，即便他们不是这一问题的直接负责人，也能评估这些问题的影响。然后将这些问题与团队不同职位角色相配对，看一下是属于前端工程、后端工程、安全问题还是网站可靠性问题。一位工程师无法单独完成这所有的工作其实很正常。事实上，如果任何一个人能够自己完成这所有的工作，那真的会让人感觉不可思议。但是如果我们将这些工作中的一部分看作是“无形的劳动”，也就是需要用我们假装不存在的技能去解决的那些不被看重、“上不了什么台面”的劳动，那我们绝对是在搬起石头砸自己的脚。

本文开篇所提到的焦虑就是一个症状，因为我们都知道有些东西缺失的很严重，并且这些缺失的东西正变得越来越重要。如果我们将这些缺失的东西看作是“并非真正的技能”，是有些人自然而然就会而工程师不会的技能，那这会变得很可怕，因为听上去就像工程师会被路人甲随意碾压，谁也不会尊重工程师一样。但是，如果我们意识到这是一种真正的技能，是人们在生活过程中勤加练习才会擅长的技能，那我们对此就会有不同的态度。很多擅长这些软技能的人可能不是来自于工程界，但这是因为工程界过去几十年来对工程人员这方面的培训工作做得比较失败，并不意味着这些人就毫不了解工程界，或者说毫不尊重工程师。

有一点需要提醒，如果这个岗位工作涉及到协调工程师，或者是将工程系统连接到用户，也或者是其他任何不尊重工程师就做不好的工作，那你不应该雇用不尊重工程师的人。“这个人会让整个团队感到痛苦”，这是一个危险信号。

但同时：项目中的每个人都需要重视并且了解项目中最基本的一些问题。如果系统中有一个法律相关的问题，那每个人都需要了解这一法律条文要求。如果有用户研究显示用户对某个方面反馈较好或者较差，那每个人在设计的时候都需要考虑到这一点，或发扬或规避。同理，每个人都需要了解和重视人的技能：毕竟，你正在创建的这个系统至少是包括你在内的。

原文链接：https://shift.newco.co/hard-and-soft-skills-in-tech-8be00216f67f

编译组出品。编辑：郝鹏程