Un proyecto de software a medida rara vez fracasa por un problema técnico. Fracasa por decisiones que nadie tomó a tiempo y que el equipo de desarrollo terminó tomando por su cuenta, sin saber que las estaba tomando.
Estos son los cinco fallos que más veces se repiten.
1. Listar funcionalidades en lugar de definir reglas
El documento de requerimientos habitual enumera pantallas: "necesitamos un módulo de aprobaciones", "queremos un reporte de ventas". Eso no es una definición, es un índice.
Lo que decide si el software funciona son las reglas que hay debajo. Quién puede aprobar y hasta qué monto. Qué pasa si la persona que aprueba está de vacaciones. Si un documento aprobado se puede modificar después. Qué se considera una venta: la orden, la factura o el cobro.
Cuando esas reglas no están escritas, el equipo de desarrollo elige una interpretación razonable y sigue adelante. El problema aparece meses después, en producción, cuando alguien descubre que el sistema hace algo distinto de lo que su área daba por supuesto.
2. Diseñar solo para quien usa, no para quien administra
Casi todos los proyectos definen bien la experiencia del usuario final y olvidan el perfil administrativo: quien carga los datos maestros, crea los usuarios, corrige un registro mal ingresado o publica un contenido nuevo.
Ese perfil es el que decide si el sistema sobrevive. Si cada cambio de catálogo, cada usuario nuevo o cada corrección exige abrir un ticket al proveedor, la organización empieza a resolver por fuera —en una hoja de cálculo paralela— y el software se abandona sin que nadie lo declare.
3. Confundir escalabilidad con infraestructura
"Que escale" suele traducirse en contratar un servidor mayor. Pero un sistema que funcionaba con diez mil registros y va lento con doscientos mil no tiene un problema de máquina: tiene un problema de diseño de consultas o de arquitectura. Añadir infraestructura pospone el síntoma y encarece la factura mensual.
La pregunta útil en la fase de diseño no es cuántos usuarios habrá, sino qué operación crece más rápido y qué pasa cuando esa tabla multiplique su tamaño por veinte. Eso sí cambia decisiones concretas: cómo se indexa, qué se calcula al vuelo y qué se precalcula, dónde conviene separar responsabilidades.
4. Tratar el mantenimiento como una fase posterior
El mantenimiento no empieza cuando el proyecto termina: se decide mientras se construye. Si no hay pruebas sobre lo crítico, si desplegar exige intervención manual y ventana nocturna, si nadie documentó cómo se reconstruye el entorno, entonces cada cambio futuro será caro y arriesgado desde el primer día.
Esto es lo que distingue un sistema que se puede evolucionar de uno que en tres años habrá que modernizar entero.
5. Comparar presupuestos que no cubren lo mismo
Dos propuestas por "el mismo sistema" casi nunca lo son. Una incluye integrarse con el ERP y la otra no. Una contempla migrar los datos históricos y la otra asume que se empieza en blanco. Una entrega el código y la otra lo retiene.
Elegir por el número final, sin comparar alcance línea por línea, es la forma más frecuente de terminar pagando dos veces: primero lo barato y después lo que faltaba.
Lo que conviene tener por escrito antes de empezar
Tres cosas, y ninguna es técnica:
- Qué sistema es dueño de cada dato importante. Si el proyecto se va a integrar con lo que ya existe, esta decisión viene antes que cualquier API.
- Qué procesos entran y cuáles quedan fuera, incluidos los que conviene ordenar antes de automatizar.
- Quién decide cuando aparezca una ambigüedad, porque va a aparecer.
Con eso resuelto, las discusiones del proyecto pasan a ser sobre cómo construirlo. Sin eso, serán sobre qué había que construir, y esa discusión cuesta mucho más tarde que temprano.
- software a medida
- gestión de proyectos
- arquitectura