El invitado experto: Jordi Sesmero «La cultura de aprender de los errores»

Esta semana contamos en la sección de «El invitado experto a Jordi Sesmero, desarrollador de software en Telefonica, que nos viene a hablar sobre el potencial de aprender de los errores cuando está dentro de la cultura de la empresa. Tenéis la bio y datos de contacto al final del artículo:

Siglo XIX: Parar el golpe. Todo comenzó como un método de detección de problemas en telares: A finales del siglo XIX, Sakichi Toyoda ideó un método que paraba la producción cuando un hilo se rompía, evitando que se produjeran productos defectuosos en los telares. Este concepto lo bautizaron como “jidoka” (traducible como automatización con toque humano).

Siglo XX: Produce lo que necesitas, cuando lo necesitas, en la cantidad que se necesita: Lo importante para que esto ocurra es la colaboración conjunta de directivos, mandos intermedios y operarios. La clave del Lean está en la Mejora Continua, en todos los sentidos. El operario a pie de fábrica, el desarrollador que crea el código, o el agente social a pie de calle pueden detectar fallos que difícilmente un directivo puede visualizar. También en el sentido contrario, desde el equipo directivo, analizar puntos de mejora continua.

Aprende de tus golpes, anticípate a ellos: Para poder aprender de los fallos se pueden realizar tres ceremonias, cuyo propósito es totalmente distinto:

• Retrospectiva: Se deben hacer periódicamente, y favorecen el ambiente para que cualquier empleado del equipo pueda dar su opinión y su estado de ánimo (Niko-Niko). Generan unión en el equipo, quitan tensiones y dan feedback (win-win!).

• Análisis de Causa Raíz: Se utilizan para aprender de los errores, por desastrosos que sean, y encontrar qué partes de la cadena de producción fallaron y por qué. No se trata de señalar a nadie, se trata de encontrar la causa del fallo.

• Post-Mortem: A veces un producto (o hasta una empresa) fallan. Es similar a una retrospectiva, pero más focalizada.

Retrospectiva: Revisa periódicamente cómo lo estás haciendo. Es el momento de aceptar la crítica y el feedback:

• Todos los miembros del equipo comparten TRES cosas a mantener y TRES cosas a mejorar.  

• Es buena idea que las traigan preparadas antes de la reunión, para utilizar el mínimo tiempo posible.

• Se vota a un número determinado de puntos a mejorar, y se decide una acción para mejorarlos. Se designa un responsable de asegurar que la acción se lleva a cabo.

• Se deben hacer periódicamente, a ser posible de forma mensual. 

• En cada retrospectiva se debe repasar que los puntos de acción acordados anteriormente se han cumplido.

Causa raíz: Analiza dónde te equivocaste: En caso de errores en la cadena de producción, es buena idea encontrar qué los produjo. Normalmente se centra en los siguientes puntos:

• Descripción. Explicación detallada de qué ocurrió y cuándo.
  Ej: la madrugada del viernes 6 de Noviembre, tras la instalación del nuevo cableado se produjo una caída del sistema eléctrico.

• Impacto. Cuáles fueron las consecuencias.
  Ej: los clientes del área del Eixample de Barcelona se quedaron sin servicio durante tres horas.

• Cómo se llegó al fallo. Se debe revisar qué partes de la cadena de producción produjeron el problema.
  Ej: cuando se analizó la potencia necesaria para el cableado, no se tuvo en cuenta que en el área hay una fábrica que consume mucha electricidad de madrugada. Los operarios tomaron del almacén un cableado erróneo, que estaba mal etiquetado, etc…

Análisis forense: Post-mortem: A veces, los proyectos simplemente acaban desapareciendo, sea cual sea la razón. El post-mortem no es tanto para evitar que se cierre, si no para aprender de los errores. Se pide a los miembros del equipo que compartan con el resto al menos una cosa en cada uno de los puntos de las llamadas 4L.

• Liked. ¿Qué te gustó realmente del proyecto? ¿En particular, qué fue mejor de lo esperado? Enfatiza lo positivo.

• Learned. ¿Qué nuevas cosas tú/el equipo hicimos durante el proyecto? Pueden ser cosas técnicas (ej: testeo automático), o no técnicas (una nueva y efectiva forma de mantener a los stakeholders informados).

• Lacked. ¿Qué cosas tú/el equipo podríamos haber hecho mejor durante todo el proyecto?

• Longed For. ¿Qué cosas el equipo hubiera deseado tener que no estuvieran disponibles? De nuevo puede ser técnico, o no.

• También se comparten fechas relevantes para el proyecto, como primera puesta en producción, o primer cliente.

Hay otras plantillas para este análisis.

En resumidas cuentas, debemos asumir que es imposible hacer todo bien a la primera y tener mecanismos para detectarlos lo antes posible. Finalmente, cuando los mecanismos de detección fallan, debemos revisar por qué no han funcionado y si podríamos haber hecho algo para evitarlo.

Jordi Sesmero, Ingeniero Informático con especialización TICMA (Technologies, Information, Communication and Audiovisual Media Technologies) de la UPF. Cuenta con experiencia de más de 15 años en investigación, desarrollo y gestión de equipos. Antiguo profesor asociado de la UPF. Desarrollador homebrew para ZX Spectrum con juegos como Misifu o MS Pacman.

Para recibir el resumen de noticias por mail todas las mañanas y ser el primero en compartirlas con tus amigos subscríbete aquí:

Por favor, deja este campo vacío

Comprueba tu bandeja de entrada o de spam ahora para confirmar tu suscripción.