¿Cuándo empieza a hundirse un proyecto?
Todo proyecto informático comienza de manera similar. Hay planes ambiciosos, un cronograma, la presentación de los primeros prototipos y la convicción de que en unos meses la empresa estará usando un sistema moderno. Al principio todo parece prometedor, pero con el tiempo aparecen los primeros retrasos. La fecha se pospone una semana, luego un mes. El número de errores aumenta, la comunicación con el contratista se vuelve cada vez más difícil y las respuestas siguientes suenan: "Un momento más", "Es solo una pequeña corrección" o "Ya estamos en la recta final."
En algún momento resulta que en lugar de un producto acabado, la empresa tiene un proyecto inacabado que nadie quiere asumir.
Es un escenario mucho más habitual de lo que podría parecer.
El mayor problema no es el código
La mayoría de los empresarios asume que si un proyecto no funciona, la culpa es del código mal escrito. Cierto: a veces así es. En la práctica, sin embargo, con mucha más frecuencia el problema está más profundo.
Falta documentación. La arquitectura se fue creando "sobre la marcha". No hay pruebas automáticas. Las integraciones se hicieron de forma provisional. Se añadieron funcionalidades sin analizar su impacto en el sistema completo. Como resultado, incluso un pequeño cambio provoca nuevos errores.
Es un poco como una reforma de una casa sin proyecto. Cada habitación puede terminarse, pero con el tiempo resulta que las paredes no están donde deberían, las instalaciones se hicieron de forma improvisada y la remodelación se vuelve cada vez más costosa.
¿Cuándo conviene decir "alto"?
Uno de los momentos más difíciles para el propietario de la empresa es decidir interrumpir la colaboración con el contratista actual. Muchos empresarios lo retrasan demasiado.
¿Por qué?
Porque el proyecto ya ha consumido mucho dinero.
Porque da lástima el tiempo invertido.
Porque tal vez "todavía se pueda".
La psicología llama a esto el efecto de los costos hundidos. Cuanto más hemos invertido, más difícil es admitir que la dirección actual no lleva a ninguna parte.
Mientras tanto, a veces la mejor decisión no es seguir echando presupuesto al mismo problema, sino detener el proyecto y analizar la situación con calma.
¿Se puede salvar cualquier proyecto?
No. — Y conviene decirlo con honestidad.
Hay proyectos cuya reparación costaría más que construirlos de nuevo. También ocurre que la tecnología usada ya está obsoleta o que la arquitectura fue diseñada de forma que impide el desarrollo futuro.
Por eso el primer paso nunca debe ser prometer soluciones.
El primer paso debe ser una auditoría.
Solo después de analizar con detalle el código, la documentación, la infraestructura y los procesos se puede responder a la pregunta de si conviene más reparar la solución existente o empezar un proyecto nuevo.
Un buen socio tecnológico no dirá lo que el cliente quiere oír.
Dirá lo que es mejor para el negocio.
¿Cómo es rescatar un proyecto en la práctica?
Contrario a lo que parece, no empieza por programar.
Primero hay que entender con qué nos enfrentamos.
Analizamos la arquitectura del sistema, la calidad del código, la forma de comunicación entre módulos, la seguridad de los datos, el rendimiento y las posibilidades de evolución. Revisamos la documentación, el historial de cambios y las tecnologías usadas. A menudo, ya tras unos días se sabe dónde está el problema real.
Solo entonces se elabora un plan de acción.
A veces basta ordenar el código y corregir algunos elementos clave. Otras veces es necesario reestructurar módulos selectos. También sucede que la solución más sensata es crear un sistema nuevo aprovechando lo que ya se ha conseguido.
No hay dos proyectos iguales.
Tampoco hay una única receta para salvarlos.
¿Por qué asumir un proyecto es más difícil que crear uno nuevo?
Es una pregunta que a menudo escuchamos de los clientes.
La respuesta es simple.
Al crear un sistema desde cero conocemos cada decisión de diseño. Sabemos por qué se eligió una solución concreta y cuáles eran los supuestos.
Al asumir el proyecto de otro, primero tenemos que reproducir ese conocimiento.
Es un poco como hacerse cargo de la construcción de una casa después de una cuadrilla que dejó el solar sin planos, sin documentación y sin información sobre lo que ya se hizo.
Por eso rescatar proyectos requiere no solo habilidades de programación, sino también experiencia arquitectónica, analítica y de diseño.
El socio tecnológico debe estar contigo también cuando surgen problemas
Un buen software house no se reconoce por cómo inicia un proyecto.
Se reconoce por cómo reacciona cuando aparecen dificultades.
No todo puede preverse. Cambian los requerimientos de negocio, las tecnologías y las necesidades de los usuarios. Lo clave es si el equipo es capaz de encontrar soluciones, comunicar claramente los riesgos y, junto con el cliente, tomar las mejores decisiones.
Es entonces cuando se construye la confianza.
¿Cómo trabajamos en Web24?
Abordamos los proyectos que requieren asunción con mucha cautela.
No hacemos promesas tras la primera conversación.
Primero analizamos la situación. Verificamos qué se ha hecho, qué se puede aprovechar y qué requerirá reestructuración. Solo después preparamos una recomendación y un plan de acciones.
Nuestro objetivo no es escribir miles de líneas de código más.
Nuestro objetivo es llevar el proyecto al punto en que realmente empiece a apoyar el crecimiento del negocio.
Resumen
Si tu proyecto se ha estancado, el contratista dejó de responder, el cronograma existe solo en teoría y las correcciones sucesivas generan más errores, eso no significa todavía que todo esté perdido.
En muchos casos el problema se puede resolver.
Pero hay que empezar por un paso: un análisis riguroso de la situación.
Porque antes de empezar a rescatar un proyecto, conviene primero averiguar por qué empezó a hundirse.
