项目验收过程中，程序员给客户解释软件问题，差点“翻车”！

公司有个项目在走验收流程了，但验收过程中遇到了一些问题，本来这些问题是很好跟客户解释的，可是我们公司一程序员因为不会描述问题，程序员思维太重，在这过程中起到了反作用，跟客户越解释客户越晕，客户差点就不耐烦了！还好，最后我让他别说话，我来跟客户解释，最终把问题给圆回来了！

程序思维太重的话，是不能直面客户的，但是，很多行业，其实程序员是要直面客户的，比如说我所在的上位机开发行业！

在我们公司这个项目的验收过程中，客户要听取我们每个开发人员对于上位机功能的讲解，因为客户跟我们很熟了，每个人开发了哪些功能他都知道，所以就一个一个问。

等到问到程序员小高的时候，小高大致讲解了下他负责的功能部分，小高讲完以后，客户发现小高之前写的几个比较麻烦的功能被修复了，于是就好奇地问小高他是怎么做到的。

而小高在讲解其中一个功能的时候，几乎是在跟客户讲代码，小高怎么也解释不清楚，客户怎么也听不懂，所以客户就不耐烦了。

先说下小高写的这个功能吧！

小高写的这个功能是检测某个硬件马达的转速的，这个马达大约为1毫秒转一圈，而马达前面有一个杆子，而杆子旁边有一个金属传感器，当马达带动这个杆子转一圈，被金属传感器检测到，那么在上位机系统上就记录一个圈数。

而这个金属传感器是使用IO控制得，当金属传感器被触发时，IO信号为1，不触发时IO信号为0。

小高统计马达圈数的刚开始的做法是单开一个线程使用一个死循环，一直去监听IO信号，但是发现性能压根跟不上，经常会漏掉信号，所以，记录的马达圈数一直不准，这个客户是知道的，因此印象深刻，也一直让我们解决，但我们一直没有好的解决办法。

这个问题解决不掉的原因也很简单，因为如果在上位机代码上做监听，那么监听程序很难不受软件本身的其他事情影响，因此，监听效率极差！

后来，我们了解到，公司使用的IO控制卡本身可以通过编程单开一条线程来做监听的，不受其他程序影响，因此，我们就通过重新编程IO控制卡的方式，将那个死循环写在了IO控制卡上，将监听程序和上位机本身做了隔离，在将监听到的圈数写在了一个变量上，上位机通过调用IO控制卡的变量来获取记录的圈数，从而解决了问题。

当客户问小高他是怎么解决这个问题的时候，小高跟他说大概是这样的：“本来我们在程序里写了一个while循环，循环监听IO信号，但是，while循环的执行效率没有IO信号的触发信号快，因此计数就不准了。后来，我们发现金属传感器本身可以通过编程的方式去计数，因此我们就把计数放在了金属传感器里面做，这样计数就准确了！”

客户给他的回答搞懵了，因为客户虽然不懂技术，但是他也知道金属传感器本身就只是个信号源，自己是不会计数的，因此被小高搞得一头雾水！

小高又尝试解释了几遍，但是都离不开代码和金属传感器自己会计数这个说法，结果客户可能觉得小高在蒙他，我站在旁边都能感觉到客户有点不高兴了！于是立马去打圆场。

我跟客户是这么解释的：“因为上位机本身是个软件，它有很多事情需要做，本来我们是把计数功能放在上位机上做的，但是马达的转速太高，使用纯软件监听的方式效率根本跟不上，容易丢信号。后来我们将计数功能从软件当中剥离，又使用了硬件加速，因此现在的计数是相对准确的！”

为了让客户更加明白，我又举了一个例子：“我们的软件就像一个高速公路，软件平时的执行过程就跟节假日的高速公路一样，特别拥堵，计数功能如果跑在这个高速公路上，自然也会堵在那里。而我们新的方案就像是另外开发了一条高速公路，只有用来计数的那辆车才能跑，因此效率极高！”

可以看出，客户虽然依旧不懂，我既给了比较专业的回答，又给了小白都能听懂的白话，因此我的解释客户更能接受一点，总比说金属传感器自己在那计数要好得多吧！

结语

事后，我跟小高说，像咱这种需要直面客户的，经常需要跟客户解释一些他们比较感兴趣的问题，我们既要体现自己的专业性，又要让客户听懂，如果光体现自己的专业性，但是客户听不懂的话，就有可能起反作用，导致客户一头雾水。

有些客户不较真，虽然是一头雾水，但是只要功能对了，他们也不会说什么，但是真碰到一些比较较真的客户，你的解释不能让他们听懂，他们会抓着你不放的！

尤其是像这次的这个客户，他并不是完全不懂技术，有些东西的执行逻辑他是清楚的，这时候你讲得不对或者含糊其辞，他们就会质疑你写的东西到底是不是在正确执行他想要的效果。如果解释不好，可能最后就“翻车”了！