Player Unknown’s Bug: ¿Podemos crecer si registramos problemas de causa desconocida?
(engineering.ab180.co)Comparto la historia de cómo, a través de una página de issues creada por casualidad, fuimos fortaleciendo la estabilidad psicológica del equipo y aumentando el intercambio de información para construir una organización y un servicio más sólidos.
Cuando desarrollas, a veces te encuentras con problemas cuya causa no se puede identificar.
En especial en el frontend web, además del estado del servidor y otros factores, influyen muchísimos elementos externos como el tipo o la versión del navegador, o las extensiones de Chrome.
Si no sabemos la causa del problema, o si la causa no está de nuestro lado, de repente me surgió la duda de si solo con un postmortem realmente se puede construir una estructura sólida (si no se queda corto).
Cómo empezó
Una vez tardamos 9 horas en total desde que se reportó un issue de causa desconocida hasta que se dio por cerrado.
Después de dedicar 4 horas al debugging, recién entonces supimos que la causa del problema no estaba en el código interno ni en la infraestructura, sino en un bug de una extensión de Chrome del usuario.
Ya era difícil identificar dónde estaba la causa del problema, pero me enfureció conmigo mismo el hecho de que nos hubiera tomado nada menos que 4 a 5 horas descubrir que la causa era externa.
Creé en Notion una página llamada “Player Unknown’s Bug(PUB)” y, junto con esa frustración, fui organizando lo que intentamos al responder al issue, lo que quedó pendiente y lo que convendría mejorar.
Convertirlo en cultura, y hacerla evolucionar
Al hacer la retrospectiva, hablamos de la causa del issue, de lo que aprendimos adicionalmente al investigarlo y de los puntos en los que hicimos suposiciones equivocadas. Mis compañeros señalaron dudas y aspectos que sería bueno mejorar, y reunimos todo eso para establecer un proceso de respuesta ante incidentes.
Lo bueno de este proceso fue que el equipo empatizó con las dificultades que sentí durante la respuesta al issue, y además fue entretenido compartir lo que habíamos aprendido. También creamos una checklist para poder identificar más rápido problemas similares si vuelven a ocurrir. Se conversó con el equipo y terminó adoptándose como una práctica formal.
La organización de desarrollo de AB180 ya realiza “postmortems” de forma habitual. Si el postmortem interno se centra en Resolution y Action Items, PUB tiene como objetivo Lesson Learn, formar una sensación de seguridad psicológica alrededor de la respuesta a issues y ordenar los factores que conviene revisar primero ante problemas desconocidos.
Una cultura de compartir información de forma voluntaria
A medida que esta práctica se fue asentando en el equipo, también comenzaron a acumularse poco a poco los issues atendidos por otros compañeros.
Durante las retrospectivas, el tiempo de hablar sobre aspectos que no conocíamos y profundizar más empezó a funcionar, aunque fuera en pequeño, como una especie de “sesión de intercambio de conocimiento” voluntaria.
Para impulsar un poco más esta cultura, estamos operando un canal de Slack donde compartimos con frecuencia lo que aprendemos y vamos descubriendo. Hasta ahora ha funcionado bien.
Lesson Learn
- Hay que elevar la seguridad psicológica de todo el equipo que responde a incidentes, y para eso hace falta conversar más.
- Cuando eso no ocurre, los problemas se repiten y se instala en la organización la idea de que “problema = algo de lo que no se debe hablar”.
- Compartir información puede crear seguridad psicológica dentro de la organización, e incluso elevarla.
- Y esta clase de cultura de compartir información quizá puede empezar con algo mucho más pequeño de lo que uno imagina.
5 comentarios
Yo, en cambio, hoy salí del trabajo después de pasarme todo el día lidiando con un incidente que creía que tenía una causa externa muy clara, pero que por circunstancias internas parecía imposible de resolver fácilmente y me tenía completamente frustrado; al final, resultó que se solucionaba simplemente cambiando una sola línea en el archivo de configuración. Al ver este artículo, de verdad me resulta de mucha ayuda.
Hoy también trabajaste muchísimo, de verdad. Aun así, qué bueno que pudiste resolver el problema. A veces también me acuerdo de los problemas que mencioné en el texto de arriba. En ese momento fue difícil, pero ahora siento que puedo tomarlos con alegría.
¿No crees que lo difícil que viviste hoy también podrás recordarlo con una sonrisa cuando pase el tiempo? jaja
Gracias por leer mi humilde texto.
La verdad es que, ni antes ni ahora, nunca he pensado que lidiar con incidentes sea algo disfrutable.
Por ejemplo, el incidente que resolví hoy ocurrió precisamente en un producto donde nuestro equipo tenía bloqueado el acceso directo al servidor de producción, así que, salvo la etapa inicial en la que detectamos el incidente y analizamos lo que estaba pasando, y la etapa final cuando por fin conseguimos permisos de acceso al servidor, no nos quedó más que sentirnos relativamente impotentes. Cuando nuestro equipo pedía que se tomaran ciertas medidas, el equipo de operaciones del servidor las rechazaba por sus propias circunstancias. Y no, no se puede aceptar con gusto esa sensación de impotencia.
Por eso, mientras redactaba el documento de postmortem antes de salir del trabajo, sentí que era más bien algo como: “¡Aunque sea por puro fastidio, la próxima vez no voy a cometer este error!”
Al escuchar lo que nos compartiste, siento que debió de haber sido muy duro para ti. Como dijiste, al dejar de cometer el mismo error una y otra vez, no queda más que ir mejorando poco a poco... snif
En realidad, ese producto es un producto legacy bastante antiguo, no hace mucho que me lo entregaron en la transición, y apenas lo recibí llegó una solicitud de cambio de funcionalidad, así que hace poco sí modifiqué el código, pero era una parte que no tenía absolutamente nada que ver con la falla ocurrida hoy. Por eso, la parte que realmente causó el problema no era algo que yo hubiera escrito directamente, aunque si hubiera conocido ese producto mucho más a fondo, seguramente habría podido resolver el problema más rápido. Eso es lo que de verdad lamento.
Y, de hecho, la estimación sobre la causa de la que estuve convencido al principio, después de confirmar que era una caída total del servicio, en realidad solo era correcta a medias. Creo que esa seguridad en esa estimación fue, más que nada, el verdadero error de hoy.