Y es que esto es algo que antes o después ocurre, fallamos en el diseño de una arquitectura, hacemos checkin de código que no compila, tomamos una decisión de implementación totalmente desafortunada, o cualquiera de las múltiples situaciones que se nos dan en un proyecto.

Es algo que nos va a ocurrir, no en vano los errores nos ocurren en nuestra vida diaria, ese típico creo que puedo cargar con un plato más de camino a la cocina que acaba en tragedia, o esta bolsa seguro que aguanta este peso (curiosamente la bolsa dónde llevamos las botellas de cerveza), o más serios como ese típico mensaje/correo que justo cuando le das a enviar, te das cuenta de que lo estás enviando a la persona equivocada, y el contenido, ejem, dejémoslo ahí …

Los errores ocurren, somos humanos, y no podemos evitarlos, tenemos que aprender a convivir con ellos.

Lo realmente importante de esto, es como reaccionamos ante ellos. Para mí es más importante, como cliente, el como alguien me soluciona un fallo, que alguien que “presuntamente” no tiene fallos.

Nuestro primer paso siempre será reconocer el error (es difícil eh), de nada nos valdrá ocultarlo, no va a desaparecer.

Ahora que ya sabemos, y hemos puesto en común el error cometido, lo siguiente es ver la gravedad del error. No todos los errores son igual de graves o de preocupantes, habrá fallos, que simplemente sepamos que tenemos, cuya única acción sea “saber que está ahí”, y vivir con el. No vivir eternamente claro está (o sí …), pero que no sea necesario tomar una acción de modo inmediato.

En el caso de que la gravedad del asunto requiera tomar acciones inmediatas, el resolver este error debe ser prioritario. Es igual que el principio de no desarrollar funcionalidades nuevas mientras haya bugs abiertos.

Por supuesto, en una situación ideal, en la que tengamos una matriz de riesgos, dónde aparezca esta situación, tendríamos un “plan de contingencia”. Pero como suelen decir los americanos, “shit happens”, y no siempre vamos a tener la suerte de tener un plan de contingencia. Esto tampoco debe desanimarnos, las cosas ocurren.

Cada error es un mundo, y no es lo mismo un fallo de diseño que uno en los requerimientos, y desde aquí no pretendo dar una solución universal a la solución de errores.

Lo realmente importante es que cuando detectemos un error por primera vez, el flujo no se convierta en el gráfico que acompaña este post, en el que lo que se intenta es ocultarlo, escurrir el bulto, colarselo a alguien, en defnitiva escapar del problema.

Reitero, el flujo siempre pasa por la comunicación, el famoso triage para evaluar su gravedad, y el tomar las acciones correctivas necesarias antes de continuar, y que el error nos genere un efecto bola de nieve.

Y bueno, cuanto rollo para esta pequeña conclusión, pero es que hoy no estaba demasiado inspirado jeje.

Ahh si, por supuesto, feliz año nuevo a todos, y espero que se cumplan todos vuestros propósitos.

En cuanto a mi, como decía Joe Strummer, “the future is unwritten”, así que simplemente espero ir mejorando día a día, aprendiendo, descubriendo, viajando, y pudiendo hacer las cosas que me mantienen vivo y “despierto” día a día, y dejemos que cada día nos vaya descubriendo nuevas cosas para hacer.

Y también deciros, que no, este año tampoco os libráis de mí, ya me han reconfirmado como MVP de Team System para el 2009 :), muchas gracias a todos los que me leéis, que suponéis una motivación extra para mi.