“我不懂那些技術(shù)。每次跟工程師們交流時(shí)，都感覺他們會(huì)因?yàn)槲也欢夹g(shù)而暗自鄙視我，我應(yīng)該怎么做？”
上次我們聊了聊，工程師如何轉(zhuǎn)變成為一個(gè)優(yōu)秀的管理者。相信大家已經(jīng)很好的理解了直線思維和網(wǎng)狀思維的區(qū)別（請(qǐng)查看《工程師想要做管理？先改變你的思考方式》）。
但是有管理者問我：“我不懂那些技術(shù)。每次跟工程師們交流時(shí)，都感覺他們會(huì)因?yàn)槲也欢夹g(shù)而暗自鄙視我，我應(yīng)該怎么做？”
很多管理者，在和工程師談需求時(shí)，都費(fèi)盡唇舌的想要解釋清楚自己的想法，卻總是被工程師以“這個(gè)實(shí)現(xiàn)不了”為理由拒絕。如果再嘗試溝通，一個(gè)“亂改需求”的帽子就扣到了頭上。如果管理者再不依不饒的話，最后就變成真人PK了。
我們平時(shí)接觸最多的工程師群體莫過于程序員了。你看見過的程序員往往是：
聰明，知識(shí)面廣。
迷之自信，甚至自負(fù)。
對(duì)于技術(shù)異常執(zhí)著。
難以溝通， 沉浸在自己的小世界中。
（不會(huì)穿衣搭配）
現(xiàn)在，讓我站在一個(gè)（曾經(jīng)的）程序員的角度上，來談一談工程師的個(gè)人喜好：
1. 熱愛解決問題
2. 強(qiáng)大的邏輯性
3. 注重理論知識(shí)
一
熱愛解決問題
工程師最開心的時(shí)候，莫過于解決了一個(gè)實(shí)際問題所帶來的成就感。
工程師希望能夠從“看的見，摸得著”的事物中獲得成就感，比如一臺(tái)電機(jī)，一個(gè)軟件，一組生產(chǎn)線。讓工程師來“測試發(fā)電機(jī)運(yùn)行是否良好”，他們肯定會(huì)很開心。而讓工程師來“做空一個(gè)股票”，他們一定不樂意。
為什么？
因?yàn)?ldquo;測試發(fā)電機(jī)運(yùn)行是否良好”只需要嚴(yán)格遵照手冊(cè)規(guī)則，一步一步做下去，就一定能測試成功。而“做空一個(gè)股票”，可以有很多種方式，同時(shí)還可能有很多突發(fā)事件。而這種不確定性，就是工程師最討厭的部分。
當(dāng)然，常年累月的“解決問題”，也帶給了工程師另外一個(gè)特點(diǎn)，強(qiáng)大的邏輯性。
二
強(qiáng)大的邏輯性
有個(gè)關(guān)于程序員的笑話：
一天，妻子跟程序員丈夫說“你去菜場買兩斤蘋果，如果你看見了燒餅，就買一個(gè)回來”。
丈夫帶著一個(gè)蘋果回來了。
工程師的邏輯性強(qiáng)，是大家的一個(gè)共識(shí)。這是很多工程師的優(yōu)點(diǎn)，也是他們一個(gè)很大的阻礙。
你如果和工程師辯論，他們的邏輯都自成一體。“你這個(gè)項(xiàng)目做不出來，因?yàn)橐韵聨讉€(gè)原因。。。”。里面混著數(shù)個(gè)專業(yè)術(shù)語，帶著自信，不容你一絲反駁。
工程師平時(shí)的工作，又強(qiáng)化了他們對(duì)于事物邏輯性的追求：我們很難想象，一個(gè)隨機(jī)分布的程序，或者一個(gè)隨意裝配的機(jī)械，會(huì)如何的運(yùn)作。而工程師為了保持這些事物的穩(wěn)定，不得不學(xué)會(huì)按照機(jī)器的方式思考，也就是依靠邏輯來判斷事物的正誤。而邏輯性強(qiáng)的前提，就是需要有豐富的理論知識(shí)。
三
注重理論知識(shí)
一枚硬幣拋了100次，都是正面，那么下一次是反面的幾率有多大？
如果是工程師，他會(huì)說：“50%，因?yàn)橛矌诺恼春椭暗慕Y(jié)果是互相獨(dú)立的”。
如果是個(gè)商人，他會(huì)說：“0%，因?yàn)?00次正面，已經(jīng)證明這個(gè)硬幣被動(dòng)過手腳了。”
對(duì)于科學(xué)知識(shí)的信任，是所有工程師的共性。想要成為一個(gè)出色的工程師，就必須對(duì)技術(shù)和科學(xué)有著近乎狂熱的信仰。
工程師對(duì)技術(shù)的信仰，有時(shí)會(huì)成為偏執(zhí)的原因。因?yàn)楣こ處煹倪壿嬍且揽孔陨韽?qiáng)大的理論知識(shí)所建立起來的。而這樣也帶來了社會(huì)心理學(xué)所說的“知識(shí)的詛咒”：專家以術(shù)語和他人交談，失去了與非專業(yè)人士溝通的能力 。
既然我們分析了工程師的特點(diǎn)，那么，如果我們想讓工程師滿足需求，我們?cè)撛趺醋觯?br style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important;" />
給工程師發(fā)嗲，撒嬌，賣萌？
給他們買超好的電腦，配上超大的屏幕？
做他們的出氣筒，當(dāng)受氣包？
當(dāng)你只管理一兩個(gè)工程師的時(shí)候，這樣可能會(huì)有效，可能會(huì)留住那些優(yōu)秀的工程師。但是，我們需要的是組建一個(gè)優(yōu)秀的工程師團(tuán)隊(duì)，僅僅依靠人情，會(huì)浪費(fèi)大部分精力在辦公室社交上。那么，我們需要做到以下幾點(diǎn)：
1. 多聽少說
2. 提出問題
3. 自我學(xué)習(xí)
4. 證明自己
5. 親自交流
一
多聽少說
作為一個(gè)合格的管理者，我們需要做到和上級(jí)匯報(bào)，和客戶解釋，和供應(yīng)商溝通。。。只有一個(gè)“能說會(huì)道”的管理者，才是一個(gè)優(yōu)秀的管理者。
這樣也導(dǎo)致我們?cè)诟こ處煖贤〞r(shí)，總是在和工程師長篇大論，談及各種設(shè)想，創(chuàng)意，需求。而工程師卻不得不坐在那，耐著性子，聽著對(duì)他們毫無意義的空話。
我們知道工程師最喜歡的事情是：用盡可能簡單的方式，去解決一個(gè)新奇的，有趣的，復(fù)雜的，實(shí)際的問題，并且因此而掙錢。而我們也知道，一個(gè)問題的長度，是遠(yuǎn)小于答案的長度的。
所以，作為問題的提出者，我們需要更多的鼓勵(lì)工程師占據(jù)談話的主導(dǎo)權(quán)。他們作為天生的問題解決者，一定能提出更加精彩的點(diǎn)子。
“沒錯(cuò)呀，我們都是讓工程師去解決一個(gè)實(shí)際問題啊，比如做個(gè)類似百度的搜索引擎。為什么他們一口回絕了呢？”
這是由于我們創(chuàng)造了錯(cuò)誤的問題，并且嘗試讓工程師去解決。這些錯(cuò)誤的問題，站在我們的角度上，感覺并不是很難。而站在工程師角度上，這種問題是在故意刁難他們。那么，我們?nèi)绾尾拍軉柍龊线m的問題呢？
二
提出問題
很多管理者問的最多的問題是：“這個(gè)項(xiàng)目什么時(shí)候能做完？”
試想一下，我們?cè)诳匆粋€(gè)人彈鋼琴。即使你不會(huì)彈鋼琴，你也知道《小星星》比貝多芬的《命運(yùn)》容易的多。這是因?yàn)槲覀冊(cè)谂袛嗨臅r(shí)候，我們依靠的是它的速度來進(jìn)行判斷的。而小《小星星》的速度比《命運(yùn)》慢的多。
作為不懂的鋼琴技術(shù)我們，只能利用錨定效應(yīng)來估計(jì)復(fù)雜度：為不熟悉的事物做估計(jì)時(shí)，我們會(huì)以熟悉的事物來作為“錨點(diǎn)”，而估計(jì)出來的結(jié)果和“錨點(diǎn)”往往相近。當(dāng)然，這樣的判斷大多數(shù)情況是正確的。
然而，你是不是經(jīng)常聽見工程師說：
這個(gè)問題解決不了。
這個(gè)需求沒辦法做。
這個(gè)流程很復(fù)雜。
你會(huì)想：“這有什么難的，不就是要你做個(gè)小程序來排個(gè)序/放大窗口/批量刪除嘛”。
我們提出的問題一般都是“難度低，重復(fù)性高”。這類問題大多數(shù)人都可以輕易解決，只是想利用機(jī)器減少人工的消耗。而我們的錨點(diǎn)就是“人可以輕易解決的問題”，自然而然的將問題看得很簡單。
所以，我們對(duì)于問題難度錯(cuò)誤的估計(jì)，加上預(yù)算的緊逼，讓工程師很難將注意力集中于提升產(chǎn)品質(zhì)量上，反而去關(guān)心一些無關(guān)緊要的事情：
如何讓管理人員不再來煩我？
如何向這些外行證明我才是對(duì)的？
如何讓別人來接手這個(gè)爛攤子？
那么，我們?nèi)绾伪苊獗还こ處熣J(rèn)為是外行呢？我們需要自我提升。
三
自我學(xué)習(xí)
我給大家講個(gè)笑話：手持兩把錕斤拷，口中疾呼燙燙燙。
是不是完全無法理解這個(gè)笑話的笑點(diǎn)？
正如這樣，如果我們不深入理解需求中存在的技術(shù)問題，而讓工程師頭疼于那些非技術(shù)原因產(chǎn)生的問題，很容易讓最終產(chǎn)品延期又低質(zhì)。（至于那個(gè)笑話，是一個(gè)程序編譯時(shí)常見的亂碼錯(cuò)誤）
因此，我們作為管理者，首先就需要將一些初級(jí)的，非技術(shù)的問題消滅掉，從而減少工程師的工作量。
“如果我會(huì)的話，我自己做就好了，那就不需要請(qǐng)工程師了。問題是我學(xué)不會(huì)啊！”
我們不需要去懂得如何去實(shí)現(xiàn)，而是將基礎(chǔ)原理適當(dāng)?shù)倪M(jìn)行了解。至少做到能夠理解工程師口中的專業(yè)詞匯，就能大大減少我們交流溝通時(shí)的障礙。
那么，如果我們真的完全搞不懂那些技術(shù)，我們?cè)撊绾螐钠渌矫嫦率帜兀?/span>
四
證明自己
不少工程師對(duì)于管理學(xué)的態(tài)度是：“這有什么難的？不就是做個(gè)PPT，寫個(gè)報(bào)告，匯報(bào)一下就好了？”
有些管理者則默認(rèn)了這種想法的正確性。平時(shí)把自己的姿態(tài)放低，給工程師端茶送水，揉肩捶背。而有些管理者對(duì)這種想法嗤之以鼻，與工程師處于“道不同，不相為謀”的冷淡關(guān)系。
沒錯(cuò)，科學(xué)技術(shù)是第一生產(chǎn)力。而且，如果我們每個(gè)人都能良好的理解他人的想法，并且按照步驟按時(shí)完成，其實(shí)我們根本不需要任何管理者。然而，人與人思考模式有著巨大的鴻溝，管理者則是搭建這些橋梁的關(guān)鍵人物。
明茨伯格的管理者角色理論中提出，管理者需要處理三個(gè)方面的問題：人際關(guān)系，信息傳遞，以及決策制定。由于人際關(guān)系依托于個(gè)人性格的展現(xiàn)，而決策制定很難直觀的表述出來。那么，我們可以向工程師展現(xiàn)出自己的“信息傳遞”的能力。
解決辦法是，我們可以進(jìn)行一下角色互換。讓工程師來監(jiān)督我們的PPT制作過程，報(bào)告的撰寫流程，等等。讓工程師能夠感受到管理者為項(xiàng)目所作出的努力，感受到管理者作為“溝通的橋梁”所展現(xiàn)出的技能與技術(shù)，增加工程師對(duì)于管理者的諒解。
如果工程師覺得這是浪費(fèi)時(shí)間，拒絕角色互換，怎么辦？我們只能拿出殺手锏了：讓工程師和客戶交流。
五
親自交流
對(duì)于工程師來說，管理者是輔助他們與客戶交流的橋梁。但如果工程師不聽從管理者的建議，那么，讓工程師直接去體驗(yàn)客戶的需求，是解決需求紛爭的最佳方案。
我們有三種辦法，讓工程師直面用戶的需求：
1）讓工程師使用自己的產(chǎn)品。
這樣的方式最為簡便，但是也最不直觀，因?yàn)楣こ處熗皇钱a(chǎn)品的主要受眾。這樣的方法可以讓工程師很容易發(fā)現(xiàn)一些常見問題，但是很難去深入了解客戶的特殊需求。例如，我們?yōu)楹媾喾婚_發(fā)了一套自動(dòng)化生產(chǎn)線，但是工程師自己很難依靠這個(gè)生產(chǎn)線分析出烘焙坊的真實(shí)需求。
2）讓工程師接受用戶反饋
大多數(shù)用戶反饋都是傳遞到了售后部門，然后由售后部門整理后集中發(fā)給技術(shù)部門。由于用戶和售后部門對(duì)于技術(shù)的不了解，有些技術(shù)上的問題，可能因?yàn)楸粴w類為非技術(shù)問題而忽略了。讓工程師直面反饋，他們也能逐漸發(fā)現(xiàn)問題的規(guī)律，可以防止下一次開發(fā)犯同樣的錯(cuò)誤。然而，客戶的反饋往往都是負(fù)面的，這樣也容易造成工程師對(duì)于產(chǎn)品產(chǎn)生一定偏見。
3）讓工程師觀察用戶如何使用
這是最復(fù)雜的方法，但是也是最有效的方法。讓工程師直接觀察用戶的使用方式與使用習(xí)慣。通過這種方法，工程師可以了解到，用戶如何實(shí)際使用產(chǎn)品的，也能夠?yàn)楣こ處煾倪M(jìn)產(chǎn)品提供更多的靈感。然而，這樣的方式會(huì)占用大量的開發(fā)時(shí)間，而且大多數(shù)工程師，會(huì)對(duì)這個(gè)方式有如同本能般的抵觸——因?yàn)檫@相當(dāng)于讓工程師自己承認(rèn)，自己的產(chǎn)品有缺陷。
作為殺手锏，這三個(gè)方式都可以酌情使用，然而會(huì)占用雙方大量的時(shí)間和精力，造成項(xiàng)目的停工。相對(duì)于說服工程師，更難的可能是說服整個(gè)項(xiàng)目組花費(fèi)時(shí)間來做這些“無用功”。
最后，總結(jié)一下管理者和工程師溝通的五個(gè)要點(diǎn)：
1.讓工程師成為解決問題的主導(dǎo)者
2.選擇正確的方向進(jìn)行溝通
3.提升管理者的專業(yè)知識(shí)
4.展現(xiàn)管理者的非專業(yè)技術(shù)
5. 促進(jìn)工程師和客戶的直接交流。
