No es mi culpa

"Si culpas a tus empleados, eres un mal manager. Los contrataste, los aceptaste, los supervisaste y dirigiste su entrenamiento. Eres el responsable. Si no te gusta lo que está sucediendo, observa tu propio comportamiento. Pero, si hay crédito para dar, es de ellos." Gerald Weinberg

Sigo con la serie "No hagas lo que yo hice" que inicie hace un tiempo. Esta vez se trata de un pensamiento que he tenido más de una vez: "No es mi culpa". Esta es una de las cosas más nocivas que uno puede pensar cuando trabaja en equipo, mucho más cuando coordina un equipo.

En un proyecto tuve que trabajar con dos estudiantes que estaban haciendo sus primeros pasos en el desarrollo de software. Conocían las herramientas de desarrollo que estábamos utilizando pero no habían participado nunca de un proyecto más allá de los trabajos para la universidad y carecían de algunos conocimientos importantes como diseño orientado a objetos.
Yo había iniciado el desarrollo del proyecto definiendo algunas cuestiones arquitectónicas para el manejo de la persistencia, la validación de errores y algunas otras cosas. Luego debí dejar el desarrollo para ocuparme de otras tareas, pero seguía el avance del proyecto. El problema no era sólo que el avance no era el esperado. La sensación que tenía en aquellos momentos cuando me ponían al tanto del estado del proyecto era que se estaba haciendo todo mal.

Una y otra vez se perdían modificaciones en el código por un mal uso de la herramienta de manejo de versiones, y siempre el origen de todo era, supuestamente, alguna falla de SourceSafe. Yo pensaba, "Vamos, SourceSafe tiene sus problemas pero sé que se puede hacer un check-in sin perder información si lo hago bien...". Luego observaba que el código estaba repleto de declaraciones de atributos enteros con signo de 16 bits (Integer en Visual Basic) cuando los valores posibles para esos atributos iban mucho mas allá de los límites de este tipo de datos. "¡Genial! Ahora nuestra aplicación es un campo minado de posibles errores de overflow esperando estallar cuando quiera utilizar un valor tan grande como... 32679". Los casos de uso que supuestamente estaban terminados, y que debían estar listos hace 2 semanas, tenían errores tan grotescos que no soportaban un smoke test mínimo. En realidad, no es que saliera humo al probarlos. ¡Se desataba un espectáculo de fuegos artificiales en el cielo cada vez que se ejecutaba la aplicación!

"¡¡¡GGRRRR!!! ¡Están haciendo todo mal!"

Es terrible tener ese pensamiento. Es injusto porque cuando uno trabaja en equipo siempre tiene algo que ver con los resultados y es poco práctico porque si siempre pienso que la culpa de todo la tiene otra persona, es poco lo que puedo hacer para mejorar las cosas. Y, al final, no hago nada.

¿Por qué no se capacito a esas personas para manejar las herramientas de control de versión antes que tengan que utilizarlas en un proyecto?
¿Por qué no se replanifican las iteraciones si vemos que la realidad no se adapta a nuestros planes?
¿Por qué nadie verifica que las personas que toman decisiones de diseño están capacitadas para hacerlo o cuentan con alguien que las ayude para hacerlo?
¿Por qué no se analizan cuales son los motivos de los errores, cuales son las fallas en nuestra manera de trabajar, como podemos merjorarla, que técnicas podemos utilizar?

Hacerse este tipo de preguntas puede ser doloroso. Porque los problemas de un proyecto pueden ser el reflejo de las limitaciones propias. Es mucho más fácil asignarle las culpas a otras personas, más aún si son nuevas en la empresa o con menos responsabilidad. Eso no está bien.