Guías

Software a medida: medir el éxito en lugar de estimarlo

Sin un indicador fijado previamente, no se puede decir después si el software a medida valió la pena. Qué cifras sirven, cuáles llevan por mal camino y cuándo se recogen.

Presupuesto bajo consultadesde 8 semanas hasta la primera versiónSituación 2026
En resumen

El éxito del software a medida solo se puede medir si se registró el valor inicial previamente: basta con contar durante dos semanas. Los indicadores útiles son tiempo de procesamiento por operación, proporción de casos que pasan sin intervención y tiempo de reacción hacia el exterior. La satisfacción del equipo en las primeras dos semanas no es un criterio útil.

01 — Medición

En qué medís el éxito

  • Establecer ese único número previamente. Sin valor de partida, no se puede demostrar nada después. Contar durante dos semanas es suficiente para una magnitud fiable.
  • Tiempo de procesamiento por caso. La magnitud más directa: cuánto dura el procedimiento afectado hoy, cuánto después.
  • Proporción de casos que pasan sin intervención. Esta tasa sube en las primeras semanas típicamente de forma notable cuando se afina — es el mejor indicador temprano.
  • Tiempo de respuesta hacia el exterior. Con qué rapidez obtiene alguien que pregunta una primera respuesta vinculante.
  • Lo que no deberíais medir: satisfacción en el equipo en las primeras dos semanas. Cualquier cambio se siente al principio peor de lo que es.

02 — Cálculo

Así se calcula

Cuatro números bastan: ¿con qué frecuencia ocurre el proceso? ¿Cuánto dura? ¿Cuánto cuesta una hora internamente? ¿Y cuánto cuesta la solución, una vez más el funcionamiento durante tres años?

Un ejemplo: un proceso que ocurre dos veces por semana y dura 40 minutos cada vez ocupa alrededor de 69 horas al año. Con una tarifa interna de 45 euros por hora, son unos 3.100 euros anuales que quedan ahí vinculados. Si una solución reduce este esfuerzo en dos tercios, se amortiza —según la oferta real— a menudo en uno o dos años. El valor exacto para vuestro caso os lo indicamos después de la primera reunión.

Este cálculo es deliberadamente conservador: solo considera el tiempo ahorrado, no los errores evitados ni los pedidos que se consiguen gracias a una reacción más rápida. En la práctica, el beneficio suele ser mayor, pero no conviene contarlo antes de haberlo medido.

03 — Contexto

Lo que muestra la experiencia

Observación

Los proyectos de software más caros son aquellos en los que durante doce meses nadie pudo usar nada.

04 — Preguntas

Preguntas frecuentes

¿Qué pasa si durante el desarrollo descubrimos nuevos requisitos?

Es normal y está previsto, porque se trabaja en pasos pequeños. Un nuevo requisito se incorpora al siguiente paso, en lugar de detener todo el proyecto.

¿Qué pasa si dejamos de colaborar?

Tenéis código, documentación y accesos. Usamos deliberadamente tecnologías extendidas para que un cambio sea posible sin que nadie tenga que reconstruir todo.

¿Cómo evitamos que el proyecto se descontrole?

Pasos pequeños con resultado útil, presupuestos fijos por paso y la posibilidad de salir después de cada paso. Los grandes proyectos a precio fijo de doce meses son el camino más seguro hacia la decepción, para ambas partes.

¿Cuándo vale la pena el software propio frente al software estándar?

Cuando tu proceso es una ventaja competitiva real, cuando el software estándar solo encaja al setenta por ciento y el resto termina en trabajo manual, o cuando los costes de licencia por usuario superan el desarrollo en pocos años. Si solo se trata de comodidad, el software estándar es más barato.

¿Cuántos usuarios soporta un sistema así?

Depende de la arquitectura, que planificamos según vuestro crecimiento esperado, desde pocos usuarios en el propio negocio hasta varios cientos en múltiples ubicaciones.

¿Funciona en nuestros propios servidores o en la nube?

Ambas opciones son posibles. Para la mayoría de los negocios una solución en la nube requiere menos mantenimiento; donde los datos no pueden salir del local, lo configuramos en infraestructura propia.

¿A quién pertenece el código fuente?

A vosotros, completamente, desde el pago. Está en el contrato. Podéis ir con él a cualquier otro desarrollador, ese es el punto.

Siguiente paso

Primera evaluación, sin compromiso.

Describid brevemente de qué se trata. Recibiréis una respuesta honesta sobre qué es realista y cuánto cuesta aproximadamente.