La respuesta corta
Para definir el alcance de un software, empiece por el problema de la operación, no por la lista de pantallas. Un buen alcance describe el objetivo, quién usa el sistema, las rutinas que cubre, las reglas de negocio, las integraciones, lo que queda fuera y cómo se aceptará cada entrega. Todo por escrito, revisado con quien opera y aprobado por quien decide.
No necesita llegar con esto listo. Convertir un problema de la operación en un alcance validado es parte del trabajo de quien desarrolla, y suele ocurrir en una fase de estudio antes de cualquier compromiso mayor. Lo que ayuda mucho es saber contar qué da trabajo hoy, qué retrasa o genera errores, y quién siente ese problema en el día a día.
Qué contiene un buen alcance de software
El alcance no es una lista de funcionalidades. Es el acuerdo sobre lo que el sistema necesita resolver y hasta dónde llega. Siete partes aparecen en cualquier alcance que se sostiene:
- Objetivo. El problema que el sistema resuelve, dicho en una o dos frases, y cómo se sabrá que se resolvió. "Acabar con la doble digitación entre la recepción y la atención" orienta decisiones; "modernizar el proceso" no orienta ninguna.
- Usuarios y perfiles. Quién lo usa, con qué frecuencia y con qué permisos. Un sistema como Ágil Cidadão, nuestro sistema de atención al ciudadano, tiene tres perfiles (ciudadano, agente de atención y gestión), y cada uno usa la misma información de una manera distinta.
- Rutinas cubiertas. Los procesos que el sistema acompaña de principio a fin, descritos como ocurren: quién los inicia, por dónde pasan, dónde terminan. Aquí aparecen las excepciones que nadie recordó en la primera conversación.
- Reglas de negocio. Las condiciones que el sistema debe respetar: plazos, aprobaciones, cálculos, quién puede hacer qué. Una regla que solo existe en la cabeza de alguien se convierte en un defecto cuando el sistema entra en uso.
- Integraciones. Con qué sistemas debe comunicarse el nuevo, en qué dirección y por qué medio, como una API o una exportación estructurada. Conviene confirmar pronto lo que permite cada sistema, porque en las integraciones suele estar la sorpresa.
- Exclusiones. Lo que no forma parte de esta etapa, escrito con la misma claridad que lo que sí. La lista de lo que queda fuera evita buena parte de las discusiones a mitad del proyecto.
- Criterio de aceptación. Cómo se considerará terminada cada entrega. Una frase como "el agente de atención puede abrir la solicitud en nombre del ciudadano y el historial registra autor y fecha" se puede probar; "funcionar bien" no.
Algunos requisitos entran aunque nadie los pida: cuántas personas usan el sistema al mismo tiempo, qué datos personales guarda y qué exige sobre ellos la ley brasileña de protección de datos (LGPD), y si hay requisitos de accesibilidad. Dejar esto para el final suele salir caro, porque afecta todo el diseño.
Checklist para revisar el alcance antes de contratar
Antes de aprobar un alcance, ya sea el que escribió su equipo o el que entregó un proveedor, verifique si responde a estas preguntas:
- ¿El problema está escrito? Se puede leer el objetivo y entender por qué existe el sistema sin conocer el proyecto.
- ¿Participó quien opera? Las rutinas fueron descritas por quienes ejecutan el proceso, no solo por quienes lo gestionan.
- ¿Cada perfil está listado? Con lo que puede ver, registrar, aprobar y eliminar.
- ¿Las reglas tienen responsable? Cada regla de negocio tiene a alguien de su lado que confirma si es correcta.
- ¿Se verificaron las integraciones? Para cada sistema existente, se sabe qué permite y quién responde por él.
- ¿Hay una lista de lo que queda fuera? Si no la hay, cada persona supondrá un límite distinto.
- ¿Los ítems tienen criterio de aceptación? Cada entrega dice cómo será probada y aprobada.
- ¿Lo esencial está separado de lo deseable? El alcance muestra qué entra en la primera versión y qué viene después.
- ¿Están previstos los datos y la migración? Si hay información en hojas de cálculo o en un sistema antiguo, el alcance dice qué se migrará y cómo.
Si varias respuestas son "no sé", eso no significa que el proyecto sea malo. Significa que falta estudio antes de estimar. Explicamos esa fase en qué es el discovery de producto.
Cómo priorizar lo esencial ahora y lo que puede esperar
Todo alcance empieza más grande de lo necesario. Cada área trae su propia lista, y sumar todas las listas es el camino más corto hacia un proyecto largo que tarda en generar valor.
La pregunta que ordena la prioridad es simple: sin esto, ¿funciona la rutina principal? Si la respuesta es no, el ítem entra ahora. Si la rutina funciona, aunque con algo de trabajo manual, el ítem puede pasar a una etapa siguiente.
- Esencial ahora. Lo que resuelve el dolor principal y lo que es obligatorio por ley o por seguridad, como el control de acceso y la protección de datos personales.
- Importante, pero puede esperar. Informes adicionales, automatizaciones de conveniencia, pantallas para perfiles que usan poco el sistema.
- Deseable. Ideas que tienen sentido, pero que el uso real todavía debe confirmar.
Una primera versión ligera, enfocada en la rutina que más sufre, entra en uso mientras se construye el resto. Lo que el equipo aprende al usarla cambia la lista de lo que viene después, y casi siempre para mejor. El razonamiento es el mismo de un MVP bien definido.
Alcance cerrado o alcance evolutivo: cuál elegir
Hay dos formas de tratar el alcance en un contrato, y ambas funcionan cuando se aplican al caso correcto.
| Criterio | Alcance cerrado | Alcance evolutivo |
|---|---|---|
| Cuándo sirve | Problema claro, con principio, medio y fin | Producto que cambiará con el uso |
| Qué se define al inicio | Todas las entregas y sus criterios de aceptación | El objetivo, la primera versión y las prioridades |
| Cómo maneja el cambio | Cada cambio se evalúa y aprueba por separado | La prioridad se revisa en cada sprint |
| Previsibilidad | Plazo e inversión definidos desde el inicio | Ritmo previsible, con el alcance ajustado por lo que se aprende |
| Riesgo principal | Fijar temprano algo que el uso mostraría distinto | Perder el foco si nadie decide qué queda fuera |
Trabajamos con los dos modelos, proyecto cerrado y equipo dedicado, y recomendamos uno de ellos después de entender el caso. En ambos, el cambio es parte del proceso: evaluamos el impacto de cada pedido en el plazo y el esfuerzo, mostramos las opciones y nada cambia sin la aprobación de quien contrata.
En el sector público brasileño, la Ley 14.133/2021 (ley de contrataciones públicas) prevé el estudio técnico preliminar y el término de referencia antes de la contratación, y esos documentos ya cumplen parte del papel del alcance. Cuanto más describe el término de referencia el problema y los criterios de aceptación, y menos parece una lista de pantallas, más espacio queda para la solución correcta.
Errores comunes al definir el alcance de un sistema
- Empezar por las pantallas. Diseñar la interfaz antes de entender la rutina lleva a un sistema bonito que no encaja en el trabajo.
- Escuchar solo a quien gestiona. Quien decide conoce el objetivo; quien opera conoce las excepciones. Un alcance sin las dos visiones falla en una de ellas.
- Copiar el sistema antiguo. Reproducir pantalla por pantalla lo que existe hoy arrastra los atajos que el equipo creó para sortear sus limitaciones.
- Dejar las integraciones para después. Descubrir a mitad del proyecto que el otro sistema no ofrece API cambia el plazo y a veces la propia solución.
- Usar términos vagos. "Intuitivo", "rápido" y "completo" no se pueden probar. Cada uno debe convertirse en un criterio de aceptación.
- No escribir lo que queda fuera. El silencio se convierte en expectativa, y la expectativa no atendida se convierte en conflicto al final del proyecto.
Cómo el alcance se convierte en cronograma
Con el alcance aprobado, cada ítem se convierte en una entrada del backlog, la lista priorizada de lo que se construirá. Los ítems grandes se dividen en partes que caben en un sprint, y cada parte recibe su criterio de aceptación.
El cronograma sale de la combinación de tres cosas: el tamaño de cada ítem, el orden de prioridad y las dependencias, como la integración que debe existir antes del informe que usa sus datos. Diseño, desarrollo e infraestructura se superponen, así que el cronograma no es una fila. Detallamos lo que más pesa en el plazo en cuánto tiempo lleva desarrollar un sistema a medida.
En nuestro método de trabajo, alcance, premisas, riesgos y cronograma quedan registrados en la reunión de apertura, y el alcance se aprueba formalmente antes del diseño. Después, cada sprint empieza con la planificación de las prioridades y termina con la demostración de lo construido. Así, en el desarrollo de software a medida, el acuerdo escrito se convierte en un sistema en uso.