Qué cuesta el software a medida, y qué determina realmente la cifra

No vamos a publicar una lista de precios, y debería desconfiar de quien lo haga. Una cifra que no se ha encontrado con sus requisitos es una cifra de marketing, y su propósito es iniciar una conversación, no ser exacta. Lo que sí podemos hacer es explicar qué mueve la cifra, para que pueda leer los presupuestos que reciba y distinguir uno barato de uno incompleto.

Por qué un mismo encargo recibe presupuestos tan dispares

Tres razones, y solo una tiene que ver con las tarifas.

El primero es la interpretación del alcance. «Un CRM para nuestro equipo comercial» puede ser una lista de oportunidades con recordatorios, o un sistema con generación de presupuestos, flujo de aprobación, integración telefónica e informes por territorio. Ambas lecturas son honestas. Los presupuestos difieren en un factor de diez.

El segundo es qué incluye el precio. Algunos presupuestos cubren solo el desarrollo. Otros incluyen el análisis inicial, la migración de datos, el funcionamiento en paralelo, la formación, el despliegue, un periodo de soporte y las correcciones que siguen al primer contacto con usuarios reales. El segundo suele ser la cifra mayor y casi siempre el total menor, porque el trabajo excluido tiene que hacerse igualmente.

El tercero es la tarifa, y es el que menos importa de los tres. Un equipo a mitad de tarifa que tarda tres veces más no es más barato, y un desarrollo que hay que rehacer no es barato a ninguna tarifa.

Las siete cosas que más mueven la cifra

1. El número de roles de usuario distintosCada rol es un conjunto distinto de pantallas, permisos y pruebas. Un sistema con un rol es una fracción del mismo sistema con cinco, aunque los datos subyacentes sean idénticos. Suele ser el mayor factor individual y casi siempre se infravalora en el encargo.
2. Integraciones, y quién las controlaUna integración con una API moderna y documentada es trabajo previsible. Una integración con un sistema heredado, una base de datos sin documentar, un proveedor con el que hay que concertar cita, o un portal sin API alguna, es el trabajo menos previsible del proyecto. Dos integraciones con el mismo nombre pueden diferir en un factor de diez.
3. Migración de datosMigrar datos limpios de un sistema es rutina. Migrar una década de hojas de cálculo con códigos inconsistentes, partes duplicadas y excepciones que nadie recuerda es un trabajo de arqueología. El esfuerzo está en las excepciones, y nadie sabe cuántas hay hasta que alguien mira.
4. Requisitos sin conexión y móviles«También debería funcionar en móviles» puede significar un diseño adaptable, que es casi gratis, o una aplicación capaz de trabajar sin conexión con un modelo de conflictos de sincronización, que es un proyecto en sí mismo. Se escriben en la misma frase y se presupuestan de forma muy distinta.
5. Requisitos de cumplimiento y auditoríaLos informes obligatorios, los registros de auditoría, la ubicación de los datos, las reglas de conservación y el registro de accesos son ingeniería real, no papeleo. Además condicionan la arquitectura, lo que significa que cuestan mucho más descubiertos tarde que conocidos al principio.
6. Cuánto van a cambiar los requisitosNo es un defecto, sino una propiedad. Si el dominio se entiende bien y es estable, un alcance fijo es alcanzable. Si está construyendo algo verdaderamente nuevo, el alcance se moverá, y un contrato a precio cerrado o se inflará para cubrirlo o acabará en pelea. Ambas cosas son peores que ser honesto al respecto desde el principio.
7. Rendimiento y escala, si de verdad hacen faltaLa mayoría de los sistemas de gestión tienen una carga modesta y no deberían construirse como si no la tuvieran. Pero si necesita concurrencia real, grandes volúmenes de datos o tiempos de respuesta estrictos, eso es arquitectura, infraestructura y pruebas, y debe conocerse antes de la primera decisión de diseño.

Lo que no mueve la cifra tanto como la gente espera

El número de pantallas. Las pantallas son la parte visible y por tanto la que los encargos enumeran, pero una aplicación bien estructurada comparte entre ellas la mayor parte de su maquinaria. Veinte pantallas sobre un modelo de datos limpio cuestan mucho menos que ocho pantallas sobre cuatro sistemas que se contradicen.

El diseño visual, dentro de lo razonable. Una interfaz cuidada y coherente construida sobre un sistema de diseño no es la parte cara. Una identidad visual a medida con ilustración y animación propias sí puede serlo, pero es una decisión aparte que puede tomar de forma independiente.

La elección de una tecnología convencional. Las discusiones sobre frameworks rara vez cambian el total. Lo que cambia el total es si quienes lo construyen conocen bien la pila y si quien la mantenga después también.

Cómo conseguir una estimación en la que pueda confiar

• Traiga los documentos reales, no una descripción. Su tarifario auténtico, una factura real, una hoja de cálculo en uso, el informe que su responsable pide todos los lunes. Veinte minutos con documentos reales valen más que una hora describiéndolos.
• Escriba las tres cosas que deben cumplirse para que el proyecto merezca la pena. Esos son sus requisitos. Todo lo demás del encargo es negociable, y saber qué es qué permite acotar un presupuesto en lugar de inflarlo.
• Pregunte qué excluye el presupuesto. La respuesta dice más que la cifra. La migración, la formación, el funcionamiento en paralelo y el periodo de correcciones posterior al lanzamiento son las omisiones habituales.
• Pídalo por fases, con algo en producción pronto. Un plan por fases saca a la luz los errores de estimación mientras todavía son pequeños, y le da la opción de parar.
• Pregunte cuál es la suposición más arriesgada. Quien ha estimado el trabajo de verdad responde al instante. Quien dice que no hay riesgo no ha mirado.

Precio cerrado, por tiempo y materiales, o con tope

El precio cerrado encaja con un alcance bien entendido y traslada el riesgo al proveedor, que lo incorpora al precio. Funciona, y su coste es que los cambios se convierten en hechos contractuales, lo que pone a todo el mundo a la defensiva justo cuando el proyecto necesita flexibilidad.

El modelo por tiempo y materiales encaja con el trabajo exploratorio y es el modelo honesto cuando el alcance va a moverse, pero exige confianza y no le da techo salvo que usted lo imponga.

Un modelo con tope por fase suele ser lo mejor: una cifra firme para una fase cuyo alcance se entiende realmente, reestimada en cada frontera de fase con lo aprendido. Obtiene previsibilidad donde es posible y flexibilidad donde no lo es.

El error caro más barato

Elegir solo por precio y rehacerlo en dieciocho meses. Es lo bastante común como para ser el resultado por defecto entre quienes compran por primera vez. Las señales de alarma son constantes: un presupuesto muy por debajo de los demás sin explicación, ningún análisis previo a la cifra, ninguna pregunta sobre sus datos, y una fecha de entrega que da por hecho que no se aprenderá nada durante el desarrollo.

Un presupuesto más bajo porque el proveedor entiende el dominio y ha construido algo parecido es realmente un mejor precio. Un presupuesto más bajo porque omite migración, pruebas y funcionamiento en paralelo es el mismo precio, pagado más tarde, en peor orden.