Cuánto tarda un software a medida (y por qué se retrasa)

La respuesta corta y honesta: un desarrollo pequeño, de cuatro a ocho semanas; uno mediano, de tres a seis meses; y uno que sustituye a la gestión entera de una empresa, más de un año.

La respuesta útil es otra: lo que decide el plazo casi nunca es la programación. Es cuánto tarda la empresa que lo encarga en contestar, decidir y probar. Esa parte no suele estar en el presupuesto de nadie, y es la que se lleva los meses.

Plazos por tamaño

• Una utilidad concreta (2 a 6 semanas). Un cálculo que hoy se hace en Excel, un generador de documentos, una pantalla que consulta datos que ya existen. Alcance cerrado, poca gente implicada.
• Un módulo dentro de algo que ya funciona (1 a 3 meses). Control de almacén, gestión de partes de trabajo, una zona privada de clientes. El tiempo depende sobre todo de lo bien documentado que esté el sistema al que se engancha.
• Una aplicación completa de un área (3 a 6 meses). Todo el circuito de un departamento: entra, se procesa, sale, se factura, se consulta. Aquí ya hay usuarios distintos, permisos e informes, y aparecen los casos raros que nadie mencionó al principio.
• Sustituir la gestión de la empresa (más de 12 meses). Producción, almacén, facturación y contabilidad. No se hace de golpe ni se debe intentar: se hace por áreas y conviviendo con lo viejo durante un tiempo.
• Migrar de tecnología sin cambiar funciones (variable, y engaña). Suena a trabajo mecánico y no lo es: hay que reproducir veinte años de comportamiento, incluidos los detalles que nadie recuerda pero de los que depende alguien.

En qué se va el tiempo de verdad

Un reparto realista de un proyecto mediano, y la sorpresa es lo poco que ocupa escribir código.

• Entender el negocio (15-20 %). Sentarse con quien hace el trabajo y ver cómo se hace de verdad, que casi nunca coincide con cómo está escrito en el procedimiento. Esta parte parece prescindible y es la que evita rehacerlo todo en el mes cinco.
• Diseñar los datos (10 %). Cómo se guarda cada cosa. Es la decisión más cara de cambiar después: la pantalla se rehace en un día, la estructura de datos con dos años de información dentro no.
• Programar (35-40 %). Sí, poco más de un tercio.
• Probar y corregir (20 %). No solo que funcione: que aguante los datos reales, que son mucho más sucios que los de prueba.
• Migrar los datos viejos (10-15 %). Se subestima siempre. Los datos históricos vienen con duplicados, campos usados para otra cosa de la que fueron creados y códigos que solo entiende quien lleva veinte años ahí.
• Formar y arrancar (5-10 %). Que la gente lo use. Un programa que nadie sabe usar no está terminado.

Las cuatro razones por las que se retrasa

Después de bastantes proyectos, los retrasos se repiten y casi siempre son los mismos cuatro.

• Las decisiones del cliente. «¿Qué pasa si un albarán se factura a medias?» es una pregunta de dos minutos para quien programa y de tres semanas para la empresa, porque hay que preguntar a producción, a administración y al gerente, y no se ponen de acuerdo. Estas preguntas son inevitables y llegan en tandas. Si nadie tiene autoridad para contestarlas rápido, el proyecto se para.
• El alcance que crece sin que nadie lo note. No llega de golpe, llega en peticiones pequeñas y razonables: «ya que estamos, ponle un aviso», «y que salga también por correo». Ninguna cuesta nada. Treinta de ellas son dos meses. La solución no es decir que no: es que cada una se apunte con su coste y su efecto en la fecha, y que se decida a la vista de eso.
• Los datos viejos. Nadie los mira hasta que hay que migrarlos, y entonces aparece que hay tres formas distintas de escribir el mismo cliente y un campo de observaciones que se ha usado durante años para meter la fecha de garantía. Limpiarlo es trabajo de la empresa, no del programador, y hay que empezarlo pronto.
• No haber probado con volumen real. Con treinta registros de prueba todo va rápido. Con los ciento veinte mil de verdad hay pantallas que tardan medio minuto. Encontrar eso en la semana de arranque es lo peor que puede pasar; conviene pasar datos reales mucho antes.

Cómo se acorta un plazo de verdad

• Entregando por partes, y usándolas. Cada tres o cuatro semanas, algo que funciona y que alguien usa en su trabajo. No es una formalidad: es la única forma fiable de descubrir un malentendido en la semana cuatro en vez de en la veinte.
• Poniendo un interlocutor con capacidad de decidir. Una persona que conozca el negocio y pueda contestar sin convocar un comité. Sin eso, el proyecto avanza a la velocidad de la próxima reunión.
• Separando lo imprescindible de lo deseable, por escrito y antes de empezar. Casi siempre hay un 30 % que puede esperar a después de arrancar, y sacarlo de la primera entrega adelanta la fecha de forma inmediata.
• Empezando la limpieza de datos el primer día. Es trabajo de la empresa y se puede hacer en paralelo. Hecho a tiempo, quita semanas del final, que es donde más duelen.

Una advertencia sobre los plazos muy cortos

Si alguien te da un plazo notablemente más corto que el resto por el mismo alcance, la pregunta no es cómo lo consigue: es qué parte no está contando. Normalmente es la de las pruebas, la de la migración de datos o la de la formación, y esas tres no desaparecen: se pagan después, con el programa ya en marcha y la empresa trabajando con él.

Un plazo se puede acortar de verdad recortando alcance. Recortando trabajo, no.