Y nada más cierto, sobre todo si hablamos de desarrollo de software. Con los años me acostumbré a interpretar como nubes en el horizonte lo que para otros es motivo de festejo. ¿Todo avanza sobre ruedas? Mmmm… mala señal. Pongamos por caso…
…que todo comienza con la típica frase apocalíptica “Esto es una pavada”. Que leemos o nos comentan los requerimientos y todo parece sencillo…
…que a partir de ello hemos elaborado una estimación y vuelve a las pocas horas con un escueto “ok”. ¿Ok? ¿No falta nada? ¿No nos olvidamos de algo? ¿No les parce demasiado, o demasiado poco, o muy caro, o muy barato?
…que luego el diseño va surgiendo sin graves problemas, y que después de remover algunas piedras y hacer un par de ajustes menores se termina todo en tiempo y forma.
…que las pruebas no arrojan errores de gravedad…
¿Qué clase de proyecto es ese? Uno que va a explotar como fuegos artificiales.
Lo primero que se me ocurre para justificar lo anterior tiene que ver con las zonas grises, los cambios, los errores.
Todavía suponiendo que -en un proyecto muy particular- los dos primeros elementos –zonas grises y cambios- no estén presentes, el tercero –errores- estará siempre ahí. En cualquier metodología -ya sea ágil, evolutiva o lineal- se establecen puntos de control a lo largo de todo el proyecto y las tareas son divididas –o deberían serlo- de manera tal de que todos los componentes pasen a lo largo del proceso bajo la mirada –supuestamente atenta- de por lo menos dos pares de ojos (aunque con par y medio alcanzaría). Si todo va más o menos bien surgirán incongruencias, malos entendidos, omisiones, errores de interpretación, de diseño, de codificación y de cualquier otro tipo imaginable. Si todo va realmente bien se irán corrigiendo con el tiempo, aunque aparecerán nuevos problemas. Por eso su ausencia es clara señal de que algo anda mal: la ausencia de ladridos indica la ausencia, la distracción o la indiferencia de los perros.
Los sistemas informáticos –incluso los más triviales- son lo suficientemente complejos como para que un componente menor o una situación improbable mas no imposible tire todo abajo. Incluso sin llegar a ese extremo tenemos que recordar que el software en su conjunto –sobre todo el de gestión- es necesariamente un subsistema de un sistema mucho mayor, una organización (el “negocio”). Desde este punto de vista no es más ni menos que un servicio para esa organización. Como pasa con todos los servicios, solamente notamos su presencia a través del sinfín de problemas e incomodidades que surgen cuando andan mal. Y ahí sí que aparecen los perros –pero ahora mostrando los dientes- y será mejor que cabalguemos rápido.
Un ejemplo simple: la falta de un calefactor o uno averiado en invierno puede interrumpir el trabajo por varios días, con todos quejándose amargamente. Si esto no sucede –las quejas, quiero decir- es que a) no hay trabajo que interrumpir, b) la calefacción no hacía falta, c) todos murieron congelados, d) se fue todo el mundo a casa o al bar de la esquina, o… en fin, en todo caso vemos que no es tan malo enterarse de que algo no anda, que peor es hacerlo a último momento o, sobre llovido mojado, que nadie se queje o que las quejas se aplaquen solas ante la falta de solución (¿resignación? ¿abandono?).
Luego, la famosa frase –que no es del Quijote, según revela el oráculo- se aplica también a nivel de empresa u organización… y no necesariamente en cuestiones de infraestructura o servicios: pensemos en la diferencia entre las reacciones ante cada pequeña o gran caída de Google o pifie en Microsoft (el mundo entero se transforma en una gran jauría enfurecida) y el lento, continuo y casi silencioso desangrarse de Yahoo!
Así que ¿problemas? ¿quejas? Cabalgamos.
