如何正确的报修

    先讲个故事，今天接到一宗报修，主题是“数据库连不上了”，我的天，大事件啊，习惯性地立即测试一下，发现一切正常。随后开始追问谁说的“数据库连接不上”，原来是一个女程序员和女行政的故障分析。之所以非要在程序员前面加个女字，并不是性别歧视，恰恰相反，程序媛就好好指导一下，程序猿的话就得训一顿了。

    当发现软件无法正常运行时，完全无视错误提示，把弹窗当小红点了，赶紧戳没它。然后开启故障排查，第一次，在资源管理器里输入\\数据库IP。

    妹纸，你的大学计算机应用基础老师生气了。

    第二次，在浏览器里输入了数据库IP，很巧，这服务器上面是有网站的，正常打开了，完美！可是妹纸坚持说网络有问题，好吧，浏览器打开网站只说明WEB服务正常，并不代表数据库服务正常。

   第三次，使用了Ping，终于有点工程师的赶脚了。

    妹纸，你的计算机网络老师生气了，网关阻止了Ping不行吗？浏览器访问这个数据库上的网站已经成功，怎么就是网络故障呢？正确的做法是telnet 服务器ip 数据库端口来测试，或许防火墙阻塞端口，或许数据库服务没启动。怎么还和跨网段扯上关系了？

    故事到这里就结束了，因为妹纸下班了。

 

    十多年前发表过一篇《提问的学问》，面向编程初学者的，十多年后，想写一篇《报修的学问》，酝酿了好久，今天终于提笔了。

    工程师不可避免地要和非技术专业的人沟通，怎么沟通是一门学问，恐怕又要引经据典说个长篇，长话短说，按需求和故障报修两类事情分开说。

    和客户聊需求，先倾听客户的陈述，原封不动记录下来，排除掉客户说的IT术语，重点学习客户行业的术语，然后组织语言复述客户的需求，要避免使用IT术语。沟通几回合，掌握客户的目标即可。如果是售前，则要拿出一个客户技术水平能看懂、提到的术语客户都明白的解决方案，客户认可这份解决方案就算过关。如果是需求调研，输入输出都要按照客户现行的格式弄清楚，业务流程图要画仔细，最好是有高成熟度的原型设计让客户能直观地感受到将来交付的软件是什么样子，为什么要这么做？一千个读者一千个哈姆雷特，一句话被不同人理解成不同意思很容易发生。如果你一直在抱怨客户的需求总是在变化，小心了，这说明你没有真正的挖掘出客户需求，你已经曲解了客户的需求。建议程序员交叉审查需求分析文档，什么时候别人提不出疑惑，那这份需求分析就可以给客户确认了。

    客户故障报修，和聊需求的注意事项一样，搞清楚故障描述即可，你信客户的术语就会被带到坑里，你说过多的术语只会引起客户更多的疑惑和追问。程序员有三怕，第一怕：最后一次编码/看技术书籍已是几年前的技术总监，他若是放手还好，若是遇到抓得宽的，大家一起死去吧；第二怕：自认为懂技术的项目/产品经理，他们确实很了解需求，很熟悉软件结构和操作，核心矛盾在他只看到盒子的表面，而程序员还看到了盒子的内部，如果真如他所想改动界面那一点点只是分分钟的事情的话，程序员吃饱了撑的跟你拍桌子丢板凳；第三怕：测试，如果性能、白盒、接口测试没有搞得万无一失，等集成测试的时候大家就抱头痛哭吧。这三怕的问题核心就在技术专业的人和非技术专业的人用了一大堆技术术语来讨论技术问题，没好果子吃，程序员信了他们的话就被带到坑里，企图纠正他的错误那就是各种吵架甚至打架。最后奉劝程序员一句，做事一定要按规矩来，微信是用来扯淡的，不是用来工作的，眼见为实，耳听为虚，一定要和客户面对面沟通，了解需求，了解故障。

    好吧，可以总结了，沟通秘笈是：倾听，复述，不使用IT术语。