首先，这个问题有N多没交代清楚的：

①开发是在产品什么阶段改bug？

②改的bug有多大多复杂？

③这个bug的产出原因是什么？

④为什么要“催”？

⑤如果改了，有多大好处？如果不改，有多大风险？

明确了上面几个前提，这个问题就好解了。我来举个例子：

①产品已上线的线上Bug，统计Bug影响人数和程度，人数越多、程度越严重，越需要抓紧修复。上线前的测试Bug，看距离项目上线节点还有多长时间，时间越短，越要抓紧修复。

②越复杂的Bug，越不要过于催促，把Bug拆解成几个子Bug，优先觉得P0级的。

③如果是技术能力问题，找高阶帮忙；如果是产品需求不明确，反而要催产品不是催开发

④如果有项目延期风险，应该找项目经理协调而不是催开发；如果是老板发现了Bug那就给老板预期

⑤当改了之后有重大利好，不改有严重问题时，可以借此去催开发尽快修复，当然也要给与充足的支援。

总结来看，面对bug，不是“催”就能解决的，而是要根据实际情况，提前规避风险，遇到问题，给与充足支持，并做好应急预案，这样才是最优解。