起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識不懂技術，如何和工程師交流？
上次我們聊了聊，工程師如何轉變成為一個優秀的管理者；這次我們聊聊不懂技術的管理者如何同工程師談需求。
管理者問我：“我不懂那些技術，每次跟工程師們交流時，都感覺他們會因為我不懂技術而暗自鄙視我，我應該怎么做？”
很多管理者，在和工程師談需求時，都費盡唇舌的想要解釋清楚自己的想法，卻總是被工程師以“這個實現不了”為理由拒絕。如果再嘗試溝通，一個“亂改需求”的帽子就扣到了頭上。如果管理者再不依不饒的話，最后就變成真人PK了。
我們平時接觸最多的工程師群體莫過于程序員了。
你看見過的程序員往往是：
- 聰明，知識面廣。迷之自信，甚至自負。
- 對于技術異常執著，難以溝通。
- 沉浸在自己的小世界中。
- （不會穿衣搭配）
現在，讓我站在一個（曾經的）程序員的角度上，來談一談工程師的個人喜好：
- 熱愛解決問題
- 強大的邏輯性
- 注重理論知識
一、熱愛解決問題
工程師最開心的時候，莫過于解決了一個實際問題所帶來的成就感。
工程師希望能夠從“看的見，摸得著”的事物中獲得成就感，比如一臺電機，一個軟件，一組生產線。讓工程師來“測試發電機運行是否良好”，他們肯定會很開心。而讓工程師來“做空一個股票”，他們一定不樂意。
為什么？
因為“測試發電機運行是否良好”只需要嚴格遵照手冊規則，一步一步做下去，就一定能測試成功。而“做空一個股票”，可以有很多種方式，同時還可能有很多突發事件。而這種不確定性，就是工程師最討厭的部分。
當然，常年累月的“解決問題”，也帶給了工程師另外一個特點，強大的邏輯性。
二、強大的邏輯性
有個關于程序員的笑話：
一天，妻子跟程序員丈夫說：“你去菜場買兩斤蘋果，如果你看見了燒餅，就買一個回來”。
丈夫帶著一個蘋果回來了。
工程師的邏輯性強，是大家的一個共識。這是很多工程師的優點，也是他們一個很大的阻礙。
你如果和工程師辯論，他們的邏輯都自成一體?！澳氵@個項目做不出來，因為以下幾個原因……”。里面混著數個專業術語，帶著自信，不容你一絲反駁。
工程師平時的工作，又強化了他們對于事物邏輯性的追求：我們很難想象，一個隨機分布的程序，或者一個隨意裝配的機械，會如何的運作。而工程師為了保持這些事物的穩定，不得不學會按照機器的方式思考，也就是依靠邏輯來判斷事物的正誤。而邏輯性強的前提，就是需要有豐富的理論知識。
三、注重理論知識
一枚硬幣拋了100次，都是正面，那么下一次是反面的幾率有多大？
如果是工程師，他會說：“50%，因為硬幣的正反和之前的結果是互相獨立的”。
如果是個商人，他會說：“0%，因為100次正面，已經證明這個硬幣被動過手腳了。”
對于科學知識的信任，是所有工程師的共性。想要成為一個出色的工程師，就必須對技術和科學有著近乎狂熱的信仰。
工程師對技術的信仰，有時會成為偏執的原因。因為工程師的邏輯是依靠自身強大的理論知識所建立起來的。而這樣也帶來了社會心理學所說的“知識的詛咒”：專家以術語和他人交談，失去了與非專業人士溝通的能力 。
既然我們分析了工程師的特點，那么，如果我們想讓工程師滿足需求，我們該怎么做？
- 給工程師發嗲，撒嬌，賣萌？
- 給他們買超好的電腦，配上超大的屏幕？
- 做他們的出氣筒，當受氣包？
當你只管理一兩個工程師的時候，這樣可能會有效，可能會留住那些優秀的工程師。但是，我們需要的是組建一個優秀的工程師團隊，僅僅依靠人情，會浪費大部分精力在辦公室社交上。
那么，我們需要做到以下幾點：
- 多聽少說
- 提出問題
- 自我學習
- 證明自己
- 親自交流
1. 多聽少說
作為一個合格的管理者，我們需要做到和上級匯報，和客戶解釋，和供應商溝通……只有一個“能說會道”的管理者，才是一個優秀的管理者。
這樣也導致我們在跟工程師溝通時，總是在和工程師長篇大論，談及各種設想，創意，需求。而工程師卻不得不坐在那，耐著性子，聽著對他們毫無意義的空話。
我們知道工程師最喜歡的事情是：用盡可能簡單的方式，去解決一個新奇的，有趣的，復雜的，實際的問題，并且因此而掙錢。而我們也知道，一個問題的長度，是遠小于答案的長度的。
所以，作為問題的提出者，我們需要更多的鼓勵工程師占據談話的主導權。他們作為天生的問題解決者，一定能提出更加精彩的點子。
“沒錯呀，我們都是讓工程師去解決一個實際問題啊，比如做個類似百度的搜索引擎。為什么他們一口回絕了呢？”
這是由于我們創造了錯誤的問題，并且嘗試讓工程師去解決。這些錯誤的問題，站在我們的角度上，感覺并不是很難。而站在工程師角度上，這種問題是在故意刁難他們。
那么，我們如何才能問出合適的問題呢？
2. 提出問題
很多管理者問的最多的問題是：“這個項目什么時候能做完？”
試想一下，我們在看一個人彈鋼琴。即使你不會彈鋼琴，你也知道《小星星》比貝多芬的《命運》容易的多。這是因為我們在判斷它的時候，我們依靠的是它的速度來進行判斷的。而小《小星星》的速度比《命運》慢的多。
作為不懂的鋼琴技術我們，只能利用錨定效應來估計復雜度：為不熟悉的事物做估計時，我們會以熟悉的事物來作為“錨點”，而估計出來的結果和“錨點”往往相近。當然，這樣的判斷大多數情況是正確的。
然而，你是不是經常聽見工程師說：
- 這個問題解決不了。
- 這個需求沒辦法做。
- 這個流程很復雜。
你會想：“這有什么難的，不就是要你做個小程序來排個序/放大窗口/批量刪除嘛”。
我們提出的問題一般都是“難度低，重復性高”。這類問題大多數人都可以輕易解決，只是想利用機器減少人工的消耗。而我們的錨點就是“人可以輕易解決的問題”，自然而然的將問題看得很簡單。
所以，我們對于問題難度錯誤的估計，加上預算的緊逼，讓工程師很難將注意力集中于提升產品質量上，反而去關心一些無關緊要的事情：
- 如何讓管理人員不再來煩我？
- 如何向這些外行證明我才是對的？
- 如何讓別人來接手這個爛攤子？
那么，我們如何避免被工程師認為是外行呢？
我們需要自我提升。
3. 自我學習
我給大家講個笑話：手持兩把錕斤拷，口中疾呼燙燙燙。
是不是完全無法理解這個笑話的笑點？
正如這樣，如果我們不深入理解需求中存在的技術問題，而讓工程師頭疼于那些非技術原因產生的問題，很容易讓最終產品延期又低質。（至于那個笑話，是一個程序編譯時常見的亂碼錯誤）
因此，我們作為管理者，首先就需要將一些初級的，非技術的問題消滅掉，從而減少工程師的工作量。
“如果我會的話，我自己做就好了，那就不需要請工程師了。問題是我學不會啊！”
我們不需要去懂得如何去實現，而是將基礎原理適當的進行了解。至少做到能夠理解工程師口中的專業詞匯，就能大大減少我們交流溝通時的障礙。
那么，如果我們真的完全搞不懂那些技術，我們該如何從其他方面下手呢？
4. 證明自己
不少工程師對于管理學的態度是：“這有什么難的？不就是做個PPT，寫個報告，匯報一下就好了？”
有些管理者則默認了這種想法的正確性，平時把自己的姿態放低，給工程師端茶送水，揉肩捶背。而有些管理者對這種想法嗤之以鼻，與工程師處于“道不同，不相為謀”的冷淡關系。
沒錯，科學技術是第一生產力。而且，如果我們每個人都能良好的理解他人的想法，并且按照步驟按時完成，其實我們根本不需要任何管理者。然而，人與人思考模式有著巨大的鴻溝，管理者則是搭建這些橋梁的關鍵人物。
明茨伯格的管理者角色理論中提出，管理者需要處理三個方面的問題：人際關系、信息傳遞、以及決策制定。由于人際關系依托于個人性格的展現，而決策制定很難直觀的表述出來。那么，我們可以向工程師展現出自己的“信息傳遞”的能力。
解決辦法是：我們可以進行一下角色互換，讓工程師來監督我們的PPT制作過程，報告的撰寫流程等等。讓工程師能夠感受到管理者為項目所作出的努力，感受到管理者作為“溝通的橋梁”所展現出的技能與技術，增加工程師對于管理者的諒解。
如果工程師覺得這是浪費時間，拒絕角色互換，怎么辦？
我們只能拿出殺手锏了：讓工程師和客戶交流。
5. 親自交流
對于工程師來說，管理者是輔助他們與客戶交流的橋梁。但如果工程師不聽從管理者的建議，那么，讓工程師直接去體驗客戶的需求，是解決需求紛爭的最佳方案。
我們有三種辦法，讓工程師直面用戶的需求：
（1）讓工程師使用自己的產品
這樣的方式最為簡便，但是也最不直觀，因為工程師往往不是產品的主要受眾。這樣的方法可以讓工程師很容易發現一些常見問題，但是很難去深入了解客戶的特殊需求。
例如：我們為烘培坊開發了一套自動化生產線，但是工程師自己很難依靠這個生產線分析出烘焙坊的真實需求。
（2）讓工程師接受用戶反饋
大多數用戶反饋都是傳遞到了售后部門，然后由售后部門整理后集中發給技術部門。由于用戶和售后部門對于技術的不了解，有些技術上的問題，可能因為被歸類為非技術問題而忽略了。
讓工程師直面反饋，他們也能逐漸發現問題的規律，可以防止下一次開發犯同樣的錯誤。然而，客戶的反饋往往都是負面的，這樣也容易造成工程師對于產品產生一定偏見。
（3）讓工程師觀察用戶如何使用
這是最復雜的方法，但是也是最有效的方法。讓工程師直接觀察用戶的使用方式與使用習慣。通過這種方法，工程師可以了解到，用戶如何實際使用產品的，也能夠為工程師改進產品提供更多的靈感。
然而，這樣的方式會占用大量的開發時間，而且大多數工程師，會對這個方式有如同本能般的抵觸——因為這相當于讓工程師自己承認，自己的產品有缺陷。
作為殺手锏，這三個方式都可以酌情使用，然而會占用雙方大量的時間和精力，造成項目的停工。相對于說服工程師，更難的可能是說服整個項目組花費時間來做這些“無用功”。
最后，總結一下管理者和工程師溝通的五個要點：
- 讓工程師成為解決問題的主導者
- 選擇正確的方向進行溝通
- 提升管理者的專業知識
- 展現管理者的非專業技術
- 促進工程師和客戶的直接交流
本文由 @鹵豆干 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
傲慢與偏見一書提到:人都會對事物產生偏見對比，這也是人之常情或者自私，但一個聰明人應該學會適當收斂，我會直接把甩鍋的m開了，但問題是這是不是我的偏見沒有收斂，我常常思考
摔鍋的還罵不了，因為現在沒法為未來下結論。常常的摔鍋，就是對未來的質疑，站在不同假設條件下的質疑…
我司的有資歷的程序猿們，只會強調誰誰誰背鍋，很打擊人工作的動力呢
我覺得那是他們開發的沒有安全感，產品經理團隊推卸責任的甩鍋太多了，直接導致了這種情況。
都是自私的問題，都站在自己的角度想問題，又不想為所作所為負責。這個根本原因可能和民族特色有關，中國人自古都是貧民思想，每個人都期盼著強者來解決問題（比如各朝皇帝），每個貧民都不愿意出頭，也不愿意擔責；同時作為強者的自己，也不愿意承認是自己解決的問題，而是“天”解決的。所以就慢慢成就了不擔責的民風，現在都無法改變…映射到職場，是一樣樣的。
個人認為，如果容易互相推卸責任，主要問題都是出在責任分配制度的不完善上。我之后會寫一篇關于企業責任分配的必要性與方法的文章，歡迎您關注。