核心问题

PM 在 Bug 排查中应该做什么，不应该做什么？

真实场景

线上故障发生后，群里同时出现客户截图、销售催促、老板追问、工程师排查。PM 很容易变成传话筒，也可能因为焦虑不断打断工程师。

真正有价值的 PM，会让信息更清晰，而不是让现场更嘈杂。

常见误区

坏判断是：

PM 不写代码，所以只能催进度。

催促很少能缩短排障时间，反而会增加认知负担。

工程视角

Bug 排查需要三类信息：

  • 复现信息：怎么发生的。
  • 影响信息：影响谁、影响多大。
  • 决策信息：是否回滚、降级、补偿、公告。

PM 的优势在后两类，也能补齐第一类上下文。

PM 可以怎么做

你应该承担这些任务：

  • 收集并整理复现路径。
  • 判断影响范围和优先级。
  • 管理外部沟通节奏。
  • 协助决定是否降级或回滚。
  • 记录时间线，方便复盘。

你不应该做的是：

  • 每两分钟问一次“好了没”。
  • 在没有证据时指定技术原因。
  • 让工程师同时面对多个业务方。

Atlas Action

线上 Bug 出现后，PM 先开一个简短记录：

当前现象：
影响范围：
首次发现时间：
复现路径：
当前负责人：
下一次状态更新时间：

小结

PM 参与 Bug 排查的价值，不是替工程师修代码，而是降低现场混乱度。

信息越清晰，工程排障越快。