La gerencia aprueba el presupuesto para un sistema de despacho. Seis meses después, el proveedor entrega algo que funciona en la demo pero que nadie en bodega quiere usar: las pantallas no calzan con cómo se arma un pedido real y la integración con el ERP se cae cada vez que cambia un código de producto. Cuando se revisa el contrato, aparece el problema de fondo. Nunca se definió qué se entregaba en cada etapa, así que no hubo un momento formal para decir "esto no es lo que pedimos".
En diseño y desarrollo de software, los proyectos rara vez fallan por el código. Fallan antes, cuando nadie deja por escrito qué se va a construir, o después, cuando nadie sabe cómo operar lo que se construyó. Aquí recorremos las etapas del desarrollo de proyectos de software a medida y los entregables que conviene pedir en cada una. Sirve tanto si vas a contratar consultoría en desarrollo de software como si tu equipo interno lleva el proyecto.
Descubrimiento: entender el problema antes de cotizar la solución
La primera etapa es la que más se recorta para "ganar tiempo" y la que más tiempo hace perder después. Aquí se levanta cómo funciona hoy el proceso, quiénes lo usan, qué sistemas toca y qué significa que el proyecto salió bien.
Lo que deberías tener al final:
- Un mapa del proceso actual y del proceso deseado, validado por quienes trabajan en él (no solo por la jefatura).
- Un backlog inicial priorizado: la lista de funcionalidades ordenada por valor para el negocio.
- El alcance de la primera versión, con lo que queda fuera escrito con la misma claridad que lo que queda dentro.
- Un inventario de integraciones y de datos, incluyendo qué datos personales va a tratar el sistema.
- Riesgos conocidos y supuestos, por ejemplo "el ERP expone una API para consultar stock".
Ese último punto pesa más de lo que parece. Un supuesto que nadie verificó en el descubrimiento suele convertirse en un cambio de alcance a mitad del proyecto. Y si el sistema va a manejar RUT, direcciones o datos de salud, este es el momento de decirlo, porque la Ley 21.719 incorpora en su artículo 14 quáter el deber de protección de datos desde el diseño y por defecto. Agregar controles de privacidad al final cuesta mucho más que diseñarlos desde el principio.
Diseño UX: probar con usuarios antes de escribir código
Diseñar la experiencia significa decidir cómo una persona va a completar su tarea con la menor fricción posible y comprobarlo antes de programar. Que se vea bien viene después.
En esta etapa conviene pedir flujos de usuario para las tareas principales y un prototipo navegable (en Figma o similar) que se pueda mostrar a usuarios reales. También un registro breve de lo que se aprendió en esas pruebas y qué se cambió por eso.
El caso de la bodega del comienzo se habría evitado con una tarde de pruebas con tres operarios y un prototipo. Corregir un flujo en Figma toma horas. Corregirlo con el sistema en producción toma semanas, y además hay que convencer de nuevo a la gente de que lo use.
Arquitectura: las decisiones caras de revertir
La arquitectura define dónde corre el sistema, cómo se divide en componentes, cómo se conecta con otros sistemas y cómo se protege. Son decisiones que después cuesta mucho cambiar, así que merecen quedar documentadas con sus razones.
| Entregable | Qué debería responder |
|---|---|
| Diagrama de arquitectura | Componentes, nube o servidores, integraciones y flujo de datos |
| Registro de decisiones (ADR) | Qué se eligió, qué alternativas se descartaron y por qué |
| Modelo de datos | Entidades principales y dónde vive cada dato personal |
| Diseño de seguridad | Autenticación, roles y permisos, cifrado, manejo de secretos |
| Requisitos no funcionales | Usuarios concurrentes, tiempos de respuesta, disponibilidad esperada |
| Estimación de costos de operación | Cuánto costará la infraestructura al mes con el volumen esperado |
Pon atención especial al control de acceso. En el OWASP Top 10:2025, la lista de referencia de riesgos en aplicaciones web, el primer lugar sigue siendo el control de acceso roto: usuarios que pueden ver o modificar datos que no les corresponden. Eso se previene definiendo bien los roles en la arquitectura, no parchando pantalla por pantalla.
Desarrollo en sprints: avance que se puede ver
Con descubrimiento, diseño y arquitectura resueltos, el desarrollo se organiza en ciclos cortos. La Guía de Scrum define el sprint como un período fijo de un mes o menos, que incluye la planificación, la reunión diaria, la revisión y la retrospectiva. En la práctica, muchos equipos trabajan con sprints de dos semanas.
A quien contrata le importa que cada sprint termine con algo verificable:
- Un objetivo del sprint acordado al inicio.
- Un incremento funcionando en un ambiente de pruebas, que tú puedes usar, no solo ver en una presentación.
- Una revisión al cierre donde se muestra lo terminado y se ajusta el backlog.
- Una definición de "terminado" compartida: por ejemplo, código revisado por otra persona, pruebas automatizadas pasando y documentación actualizada.
Si llevas tres sprints sin poder probar nada con tus propias manos, algo anda mal, y es mejor detectarlo en la sexta semana que en el sexto mes. Hoy la IA acelera buena parte de esta etapa, pero no reemplaza la revisión humana; lo explicamos con datos en Desarrollo de software con inteligencia artificial hoy.
QA: pruebas durante todo el proyecto, no al final
Cuando las pruebas se dejan para el final, los errores se acumulan y el plazo se come la corrección. Por eso el control de calidad corre en paralelo al desarrollo desde el primer sprint.
Un proyecto bien llevado entrega:
- Pruebas automatizadas (unitarias y de integración) que corren cada vez que alguien sube un cambio.
- Casos de prueba funcionales escritos a partir de los criterios de aceptación de cada historia.
- Un informe de pruebas de seguridad antes de salir a producción.
- Pruebas de aceptación con usuarios del negocio (UAT), con un acta que diga qué se aprobó.
Un detalle que se pasa por alto: los ambientes de prueba no deberían usar copias de la base de producción con datos reales. Si necesitas datos realistas, hay que anonimizarlos. Lo desarrollamos en Datos reales en ambientes de prueba y la Ley 21.719.
Despliegue y operación: lo que pasa después del lanzamiento
El día que el sistema sale a producción empieza la parte más larga de su vida. Para esta etapa pide un pipeline de integración y despliegue continuo (CI/CD) documentado, un plan de despliegue con vuelta atrás por si algo falla, un manual de operación, monitoreo con alertas y la transferencia del código fuente y las credenciales a tu empresa.
Para medir si el equipo entrega bien en el tiempo, el programa de investigación DORA de Google propone cinco métricas de entrega de software: tiempo de ciclo de un cambio, frecuencia de despliegue, tiempo de recuperación ante un despliegue fallido, tasa de cambios fallidos y tasa de retrabajo en despliegues. No hace falta medir las cinco desde el primer día. Sí conviene saber cuánto tarda un cambio en llegar a producción y cuántos terminan en un parche urgente.
Si tu empresa está evaluando proveedores, en Fábrica de software en Chile: 10 preguntas antes de firmar dejamos preguntas concretas para la etapa comercial.
Preguntas frecuentes
¿Cuánto dura un proyecto de desarrollo de software a medida?
Depende del alcance. Un descubrimiento serio toma semanas, no días, y una primera versión útil suele tomar algunos meses. Desconfía de plazos cerrados entregados antes de hacer el descubrimiento.
¿Se puede saltar la etapa de descubrimiento si ya sé lo que necesito?
Puedes acortarla, no eliminarla. Aunque tengas claro el problema, el equipo que construye necesita validar integraciones, datos y supuestos técnicos antes de comprometer plazos.
¿Qué pasa con los datos personales si la Ley 21.719 se posterga?
La fecha de entrada en vigencia sigue siendo el 1 de diciembre de 2026. Hay un proyecto (Boletín 18.623-07) que propone moverla a diciembre de 2027, que recién el 19 de octubre de 2026 empezó a discutirse en la Comisión de Constitución del Senado. Mientras no se publique como ley, la fecha no cambia. Un sistema que se diseña hoy va a operar por años, así que conviene construirlo cumpliendo la ley de todas formas.
Antes de firmar, pide el plan de entregables
Los entregables por etapa sirven para tener puntos de control mientras todavía es barato corregir el rumbo. Si un proveedor no puede decirte qué vas a recibir al cierre de cada etapa, esa respuesta ya dice bastante. En Disrupsoft diseñamos y desarrollamos aplicaciones web y móviles a medida, con comunicación constante con tu equipo durante todo el proyecto. Si estás por iniciar uno, conversemos sobre tu proyecto de desarrollo de software a medida.
