La importancia de las lecciones aprendidas

La resiliencia es un concepto que me encanta; aunque tiene muchas acepciones distintas, yo me quedo con aquella sobre la capacidad que tenemos de afrontar situaciones complicadas y resolverlas, aprendiendo de ellas y saliendo airosos y fortalecidos. La experiencia nos puede destruir, pero también nos puede fortalecer, todo depende de la actitud con la que la afrontemos.

Este concepto de corte más bien psicológico, lo aplico desde hace años de manera natural a los proyectos software en los que participo. En definitiva, lo que intento es aprender de los errores y mejorar todo aquello que pueda ser mejorable, ni más ni menos. El efecto de esto es que con el tiempo vamos acumulando mejores conocimientos, mejores formas de hacer las cosas y de encarar los proyectos. Lo peor en cualquier proyecto es que en algún momento podamos sentir eso de tropezar con la misma piedra de nuevo.

Pero, ¿hay algo que mejorar? Es imposible aprender de las situaciones si antes ni siquiera nos planteamos la duda de si existe algo por mejorar. Me temo que en nuestro sector hay a veces demasiada soberbia que impide reconocer los errores. 

Siempre hay algo que mejorar; si tenemos la valentía y humildad de reconocerlo, nos convertiremos poco a poco en mejores profesionales.

Se mejora continuamente cuando tenemos instaurada esta capacidad de mejora como un hábito en el día a día. Para ello, cada vez que termino un nuevo proyecto o un sprint de desarrollo, me gusta evaluar todo aquello mejorable y en ocasiones plantear una sesión de tipo que yo mismo llamo de "Lecciones aprendidas" en la que todos los miembros del equipo, incluido yo mismo, reconocemos en qué nos hemos podido equivocar e identificamos todo aquello que podríamos mejorar para el siguiente proyecto.

En estas sesiones vale comentar de todo: problemas técnicos, de falta de recursos, falta de buena comunicación con el cliente, todo aquello que haya podido afectar negativamente a la marcha de un proyecto. 

Puesto que estamos hablando de software, las siguientes preguntas son recurrentes en cualquier sesión de lecciones aprendidas independientemente de la naturaleza del proyecto en particular:

• Si se han producido desviaciones signitivativas en las fechas de entrega, ¿a qué se ha debido? ¿Qué medidas podríamos tomar para evitarlo en el siguiente proyecto?
• ¿Se ha ajustado el desarrollo en su mayor parte a lo especificado? No es extraño que el cliente corrija o intente añadir funcionalidad no indicada incialmente; aunque esto es normal y habitual, sí es un peligro cuando se intenta incluir todo ese paquete de requerimientos no cotizados en el mismo proyecto sin cambiar fechas ni estimaciones económicas. Para esto, el interlocutor con el cliente debe ser muy diplomático y firme de manera que no se afecte perjudicialmente al equipo de trabajo.
• ¿Se han generado correctamente todos los artefactos esperados del proyecto? Según el proyecto, documentación de despliegue, guía de usuario, de mantenimiento, etc.
• Una vez en producción o entregado el proyecto al cliente, ¿se han encontrado errores graves? Si es así, es que algo no se ha hecho bien en las pruebas del proyecto.
• ¿Se ha hecho el suficiente trabajo de refactorings y de código limpio para que el proyecto quede prístino, claro, sencillo y abordable para retomarlo en el futuro?

Cada proyecto indicará el tipo de evaluación que se pueda hacer. Lo importante es salir de un proyecto terminado con conocimientos más sólidos y una experiencia más amplia para que el siguiente proyecto no presente, al menos, el mismo tipo de problemas, y, lógicamente, mantener un cliente muy satisfecho con el trabajo realizado y que continúe confiando en ti o en tu empresa para nuevos proyectos.

La solvencia técnica y el buen saber hacer no se demuestra al final de un proyecto, sino en todo momento durante el mismo y el cliente es eso lo que tiene que percibir.

El problema fundamental de querer y poder enfrentarte a este tipo de sesiones positivas en cualquier entorno laboral es la falta de cultura de reconocimiento del error: ¿cómo vamos a reconocer que algo no se ha hecho del todo bien cuando creemos que nuestro jefe sólo nos va a tener en cuenta si piensa que todo lo hacemos a la perfección? ¿Cómo nos vamos a diferenciar de otros compañeros / competidores que quieren de mostrar igual que tú lo buenos que son? Nuestro jefe pronto se va a dar cuenta de que nadie lo hace todo bien siempre. 

Para mí, reconocer el error es el primer paso a la excelencia, la única actitud que nos puede hacer mejorar, y más aún en software, donde hay tantos elementos distintos en cualquier proyecto donde meter la pata.

Si no aprendemos de la experiencia, mal vamos. Como digo siempre (y parafraseando al gran Raimón Samsó), "si no mejoramos, es que empeoramos".