編者按：軟技能又稱非技術技能， 與求職者在某專業領域從事工作、進行研究而應當具備必要的“硬技能”相對， 主要是指調動別人的資源和知識的能力以及調動自己知識進行創造性思維的能力。 軟技能在各個領域的重要性越來越高， 而對這一趨勢， 硬技能人群也流露出了焦慮的情緒。 本文作者 Yonatan Zunger 觀察了科技圈內技術專業人群的這一焦慮心理， 對這一心理背後的深層原因進行了分析， 並就如何解決這種焦慮情緒進行了探討。
最近， 我看到來自科技圈很多人的回復都透露出十分焦慮的情緒，
1、一些觀察資料
據我觀察， 要想在網路上看到這種焦慮性反應， 最穩妥的方式之一就是暗示軟技能對工程師的重要性可能會超越硬技能。 關於“焦慮性反應”， 我並不是指“意見分歧”， 而是特指一種“情緒宣洩下的分歧”， 情緒宣洩是一個非常重要的資料點。
我對很多情況進行過觀察，
這種情況下有趣的一點在於， 人們非常關心得是軟技能和硬技能的相對價值， 而不是整體的經濟波動或工程師的過度供應問題，
我們可以將這種強烈情緒反應的頻率看作是一種隱秘的群體智慧信號。 在文化問題上， 群體智慧信號效果更好， 因為文化就是由這些人來組成的。 通過對過去幾年的對話和回應模式進行流覽， 其中回應的焦慮程度展現出了一種模式：很多人都有這樣一個直覺， 軟技能的重要性將日益漸長， 但他們也害怕， 不知道這對於他們而言究竟意味著什麼。
2、深層原因
軟技能的地位將越來越高， 這並沒有什麼可驚訝的。 “厲害但脾氣暴躁的獨行者”會越來越少， 原因在於現在幾乎沒有什麼技術是一個人就可以完成的。 我之前的工作很大一部分內容就在於讓數百人， 有時甚至是數千人建立起一種共識並且保持這一共識， 從而朝著一個方向前進。 這是一件非常困難的事情， 正如我們領域的大多數人所想的一樣， 這與我之前掌握的技能相差甚遠， 我們感覺到自己在硬撐， 在假裝， 並且希望沒人會發現。
當你和一大批人一起工作的時候， 交流和協作的複雜性很快就會成為決定成功或失敗的主要因素。 像“心理安全感”和“相互信任”這樣的概念會成為主導你日常工作的最重要的因素， 遠遠超過任何的技術挑戰。 在初級職位階段， 之所以會這樣是因為它會影響到你的生活品質：一方面要努力做好技術工作， 一方面周圍可能都是討厭你的人， 這非常困難， 也非常可怕。 到高級職位層次時， 交流和協作會越來越成為需要你去創造並且管理的一個責任方面。 這一差別與初級和高級職位之間的深層差異密切相關：初級職位工作人員的任務是找到問題的答案， 而高級職位工作人員的工作就是找到正確的問題。 一旦你通過一定的門檻，需要特定層次技術水準才能解決的純粹技術性問題會大大減少，而無論是可靠的編譯器還是 Stack Exchange 這樣的問答網站越來越普遍，這也就意味著越來越多的硬技術問題很容易就能找到答案。
當然，總是存在各種困難的問題，這些問題可能非常重要，但沒什麼經驗的人無論如何也解決不了。也正是因為如此，我們才需要繼續發展我們的專業技能。但是，如果你繼續發展你的技能，你很快就會發現，為解決這些及其困難的技術問題而花費的時間往往比一份全職工作的時間要少得多，影響系統的關鍵（並且也是很難的）問題在很大程度上取決於這個系統與外部世界（越來越多的人）的對話模式。
有趣的是，硬技能和軟技能之間的交集比許多人意識到的還要多：當你開始將你的系統看作是包括人類元素在內的一個更大系統的組成部分時，你會開始好奇人類之間如何交互，以及他們的行為怎樣這些問題，然後你會發現許多相同的“硬技能”系統設計方法有他們的道理所在，並且也能為傳統意義上純粹的“軟技能”問題提供更好的答案。防止多使用者系統濫用以及各種結果的排名就是兩個典型的例子；在這兩種情況下，既有對於使用者需求一種非常“軟”的直覺，同時對於這些直覺又有非常“硬”的技術表達，在兩種技能之間自由轉換的能力是無價之寶。
除了這些技術工作本身需要軟、硬技能重疊的情況之外，現在所需的很多“軟技能”其實與人事管理有很大的關係。工程師群體之前在人事管理領域一直代表性很差，因為歷史上人事管理工作一直是由那些沒有工程技能的人來從事，而且關鍵的一點在於，這些人可能缺乏對上述技能以及擁有這些技能的人群的尊重。這是因為，很多的管理層是從 20 世紀初的工業管理層演變而來，也就是工業管理領域提出了“人力資源”這樣的詞彙：他們將工人們看作是一種煩惱、一種消耗，是一個必須要通過“管理”來保持高產量工作的群體。
這種所謂的“管理”其實很糟糕，它其實就是由這樣一些人所創建起的一個領域，這些人往往認為自己有很好的軟技能，但現實是他們的軟技能非常糟糕，甚至有些病態。如果員工覺得自己的上級管理者並不尊重自己，那這本身就是一個很嚴重的危險信號：畢竟，一名管理者的基本工作就是協調不同的員工，讓他們作為一個團隊來工作，所以如果他們自己都做不到互相尊重，那他們不可能在員工中創造出這樣的氛圍。
事實上，我們現在所探討的“軟技能”並不是任何人輕而易舉就能獲取到的技能，不是我們在“禮儀課程”中能學到的東西。這些“軟技能”來自於對人的研究，需要去關注他們，在他們自己都表達不出自己需求的時候你卻能理解他們的需求，這些技能的獲取非常困難，與任何專業技能的獲取一樣困難。如果我們還是按照之前的習慣去對待這些技能，認為它們並不是“真正的”技能，認為它們無法與專業技能相提並論或者是貶低它們，那對我們沒什麼好處。當需要我們發揮這樣的軟技能去處理工作的時候，你就會發現它們絕對不是微不足道的地位。
（我想起了一件事，我認識的某位元工程師將團隊搬到了一個新的辦公樓，並表示：室內建築裝修應該很容易，他自己就是工程師，不需要再找別人來做這件事，結果可想而知。這讓人感覺很有意思，工程師、科學家和管理人員似乎都傾向於認為別人的專業技能應該很容易。）
3、好消息：總有辦法
我認為有一個非常“簡單”的方法可以來改善這一狀況，那就是開始將這些軟技能像“正兒八經”的專業技能一樣對待，重視這些技能，並且為這些技能提供培訓，聘請有這樣技能的新員工，就像我們對待其他關鍵性技能一樣。
一個好的開端能夠確保我們擁有並共用一種語言，如果你都說不上來某樣東西的名字，那就很難讓人去重視這樣東西。我們經常忽略的一些常見任務是“讓每人都能立刻看到專案內部的進展情況，”“為核心技術理念創建一種共用語言，讓每個人都能對相同的一件事情做出解釋，”“確保每個人的聲音都能被聽到，並且確保不會錯過重要的提醒（害怕說出），”並且“確保所有的利益相關者對項目都有一種個人所有的感覺，感受到自己的成功與專案的成功息息相關。”我們經常忽略的一些常見的措施是“使用者/客戶在使用本產品的過程中出現沮喪或是負面情緒的頻率有多高？這對他們的長期使用有什麼影響？”或者是“當使用者在使用該產品時有一次負面體驗，那接下來每個時間段（從 10 分鐘到一周）他們的體驗怎樣呢？這會如何影響他們對於該產品的體驗呢？”
其實這些都涉及到不同的專業技能，從項目管理到用戶體驗研究。但是，如果一個團隊，將這些看作是不相干的問題，並不認為是決定自己成敗的核心問題，那他們很可能會陷入一場災難：錯過里程碑；不同團隊創建起的系統存在些許不同，在最終整合時期只會產生衝突；關鍵的問題沒有得到及時解決；一個項目被隱晦地破壞掉，只是因為一個團隊不想讓它成功；用戶遇到一個小 bug，最終演變成一場大的災難（用戶大批流失或是惹上法律、監管的麻煩）；用戶的信任被緩慢地侵蝕掉。我見過因為上述任何一個原因而失敗的專案，即便是那些純粹“技術性”工程工作無可指摘的項目也擺脫不了上述原因的影響。
要想將這些看作是核心問題，而不是週邊、無關緊要的問題，就要求團隊每個人都對這些問題有基本的瞭解，即便他們不是這一問題的直接負責人，也能評估這些問題的影響。然後將這些問題與團隊不同職位角色相配對，看一下是屬於前端工程、後端工程、安全問題還是網站可靠性問題。一位工程師無法單獨完成這所有的工作其實很正常。事實上，如果任何一個人能夠自己完成這所有的工作，那真的會讓人感覺不可思議。但是如果我們將這些工作中的一部分看作是“無形的勞動”，也就是需要用我們假裝不存在的技能去解決的那些不被看重、“上不了什麼檯面”的勞動，那我們絕對是在搬起石頭砸自己的腳。
本文開篇所提到的焦慮就是一個症狀，因為我們都知道有些東西缺失的很嚴重，並且這些缺失的東西正變得越來越重要。如果我們將這些缺失的東西看作是“並非真正的技能”，是有些人自然而然就會而工程師不會的技能，那這會變得很可怕，因為聽上去就像工程師會被路人甲隨意碾壓，誰也不會尊重工程師一樣。但是，如果我們意識到這是一種真正的技能，是人們在生活過程中勤加練習才會擅長的技能，那我們對此就會有不同的態度。很多擅長這些軟技能的人可能不是來自於工程界，但這是因為工程界過去幾十年來對工程人員這方面的培訓工作做得比較失敗，並不意味著這些人就毫不瞭解工程界，或者說毫不尊重工程師。
有一點需要提醒，如果這個崗位工作涉及到協調工程師，或者是將工程系統連接到使用者，也或者是其他任何不尊重工程師就做不好的工作，那你不應該雇用不尊重工程師的人。“這個人會讓整個團隊感到痛苦”，這是一個危險信號。
但同時：專案中的每個人都需要重視並且瞭解專案中最基本的一些問題。如果系統中有一個法律相關的問題，那每個人都需要瞭解這一法律條文要求。如果有使用者研究顯示使用者對某個方面回饋較好或者較差，那每個人在設計的時候都需要考慮到這一點，或發揚或規避。同理，每個人都需要瞭解和重視人的技能：畢竟，你正在創建的這個系統至少是包括你在內的。
（36氪編譯組出品，未經允許嚴禁轉載。編輯：郝鵬程）
一旦你通過一定的門檻，需要特定層次技術水準才能解決的純粹技術性問題會大大減少，而無論是可靠的編譯器還是 Stack Exchange 這樣的問答網站越來越普遍，這也就意味著越來越多的硬技術問題很容易就能找到答案。當然，總是存在各種困難的問題，這些問題可能非常重要，但沒什麼經驗的人無論如何也解決不了。也正是因為如此，我們才需要繼續發展我們的專業技能。但是，如果你繼續發展你的技能，你很快就會發現，為解決這些及其困難的技術問題而花費的時間往往比一份全職工作的時間要少得多，影響系統的關鍵（並且也是很難的）問題在很大程度上取決於這個系統與外部世界（越來越多的人）的對話模式。
有趣的是，硬技能和軟技能之間的交集比許多人意識到的還要多：當你開始將你的系統看作是包括人類元素在內的一個更大系統的組成部分時，你會開始好奇人類之間如何交互，以及他們的行為怎樣這些問題，然後你會發現許多相同的“硬技能”系統設計方法有他們的道理所在，並且也能為傳統意義上純粹的“軟技能”問題提供更好的答案。防止多使用者系統濫用以及各種結果的排名就是兩個典型的例子；在這兩種情況下，既有對於使用者需求一種非常“軟”的直覺，同時對於這些直覺又有非常“硬”的技術表達，在兩種技能之間自由轉換的能力是無價之寶。
除了這些技術工作本身需要軟、硬技能重疊的情況之外，現在所需的很多“軟技能”其實與人事管理有很大的關係。工程師群體之前在人事管理領域一直代表性很差，因為歷史上人事管理工作一直是由那些沒有工程技能的人來從事，而且關鍵的一點在於，這些人可能缺乏對上述技能以及擁有這些技能的人群的尊重。這是因為，很多的管理層是從 20 世紀初的工業管理層演變而來，也就是工業管理領域提出了“人力資源”這樣的詞彙：他們將工人們看作是一種煩惱、一種消耗，是一個必須要通過“管理”來保持高產量工作的群體。
這種所謂的“管理”其實很糟糕，它其實就是由這樣一些人所創建起的一個領域，這些人往往認為自己有很好的軟技能，但現實是他們的軟技能非常糟糕，甚至有些病態。如果員工覺得自己的上級管理者並不尊重自己，那這本身就是一個很嚴重的危險信號：畢竟，一名管理者的基本工作就是協調不同的員工，讓他們作為一個團隊來工作，所以如果他們自己都做不到互相尊重，那他們不可能在員工中創造出這樣的氛圍。
事實上，我們現在所探討的“軟技能”並不是任何人輕而易舉就能獲取到的技能，不是我們在“禮儀課程”中能學到的東西。這些“軟技能”來自於對人的研究，需要去關注他們，在他們自己都表達不出自己需求的時候你卻能理解他們的需求，這些技能的獲取非常困難，與任何專業技能的獲取一樣困難。如果我們還是按照之前的習慣去對待這些技能，認為它們並不是“真正的”技能，認為它們無法與專業技能相提並論或者是貶低它們，那對我們沒什麼好處。當需要我們發揮這樣的軟技能去處理工作的時候，你就會發現它們絕對不是微不足道的地位。
（我想起了一件事，我認識的某位元工程師將團隊搬到了一個新的辦公樓，並表示：室內建築裝修應該很容易，他自己就是工程師，不需要再找別人來做這件事，結果可想而知。這讓人感覺很有意思，工程師、科學家和管理人員似乎都傾向於認為別人的專業技能應該很容易。）
3、好消息：總有辦法
我認為有一個非常“簡單”的方法可以來改善這一狀況，那就是開始將這些軟技能像“正兒八經”的專業技能一樣對待，重視這些技能，並且為這些技能提供培訓，聘請有這樣技能的新員工，就像我們對待其他關鍵性技能一樣。
一個好的開端能夠確保我們擁有並共用一種語言，如果你都說不上來某樣東西的名字，那就很難讓人去重視這樣東西。我們經常忽略的一些常見任務是“讓每人都能立刻看到專案內部的進展情況，”“為核心技術理念創建一種共用語言，讓每個人都能對相同的一件事情做出解釋，”“確保每個人的聲音都能被聽到，並且確保不會錯過重要的提醒（害怕說出），”並且“確保所有的利益相關者對項目都有一種個人所有的感覺，感受到自己的成功與專案的成功息息相關。”我們經常忽略的一些常見的措施是“使用者/客戶在使用本產品的過程中出現沮喪或是負面情緒的頻率有多高？這對他們的長期使用有什麼影響？”或者是“當使用者在使用該產品時有一次負面體驗，那接下來每個時間段（從 10 分鐘到一周）他們的體驗怎樣呢？這會如何影響他們對於該產品的體驗呢？”
其實這些都涉及到不同的專業技能，從項目管理到用戶體驗研究。但是，如果一個團隊，將這些看作是不相干的問題，並不認為是決定自己成敗的核心問題，那他們很可能會陷入一場災難：錯過里程碑；不同團隊創建起的系統存在些許不同，在最終整合時期只會產生衝突；關鍵的問題沒有得到及時解決；一個項目被隱晦地破壞掉，只是因為一個團隊不想讓它成功；用戶遇到一個小 bug，最終演變成一場大的災難（用戶大批流失或是惹上法律、監管的麻煩）；用戶的信任被緩慢地侵蝕掉。我見過因為上述任何一個原因而失敗的專案，即便是那些純粹“技術性”工程工作無可指摘的項目也擺脫不了上述原因的影響。
要想將這些看作是核心問題，而不是週邊、無關緊要的問題，就要求團隊每個人都對這些問題有基本的瞭解，即便他們不是這一問題的直接負責人，也能評估這些問題的影響。然後將這些問題與團隊不同職位角色相配對，看一下是屬於前端工程、後端工程、安全問題還是網站可靠性問題。一位工程師無法單獨完成這所有的工作其實很正常。事實上，如果任何一個人能夠自己完成這所有的工作，那真的會讓人感覺不可思議。但是如果我們將這些工作中的一部分看作是“無形的勞動”，也就是需要用我們假裝不存在的技能去解決的那些不被看重、“上不了什麼檯面”的勞動，那我們絕對是在搬起石頭砸自己的腳。
本文開篇所提到的焦慮就是一個症狀，因為我們都知道有些東西缺失的很嚴重，並且這些缺失的東西正變得越來越重要。如果我們將這些缺失的東西看作是“並非真正的技能”，是有些人自然而然就會而工程師不會的技能，那這會變得很可怕，因為聽上去就像工程師會被路人甲隨意碾壓，誰也不會尊重工程師一樣。但是，如果我們意識到這是一種真正的技能，是人們在生活過程中勤加練習才會擅長的技能，那我們對此就會有不同的態度。很多擅長這些軟技能的人可能不是來自於工程界，但這是因為工程界過去幾十年來對工程人員這方面的培訓工作做得比較失敗，並不意味著這些人就毫不瞭解工程界，或者說毫不尊重工程師。
有一點需要提醒，如果這個崗位工作涉及到協調工程師，或者是將工程系統連接到使用者，也或者是其他任何不尊重工程師就做不好的工作，那你不應該雇用不尊重工程師的人。“這個人會讓整個團隊感到痛苦”，這是一個危險信號。
但同時：專案中的每個人都需要重視並且瞭解專案中最基本的一些問題。如果系統中有一個法律相關的問題，那每個人都需要瞭解這一法律條文要求。如果有使用者研究顯示使用者對某個方面回饋較好或者較差，那每個人在設計的時候都需要考慮到這一點，或發揚或規避。同理，每個人都需要瞭解和重視人的技能：畢竟，你正在創建的這個系統至少是包括你在內的。
（36氪編譯組出品，未經允許嚴禁轉載。編輯：郝鵬程）