Los que me seguís en Twitter habréis visto mis comentarios de los últimos días, ahora es el momento de detallarlo un poco más.

Una compañía del grupo (pequeña, 20-30 usuarios) de la que nos desvinculamos hace unos meses ha realizado el arranque de un sistema. Durante el desarrollo nuestro departamento había dado soporte en cuanto a arquitectura técnica (comunicaciones, servidores) y entorno de desarrollo (lenguajes, estándares de programación, modelo de datos) pero los sistemas (uno web y otro local) habían sido desarrollado por un proveedor externo y por un desarrollador propio de esa compañía. Lo último que sabíamos nosotros, justo antes de la venta, es que la infraestructura y la aplicación externa funcionaban en las pruebas realizadas y se estaba completando el desarrollo interno.

El lunes me llama el director general de esa compañía para contarme que el arranque había sido un desastre y que habían tenido que volver a las aplicaciones anteriores. Y que quiere un informe de qué habría que hacer para volver a poner en marcha esos sistemas.

Un par de días de entrevista y revisión de datos y un resultado desolador. Errores de programa imposibles de no detectar por el programador o el usuario en una prueba medianamente rigurosa, inconsistencias de datos entre aplicaciones y algunas carencias funcionales, tampoco hubo soporte durante el arranque: el desarrollador de vacaciones y el “padrino ” de la aplicación, lo mismo. Así, las incidencias se acumularon hasta hacer imposible el trabajo.

Me parece de una irresponsabilidad total de todas las partes lo sucedido: ni el desarrollador ni el “propietario” de la aplicación pueden irse de vacaciones el día del arranque, no se puede arrancar si los usuarios no han probado de forma medianamente seria, hay que verificar las conversiones por si se ha actualizado alguno de los sistemas…

Si la dirección no da a estas cosas la importancia que tiene, implicando a los usuarios, planificando las fechas de arranque con los recursos disponibles (no solo para soporte, también para la prueba de usuario que no se hizo porque “estábamos bajo mínimos de personal”). Incluso nos deberían haber implicado a nosotros, que conocíamos parte del sistema, aunque luego les facturaramos las horas (que no lo habríamos hecho). El analista-programador no puede limitar su prueba a qué no de errores y a que "el número de registros cuadre entre las aplicaciones" (explicado por él, literalmente).

Y ahora tengo que hacer un informe que trascenderá del director general al consejo. No sé como explicar lo que se ha hecho mal sin ganarme enemigos de por vida. La receta es de “primero de sistemas” (por favor, sin polémicas sobre telecos, informáticos o asimilados): prueba unitaria, integrada, prueba de usuario, migración y revisión de datos, paralelo y arranque real (con soporte del equipo de desarrollo).

Pero sobre todo, si realmente el arranque de un sistema que soporta la operativa de la compañía es importante (que lo parece), hay que dedicar tiempo y recursos a que salga bien. No se puede tirar adelante y esperar a ver que pasa. Y si en la filosofía de la compañía no está eso de planificar, ni sistemas, ni nada arrancará de forma correcta. Y, por desgracia, esto es aplicable a una gran parte de nuestro tejido empresarial.