公司有個項目在走驗收流程了，但驗收過程中遇到了一些問題，本來這些問題是很好跟客戶解釋的，可是我們公司一程序員因為不會描述問題，程序員思維太重，在這過程中起到了反作用，跟客戶越解釋客戶越暈，客戶差點就不耐煩了！還好，最后我讓他別說話，我來跟客戶解釋，最終把問題給圓回來了！

程序思維太重的話，是不能直面客戶的，但是，很多行業，其實程序員是要直面客戶的，比如說我所在的上位機開發行業！

在我們公司這個項目的驗收過程中，客戶要聽取我們每個開發人員對于上位機功能的講解，因為客戶跟我們很熟了，每個人開發了哪些功能他都知道，所以就一個一個問。

等到問到程序員小高的時候，小高大致講解了下他負責的功能部分，小高講完以后，客戶發現小高之前寫的幾個比較麻煩的功能被修復了，于是就好奇地問小高他是怎么做到的。

而小高在講解其中一個功能的時候，幾乎是在跟客戶講代碼，小高怎么也解釋不清楚，客戶怎么也聽不懂，所以客戶就不耐煩了。

先說下小高寫的這個功能吧！

小高寫的這個功能是檢測某個硬件馬達的轉速的，這個馬達大約為1毫秒轉一圈，而馬達前面有一個桿子，而桿子旁邊有一個金屬傳感器，當馬達帶動這個桿子轉一圈，被金屬傳感器檢測到，那么在上位機系統上就記錄一個圈數。

而這個金屬傳感器是使用IO控制得，當金屬傳感器被觸發時，IO信號為1，不觸發時IO信號為0。

小高統計馬達圈數的剛開始的做法是單開一個線程使用一個死循環，一直去監聽IO信號，但是發現性能壓根跟不上，經常會漏掉信號，所以，記錄的馬達圈數一直不準，這個客戶是知道的，因此印象深刻，也一直讓我們解決，但我們一直沒有好的解決辦法。

這個問題解決不掉的原因也很簡單，因為如果在上位機代碼上做監聽，那么監聽程序很難不受軟件本身的其他事情影響，因此，監聽效率極差！

后來，我們了解到，公司使用的IO控制卡本身可以通過編程單開一條線程來做監聽的，不受其他程序影響，因此，我們就通過重新編程IO控制卡的方式，將那個死循環寫在了IO控制卡上，將監聽程序和上位機本身做了隔離，在將監聽到的圈數寫在了一個變量上，上位機通過調用IO控制卡的變量來獲取記錄的圈數，從而解決了問題。

當客戶問小高他是怎么解決這個問題的時候，小高跟他說大概是這樣的：“本來我們在程序里寫了一個while循環，循環監聽IO信號，但是，while循環的執行效率沒有IO信號的觸發信號快，因此計數就不準了。后來，我們發現金屬傳感器本身可以通過編程的方式去計數，因此我們就把計數放在了金屬傳感器里面做，這樣計數就準確了！”

客戶給他的回答搞懵了，因為客戶雖然不懂技術，但是他也知道金屬傳感器本身就只是個信號源，自己是不會計數的，因此被小高搞得一頭霧水！

小高又嘗試解釋了幾遍，但是都離不開代碼和金屬傳感器自己會計數這個說法，結果客戶可能覺得小高在蒙他，我站在旁邊都能感覺到客戶有點不高興了！于是立馬去打圓場。

我跟客戶是這么解釋的：“因為上位機本身是個軟件，它有很多事情需要做，本來我們是把計數功能放在上位機上做的，但是馬達的轉速太高，使用純軟件監聽的方式效率根本跟不上，容易丟信號。后來我們將計數功能從軟件當中剝離，又使用了硬件加速，因此現在的計數是相對準確的！”

為了讓客戶更加明白，我又舉了一個例子：“我們的軟件就像一個高速公路，軟件平時的執行過程就跟節假日的高速公路一樣，特別擁堵，計數功能如果跑在這個高速公路上，自然也會堵在那里。而我們新的方案就像是另外開發了一條高速公路，只有用來計數的那輛車才能跑，因此效率極高！”

可以看出，客戶雖然依舊不懂，我既給了比較專業的回答，又給了小白都能聽懂的白話，因此我的解釋客戶更能接受一點，總比說金屬傳感器自己在那計數要好得多吧！

結語

事后，我跟小高說，像咱這種需要直面客戶的，經常需要跟客戶解釋一些他們比較感興趣的問題，我們既要體現自己的專業性，又要讓客戶聽懂，如果光體現自己的專業性，但是客戶聽不懂的話，就有可能起反作用，導致客戶一頭霧水。

有些客戶不較真，雖然是一頭霧水，但是只要功能對了，他們也不會說什么，但是真碰到一些比較較真的客戶，你的解釋不能讓他們聽懂，他們會抓著你不放的！

尤其是像這次的這個客戶，他并不是完全不懂技術，有些東西的執行邏輯他是清楚的，這時候你講得不對或者含糊其辭，他們就會質疑你寫的東西到底是不是在正確執行他想要的效果。如果解釋不好，可能最后就“翻車”了！