如何应对客户的质疑,拒绝,讨价还价和各种无厘头问题

来源:V型知识库 2017年08月07日 17:06 浏览:1310

事情的起因与经过

我们公司的合作伙伴使用我们的实时数据库做一个数据中心的项目,项目使用DotNet开发。合作伙伴的公司有一个员工专门负责封装数据层--对实时数据库的增删改查的封装

但是这个人的脾气有点怪,或者说有点傲气,一段时间下来,只要他遇到操作数据库的问题,大部分归结于数据库或者我们提供的DotNetSDK的问题。无论是他不会使用的问题,还是确实是我们产品的问题,我们基本上每次都会远程或者直接到他公司去给他解决问题。

就这样持续了大概一年的的时间,直到前段时间他遇到一个问题:调用DotNetSDK的一个方法时,根据传入参数的不同会出现有时正常,有时会抛出一个”找不到DotNetSDK程序集”的异常

后来同事远程给他查看问题,发现他是使用Remoting的技术进行远程调用,而真正调用DotNetSDK的地方是服务端,出现”找不到DotNetSDK程序集”的异常为客户端。

客户端出现异常后,查看异常的详细信息为”无法进行反序列化”。查资料了解后,应该是Remoting无法对异常、null进行序列化反序列化。

当服务端调用DotNetSDK时,传入了无效的参数,DotNetSDK会抛出异常,而服务端并没有对异常进行捕捉,导致异常通过Remoting返回到客户端,而由于Remoting不能对异常反序列化,所以导致客户端抛出异常,至于为什么异常的标题是”找不到DotNetSDK程序集”,就不清楚原因了。

找到问题的原因后,给对方的开发人员解释这属于Remoting调用的问题,和DotNetSDK无关。但是不清楚对方的开发人员是不了解Remoting调用还是其他原因,他就一口咬定是DotNetSDK出了问题。

没办法,我们让他在服务端调用DotNetSDK的地方加入了try catch,并在catch中将异常信息记录到日志中。

运行了一次,查看日志,记录的异常信息为”无效的参数”。

这样,通过这个日志信息,我们证明了我们的DotNetSDK并没有问题,而是他的Remoting调用的问题。对方的开发人员总算承认不是DotNetSDK的问题了,这时候给他讲Remoting的事情,他才总算稍稍认可。

就是这样一个事情,我们向领导汇报后,领导把我们批了一顿“你们之所以和对方的开发人员,关系处理的这么紧张、不舒服,就是因为出现问题后,你们总是想证明是别人的错。加上他这个人是个比较傲气的人,他可能觉得在他们公司,他是DotNet技术最牛的一个,可是被你们证明他错了,那么他心里自然不舒服了。时间长了, 次数多了,你们之间的关系自然会紧张了。像这种情况,最好的办法就是,你能证明自己是清白的,也能间接提高对方的技术水平。”

退而次之,如果做不到上面那点,可以这样:找到问题原因后,不要说你这个地方的代码不能这么写,要改成怎样怎样,那个地方的代码不能那么些,要怎样怎样。而是应该说:我也不知道改了什么地方,它就好了。如果对方有心,他自然会比较原来的代码,你改了什么地方。进而他回去了解你用了什么技术。如果他无心,你想要证明他错了,那么情况也不会好到什么地方去。

总结:

不要证明别人是错的,只需要证明自己没有错。当你证明别人是错的时候,你就输了。你赢的了芝麻,却输了西瓜;你证明别人错了,那么也就留下了与人相处关系紧张的问题。

遇到问题,只需证明自己是清白的,同时能间接提高对方的技术水平,那就最好不过了。

这应该是很高的境界了吧,值得吾辈深刻学习。