背锅的艺术:需求临时变更上线后出事故谁的锅

按照已确认的需求,代码都快要上线了,产品提出需求变更,匆匆改完代码上线后导致重大 bug,锅(责任)应该是研发还是产品来背呢?

工作中背锅是常态。柱哥想说:背锅不可怕,背了无数口锅还没有一点长进才是最可怕的。

下面我们聊聊如何更有效的背锅:

分锅原则

首先,我们需要明确责任原则:谁执行谁负责。
这种场景下,代码开发和最终上线的的是研发同学(RD 和 QA)的执行的,事故的主要责任是在研发同学了,产品同学变更需求只是一个诱因,所以这个锅没得甩了,只能默默的背着吧。

背锅甩锅的艺术

当然,背锅大家都是不愿意的,特别是这种好心办坏事的锅背的那就更是有点冤了,那我们怎么更好的处理才能更好呢。个人建议主要如下:

不留机会

需求变更慎重评估,坚持流程和原则。需求的变更,特别是快上线前的变更,一定要慎重评估对系统稳定性的影响范围,我们要坚持三条原则:

  • 就是尽不做变更,非核心需求留到下一个版本迭代
  • 如果要变更就要整体做评估,并调整上线计划
  • RD 不要做私活,变更至少团队内三方讨论达成共识(PM,RD,QA)

特别是第三点,实际工作比较常见的情况是 PM 和 RD 同学私下协商后变更了需求,没通知 QA 同学,结果导致线上出现严重 bug。典型的好心干了一件坏事。

正确的背锅

这种情况下,如果你接受的需求变更,锅来了,最好的方式就是用最积极态度去背锅,快速的解决问题。因为我们已经接受了需求的变更,也就是我们做出了承诺,就需要对自己的承诺负责。

无论后面是出任何问题,责任都是我们的,这个时候去抱怨需求变更等等都不是一个负责任的表现,都会损害我们的靠谱指数的。

反而承担责任,快速解决问题,会进一步增加靠谱指数。

漂亮的背锅

背了锅,承担了责任,如果我们更进一步去做一个根本原因分析,做个深度复盘,那这个锅其实背的还是比较值得的。因为通过复盘,可以有两个方面的收获:

  • 个人提升:可以进一步认清问题的深层次的原因,看在做事的方法方式和做事原则上是不是可以进一步改进提高,让个人变的做事更加靠谱
  • 团队贡献: 可以去分析是不是团队内其他人也会出现类似的问题,是不是流程机制上需要改进,进一步推动团队的工作流程的升级,这样就有了更高的团队视野

总结

正确的认识和面对背锅和甩锅,我们都会有不一样的收获。事前,尽量不留被甩锅的机会。承诺了,出问题锅就是我的,主动承担责任,不去想着甩锅。事后,积极从个人和团队视角做深度的分析和复盘,提升能力和视野。

总之,以终为始,解决问题是最为优先的。

posted @ 2020-06-01 10:19  peida  阅读(765)  评论(0编辑  收藏