La respuesta corta
El tiempo que se tarda en desarrollar un sistema depende del tamaño del problema, de las integraciones y de la claridad del alcance, y no existe un plazo único. Con entregas en sprints cortos, una primera versión útil suele salir en semanas, no en meses. El plazo total se define en el estudio inicial.
Conviene desconfiar de quien da un número antes de entender la operación. Un sistema que reemplaza una planilla de control interno y un sistema que atiende al ciudadano, se comunica con otras bases y registra cada movimiento son proyectos de naturaleza distinta, aunque los dos quepan en la frase "necesitamos un sistema". Lo que sí se puede garantizar desde el inicio es el ritmo: software funcionando en cada ciclo, para que usted vea el avance en lugar de esperar el final.
Qué pesa más en el plazo de un sistema
Cinco factores explican casi toda la diferencia de plazo entre un proyecto y otro. Ninguno de ellos es el lenguaje de programación. La tabla muestra qué acorta y qué alarga cada uno.
| Factor | Acorta el plazo cuando | Alarga el plazo cuando |
|---|---|---|
| Tamaño del problema | el sistema atiende un perfil de usuario y una rutina bien delimitada | hay varios perfiles, como ciudadano, agente de atención y gestión en Ágil Cidadão, y cada uno usa la misma información a su manera |
| Integraciones | el sistema funciona solo o los demás ofrecen una API documentada | cada base existente tiene reglas, accesos y pruebas propias, y ahí suele estar la sorpresa |
| Claridad del alcance | la operación ya sabe qué necesita cambiar y quienes deciden están de acuerdo | el problema todavía está enredado y la validación debe separar lo esencial de lo deseable |
| Disponibilidad de quienes deciden | la aprobación de cada sprint ocurre en la demostración | la aprobación se demora y el ciclo siguiente espera |
| Seguridad, accesibilidad y ley brasileña de protección de datos (LGPD) | los requisitos entran en el diseño desde el inicio | aparecen al final y obligan a rehacer pantallas, permisos y registros |
Observe que solo el primer factor tiene que ver con el tamaño del sistema. Los otros cuatro dependen de organización, acceso y decisión, y por eso se puede trabajar en ellos antes de empezar. Si el alcance todavía es difuso, la guía sobre cómo definir el alcance de un software ayuda a llegar mejor preparado a la primera conversación.
Las fases del desarrollo y qué entrega cada una
El ciclo que seguimos tiene seis etapas, descritas en detalle en cómo trabajamos. No ocurren en fila rígida: diseño, desarrollo e infraestructura se superponen desde los primeros sprints, y esa superposición es lo que evita sumar el plazo de seis fases completas.
- Validación y estudio de producto. Entendemos la operación, quién la usa y el problema antes de proponer tecnología, con prototipos y conversaciones con quienes van a usar el sistema de verdad. De aquí salen el alcance validado y el backlog priorizado, y es aquí donde se define el plazo total.
- Diseño de interfaz. Flujos y prototipos navegables probados con quienes los van a usar, antes de convertirse en código. Corregir un flujo en el prototipo cuesta mucho menos que corregirlo en el sistema terminado.
- Desarrollo. Sprints cortos, código revisado y pruebas automatizadas. Cada sprint termina con software funcionando en homologación, para que usted lo pruebe y lo apruebe.
- Infraestructura. Ambientes, publicación automatizada y monitoreo dimensionados para la operación, montados mientras el sistema crece.
- Seguridad. Control de acceso, protección de datos y cumplimiento de la LGPD desde el diseño, con verificación antes de cada publicación.
- Soporte y evolución. El sistema entra en producción y el uso real alimenta el próximo ciclo de mejoras.
Cada sprint empieza con la planificación, en la que priorizamos juntos lo que entra y definimos el criterio de aceptación de cada ítem, y termina con la demostración. Este ritmo previsible es lo que permite medir el avance por lo que ya funciona, y no por un porcentaje estimado.
Cómo un MVP acorta el tiempo hasta la primera versión útil
La forma más segura de llegar rápido a un sistema útil es no intentar construir todo de una vez. En el estudio, separamos lo que resuelve el dolor principal de lo que puede esperar y empezamos por la parte que genera valor antes. Esa primera versión reducida, usada de verdad, es lo que el mercado llama MVP, y explicamos el concepto en detalle en la guía qué es un MVP y cómo validar un sistema.
El MVP no reduce el tamaño del proyecto. Cambia el orden. En lugar de esperar el sistema completo para empezar a usarlo, el equipo pasa a operar con la primera parte mientras se construye el resto, y el uso real muestra lo que de verdad importa. Funciones que parecían esenciales en el papel a veces pierden prioridad, y aparecen otras. Ajustar el rumbo en cada sprint sale más barato que descubrir el desvío al final.
Es el caso de nuestro sistema de gestión de pacientes para atención de urgencias, en desarrollo para reemplazar un sistema comercial que no acompañaba la operación. El alcance va desde la recepción del paciente hasta el informe de gestión, y cada parte pasa por el mismo ciclo de sprint y demostración.
Qué acelera y qué retrasa un proyecto de software
Buena parte del plazo está en manos de quien contrata. Estos cuidados marcan una diferencia real:
- Una persona responsable de su lado. Alguien con autonomía para priorizar y aprobar, presente en las demostraciones.
- Acceso temprano a quienes operan la rutina. No solo a la gestión. Quien ejecuta el proceso a diario es quien señala la regla que nadie escribió.
- Documentación de las integraciones reunida antes. Contactos, accesos y manuales de los sistemas que se comunicarán con el nuevo, para que la integración no se detenga esperando respuesta.
- Aceptar una primera versión reducida. Empezar a usar lo que ya resuelve el dolor principal, en lugar de esperar el sistema completo.
- Decisiones registradas. Criterios de aceptación y cambios documentados evitan volver a discutir lo que ya se acordó.
Y algunas cosas retrasan casi siempre: cambiar la prioridad a mitad del sprint, descubrir una integración obligatoria después de cerrar el alcance y dejar la validación con los usuarios para el final. El cambio de alcance es parte de cualquier proyecto. Lo que retrasa es el cambio sin evaluación de impacto, por eso cada pedido nuevo viene con el efecto que tiene en el plazo, para que usted decida qué entra ahora y qué queda para después.
Por qué el plazo solo se vuelve firme después del estudio inicial
Antes del estudio, cualquier plazo es una suposición. Nadie habló todavía con quienes usan el sistema, nadie sabe qué permiten los sistemas actuales y el alcance es una lista de deseos. Un número dado en ese momento tiende a convertirse en una de dos cosas: un plazo inflado para cubrir lo desconocido o un plazo demasiado corto que se rompe en la primera integración.
El estudio existe para cambiar suposición por información. Mapea la operación, las integraciones y las prioridades, y devuelve un alcance validado con etapas. A partir de ahí el plazo deja de ser una apuesta y pasa a ser un plan, que usted sigue sprint a sprint. Esto vale para empresas y también para organismos públicos, donde la contratación tiene reglas propias y la planificación por etapas ayuda a dar previsibilidad al cronograma, como mostramos en la guía sobre contratar software para un organismo público.
Cómo llegamos a un plazo para su caso
Antes de cualquier compromiso mayor, hacemos un estudio corto que define alcance, prioridades, plazo e inversión de su software a medida. Usted sale de él sabiendo por dónde empezar y qué entra en cada etapa. No hace falta llegar con el alcance listo: basta contar qué da trabajo, retrasa o genera errores hoy.
Si quiere una primera lectura de su caso, nuestro consultor en el sitio hace las preguntas iniciales y deriva la conversación al equipo.