por Duncan MacKenzie
Hace un tiempo alguien me comentó que su grupo era una ‘organización de aprendizaje’ (learning organization) y por eso fomentaron la capacitación continua, organizaron campamentos de entrenamiento, almuerzos y aprendizajes, etc.
Apoyo mucho la capacitación formal e informal continua, pero me di cuenta de que esto no era completamente lo que tenía en mente cuando describí a nuestro equipo como una organización de aprendizaje.
La naturaleza del software, y probablemente todas las formas de trabajo, es que las cosas salen mal, todo el tiempo. Es decir, algo mal hecho puede ser pequeño, como quedarse atascado en un error durante unas horas, o un problema menor que se envía a producción… o puede ser enorme, como eliminar una tonelada de registros en una base de datos de producción y tener que restaurar desde una copia de seguridad (eso fue yo). En todos los casos, mi idea de una organización de aprendizaje se centra en lo que aprendimos del incidente y las mejoras que se derivan de él.
Puede tomar esto como una obviedad, debemos aprender de nuestros errores, pero se nota mucho cuando está sucediendo o no a nivel organizacional.
Cuando algo sale mal, debemos tener dos prioridades clave:
- Tenemos que solucionar el problema si está en curso: debatir por qué sucedió algo, o quién es el responsable, cuando algo está ocurriendo activamente no es útil.
- Esta es la cualidad clave absoluta de un equipo de ingeniería de aprendizaje: debemos averiguar qué hacer para evitar que este tipo de problema vuelva a suceder.
Formalizamos nuestro aprendizaje para reparaciones cuando estas tratan de un problemas importantes, como una interrupción, pero también debemos aprender de nuestros pequeños errores.
Tal vez necesitamos mejores unidades de testing, o necesitamos construir un sistema para las pruebas de integración, o tal vez solo necesitamos aprender a reducir la velocidad y revisar nuestro propio código.
Cuando veo que algo sale mal, a menudo pregunto por qué sucedió y, a veces, eso resulta en disculpas y que la gente ‘asuma la culpa’. No me importa eso, una disculpa es una manera de demostrar que comprendes el impacto de tu error, y asumir la culpa (cuando es debido) es mucho mejor que señalar a otra persona o actuar como si fuera inevitable. Aunque no es lo que busco.
Mi objetivo al hacer la pregunta es comprender lo que aprendimos e, idealmente, obtener una lista de lo que vamos a cambiar en nuestro proceso o sistema para evitar que vuelva a suceder. En su mayor parte, en nuestro equipo, todos se hacen esa pregunta. Mi trabajo es hacer espacio para el trabajo de reparación, dejar en claro qué es importante y asegurarme de que se celebre mejorar las cosas después de un problema.
Si cada problema conduce a trabajar para prevenir incidencias futuras, la calidad de nuestro sistema subyacente aumentará constantemente.
Entonces sí, es increíble cuando un equipo toma tiempo para entrenar. El apoyo al aprendizaje continuo debe ser parte de la cultura, pero la clave para mejorar día tras día es asegurarse de que cada error se convierta en una mejora.
Fuente: https://www.duncanmackenzie.net/blog/a-learning-organization/
