Los errores en un proyecto software son algo habitual, algo con lo que lidiar cada día. Se calcula que una aplicación web tiene una media de 4 errores por cada punto de función (contando 1 punto de función como unas 50-55 líneas aproximadamente de código Java).

Recuerdo incluso haber leído en mis tiempos de Universidad que, en la construcción de cierto sistema operativo, por cada 3 bugs corregidos se introducían 2 nuevos. Quizás una aplicación web no tenga la complejidad de ese sistema operativo pero no me resultaría extraño si alguien me dijera que en ese caso la relación fuese de 3 a 1.

Los errores al programar no son los únicos fallos que puede cometer un equipo de desarrollo. Pueden haberse entendido mal las especificaciones. Pueden haber olvidado copiar un archivo en un despliegue o no haber concretado lo suficiente un requerimiento. Oportunidades para equivocarse hay muchas.

Si ante cada error afeamos la conducta al que lo cometió e insistimos en encontrar al culpable para señalarlo con el dedo sólo vamos a conseguir que el equipo de trabajo esté más preocupado de salvar su pellejo que de hacer su trabajo lo mejor que sabe. Se tenderá a argumentar y argumentar en la documentación para justificar el porqué de las decisiones y dejar claro quién fue el que tomó la decisión.

En inglés hay un término llamado ‘CYA (cover your ass)‘ para indicar cuando se están tomando acciones sólo para protegerse las espaldas. Se dice también que cuando no tienes que emplear una mano en tapar tus vergüenzas puedes contar con las dos manos para trabajar mejor.

Si logramos en nuestros equipos una cultura ‘No need to CYA‘ podremos trabajar más tranquilos y ocuparnos sólo en entregar nuestro trabajo. Si alguien comete un error, bueno, quizás la próxima vez sea uno mismo quién lo cometa. Se asume, se explica, se toman las acciones necesarias para corregirlo y se avanza a la siguiente tarea. Es más rápido y más efectivo que estar buscando al culpable entre acusaciones cruzadas.

Referencias: