高情商程序员：5种类型的bug沟通有诀窍！

​高情商程序员的眼里，bug是一种自然的存在，他们能够跟相关人员有效地沟通，给自己处理bug争取时间来找到最具性价比的解决方案，以下总结了5种类型bug的有效沟通方法，请收好！

1、自己无法复现的bug

实际工作中，除了测试人员和产品会提bug之外，业务或客服也会提bug，所以对提bug的人最好给他们提供一个模版，让他们描述清楚发现bug的场景（前后操作的步骤），用的版本，浏览器等。

但即便是这样，当拿到bug描述后，即便发给了更多的同事，可能还是无法复现这个bug，此时可以这样跟提bug的人进行沟通：

• 先解释你这里已经找了很多人测试，实在无法复现bug；
• 建议对方可以进行什么操作如清缓存，再看看是否还有这个bug；
• 如果还不行，建议对方最好能录个视频并找同事或朋友也看下是否有同样的问题，并按照你的要求把相关的操作或信息都录进视频中；
• 告诉对方，如果一时半会找不到原因的话，可以用的替代方案是什么。此处非常关键，要让对方感受到你很关心他遇到的问题，而不是只说“复现不了这个bug”，人的情绪感受有时候比bug本身更重要。

对于bug的提出，根据业务场景总结bug描述模版很重要，这样可以避免对方提bug时漏掉细节，要反复沟通的情况，尽量将流程化的沟通模板化，避免彼此时间的耗费。

2、影响程度较小的bug

如果bug的影响的范围较小并且不是主要使用场景时，这时要看当前的项目是否有更紧急的事情。如果会影响项目进度的话，你可以找到产品经理和测试，沟通下这个bug的影响范围以及所需要修复的时间，最重要的是对当前的项目的影响，产品经理一般会根据项目进度来跟相关人员沟通。

假如需要你自己去沟通，那你可以参考以下方法：

• 先说明这个bug的产生原因以及影响的范围大小，大概的处理方法，让对方了解你已经有方案了（这点也是跟对方的感受有关，让对方了解到你重视了）；
• 然后说明当前的项目进度有更重要紧急的事情以及如果不能按时完成，可能会对项目造成的影响；
• 接着补充，你会在有时间的时候就修复这个bug；
• 最后建议，如果对方当前要使用的话，可以尝试什么替代方案。

看到这里，你也看出来，对于这种影响程度小、优先级不是那么高的bug，在跟bug相关人员沟通的时候，一定要让对方感受到你重视，有为他着想，那对方在了解到你的难处之后，也不会多么较真让你当下一定要改，毕竟还有影响范围小这个因素在。

3、需求定义有瑕疵或需求理解有误产生的bug

此类bug多半是产品经理定义的需求有瑕疵或自己开发时没有理解透彻的场景，也属于正常范围。现在大多是敏捷开发，对于复杂的系统，需求定义或讨论时确实会遗漏部分场景或者大家对需求的描述有各自的理解。对于此类的bug，沟通时可参考以下方式：

• 找产品经理确认细节，当时自己的理解可能有误或者需求没有定义这部分的细节，如果是需求没有定义的，那就让产品经理根据项目进度安排进后续的迭代中；如果是自己当时对需求的理解有歧义的，也需要让产品经理明确这部分容易产生歧义的地方，避免后续再发生类似的问题，这种场景如果修复起来不难，可以在当前的迭代里修复掉，如果修复起来较为耗时，可以跟产品沟通根据优先级排进后续的迭代中；
• 跟bug相关人员说明敏捷开发的特点：小步快跑，快速迭代。介于人力资源有限，一些场景后续会逐步迭代进去（这一步如果产品经理去解释的话，开发人员可忽略）；
• 在产品经理补充好bug涉及的需求细节后，需要一起讨论思考下是否还有遗漏的或者理解上可能产生歧义的需求细节；
• 定期总结，什么样的细节会在需求定义时被遗漏或被误解，进而产生了bug，将这类问题都总结下来。在后续其他的需求讨论会中，注意产品经理是否有写进去这些细节，没有的话需要提醒产品经理补充上去。

4、其他人/部门/合作方代码导致的bug

有些bug的产生并不是自己部门的原因，可能是合作方或者其他交叉调用的代码产生的问题，这种情况需要跟合作方一起商讨解决方案并协商好预估的修复时间。此时，对外可以这样沟通解释这种类型的bug：

• 先说明当前bug产生的原因是因为合作方产生的，你已经跟对方沟通了方案和大概的修复时间，让提bug的人有个大概的心理预期大概什么时候能修复；
• 此外，尽量为受影响的人找到临时的替代方案，因为合作方的时间不受自己掌控，对方也有排期，资源分配等流程，所以你为他们找到了个临时的解决方案，虽然不是那么方便，但是可以不影响关键的活动。

5、修改起来耗时，影响项目进度的bug

对于这种修改起来工作量大，会影响项目进度的bug，因为bug的修复等待期长，就需要结合产品经理的力量。首先，自己要评估修改bug的时间，不可控的相关因素，当前任务的优先级，可能的影响。然后，跟产品经理沟通，尽量将bug相关的内容进行分解，把影响层面最大的那部分场景先修复掉，其他场景可以排在后续的迭代中分批或一次性更改（这个看具体情况）。在你们有结论之后，可以参考以下方式跟bug相关的人员进行沟通：

• 首先，还是解释你已经查明了bug的原因，但这个因为涉及到一些历史遗漏或者对其他项目的影响等问题，改起来比较耗时或有风险；
• 接着，说明当前项目的任务比较紧，你和产品经理评估下来，你们已经分解了这个bug的修复步骤，把影响最大的bug尽快会修复掉；
• 被分解后的影响不是那么大的bug，需要“见缝插针”地找时间修改，不能立马解决，但你预估大概什么时间点可以（此处的预估时间点可多留点风险时长，避免给了别人期待又让人失望）；
• 继续，还是尽量给人家提供一个暂时的替代方案，可以是相对手动点的方案，但是总好过没有方案；
• 最后，给别人强化下当前任务的紧急度和影响，以及如果现在直接修复这个bug会产生的影响，并表明自己会尽量找时间修复的。（其实还是照顾别人的感受，让对方感受到你积极响应的态度，这样对方大多都会同理地理解你的难处）。

Bug是分等级的，一些重要紧急bug自然是要尽快修改掉，但一些bug是需要根据场景，时间段，资源等综合考虑修复时间的，而这个过程中，如果提bug的人不知道你为什么不能很快修复bug，自然会产生一些负面的情绪。所以，及时的确定方案，找当事人沟通清楚，让对方感知到你有在关注他的感受，也需要对方谅解你的处境，那很多关于bug何时修复的沟通也可以变得很和谐。

话说了这么多，不练还是不知道怎么弄，那就去练一练，试一试吧！

如果觉得文章不错，记得关注，点赞，分享哦，后续还有更多干货持续输出！