Coste del software a medida: factores y cómo leer un presupuesto

El factor principal es el alcance: a cuántos tipos de usuario sirve el software, cuántos flujos de trabajo ejecuta y cuántas excepciones tiene cada flujo. Un sencillo registro para un solo tipo de usuario y un sistema que gestiona juntos las ventas, el stock, la contabilidad y los informes pueden llamarse ambos software, pero exigen un esfuerzo muy distinto.

El segundo factor es la composición del equipo. Si un diseñador, un desarrollador, un probador y un jefe de proyecto trabajan juntos, el coste es el tiempo que cada uno dedica al proyecto. Un equipo con experiencia parece más caro pero da menos vueltas; uno sin experiencia parece barato pero lleva el riesgo de una reescritura.

El tercero es el tiempo. Si se quiere el mismo alcance antes, el equipo crece y aumenta la carga de coordinación. La prisa es la partida más silenciosa de cualquier presupuesto.

El mayor es la integración. Cada conexión con un programa de contabilidad, un proveedor de pagos, una empresa de mensajería, un servicio de correo o un ERP existente es un trabajo aparte, porque las reglas, los fallos y los cambios de versión del otro sistema escapan a su control. Si la documentación de un tercero es escasa, el coste se vuelve incierto.

El segundo son las propias reglas. Una frase como «quién aprueba un pedido depende del importe, y si el responsable regional no lo ha aprobado pasa a la dirección general» significa decenas de casos que probar. Cuantas más reglas de negocio hay y más excepciones tienen, mayor es el coste.

El tercero es la migración de datos. Mover, cotejar y comprobar datos desordenados de un sistema antiguo es, en la mayoría de los proyectos, una de las tareas menos esperadas y que más tiempo llevan.

• El número de sistemas que integrar y la calidad de la documentación de la otra parte
• El número de tipos de usuario y de diferencias de permisos
• El número de excepciones en las reglas de negocio
• Los datos que hay que trasladar y limpiar desde un sistema antiguo
• Las expectativas de seguridad, copias de respaldo y registros de auditoría
• La compatibilidad con varios idiomas, monedas o sucursales

La decisión más eficaz es mantener pequeña la primera versión. Un proyecto que lo quiere todo el primer día crece sin que se use ninguna parte. Lanzar primero un flujo de trabajo y probarlo con usuarios reales muestra qué funciones hacen verdadera falta y recorta desde el principio el coste de las innecesarias.

La segunda es usar componentes ya hechos. El inicio de sesión, los pagos, el envío de correos y los permisos son problemas resueltos; construirlos sobre servicios probados en lugar de desde cero reduce tanto el tiempo como los fallos. Escribir software a medida no significa escribir a medida cada pieza.

La tercera es mantener corta la toma de decisiones. Una persona con autoridad por parte del cliente, las peticiones de cambio por escrito y breves demostraciones semanales detectan la incertidumbre a tiempo. La corrección más cara es el malentendido que se advierte el último.

Un buen presupuesto es un documento de alcance, no un total único. Indica qué se hará, qué queda fuera, en qué supuestos se apoya y cómo se tratarán los cambios. Un presupuesto que describe el alcance en dos frases significa una nueva negociación por cada petición adicional.

Mire el modelo de pago. Un precio cerrado le protege cuando el alcance está claro; cuando es vago, el equipo incorpora el riesgo al precio o abre después peticiones adicionales. El trabajo por tiempo es flexible, pero necesita informes periódicos y un tope para saber hacia dónde va el total. Pregunte en qué condiciones le conviene más cada modelo.

Al comparar varios presupuestos, compare alcances, no totales. Un presupuesto que parece bajo puede dejar fuera las pruebas, la seguridad, las copias de respaldo o el mantenimiento. Dos presupuestos que no describen el mismo trabajo no se pueden comparar por el precio.

Las partidas que más se pasan por alto surgen después del lanzamiento: alojamiento e infraestructura, suscripciones a servicios de terceros, renovaciones de dominio y certificados, copias de respaldo y monitorización. Son costes recurrentes, no puntuales, y forman parte real del coste total de propiedad.

El mantenimiento es la segunda gran partida oculta. Cuando el software está terminado, el trabajo no lo está: continúan las actualizaciones de seguridad, los cambios de versión de los sistemas conectados, las pequeñas mejoras y las correcciones. Un proyecto cuyo mantenimiento nunca se habló se convierte, un año después, en un software que nadie atiende o en un rescate urgente y costoso.

La tercera es la formación, la documentación y la entrega. ¿Le entregarán el código, las notas de instalación y la documentación de usuario, o quedará atado al equipo que lo escribió? La respuesta decide la libertad que tendrá más adelante para cambiar de equipo.

El más común es elegir el presupuesto más bajo. Un presupuesto bajo suele estrechar el alcance o dejar el riesgo para más tarde; a medida que el proyecto avanza llegan partidas adicionales y el total supera el presupuesto que se descartó al principio.

El segundo es empezar sin dejar el alcance por escrito. Cuando lo acordado de palabra no está en papel, cada cual defiende su propio recuerdo. El tercero es dejar el mantenimiento fuera del proyecto; el coste no termina cuando el software sale en producción.

El cuarto es tratar el software como algo que se compra una vez. El software a medida es un activo vivo y cambia a medida que cambia el negocio. Presupuestar solo el primer desarrollo crea problemas a partir del segundo año.

Si un producto ya hecho del mercado cubre casi por completo su necesidad, no hay razón para construir software a medida. Para una necesidad estándar de contabilidad, reservas o correo, comprar el producto terminado es más rápido y más predecible.

También puede ser pronto si aún no puede describir por completo su proceso. El software escrito antes de que el proceso se asiente tiene que cambiar con él, y cada cambio trae un coste de reescritura. Pruebe primero el proceso en papel o con una herramienta de catálogo y decida cuando esté claro.