El alcance de un proyecto de software es el acuerdo escrito sobre qué se va a construir, para quién, con qué conexiones y bajo qué condiciones se considera terminado. También dice qué no se va a construir. Sin ese acuerdo, cualquier cotización es una suposición y cualquier plazo es una esperanza.
Si ya tienes claro por qué importa y quieres el paso a paso general, lo explicamos en [Cómo definir el alcance de tu proyecto de software a medida]. Aquí vamos un nivel más abajo: las piezas concretas que debe tener el alcance y cómo revisarlas antes de firmar.
Cómo definir el alcance de un proyecto de desarrollo de software
Se define respondiendo siete preguntas en orden. Si alguna no tiene respuesta todavía, esa es la tarea del Discovery:
- ¿Qué problema operativo queremos resolver?
- ¿Quién va a usar el sistema?
- ¿Qué funcionalidades son imprescindibles para la primera versión?
- ¿Con qué sistemas debe conectarse?
- ¿Qué datos existentes hay que llevar al sistema nuevo?
- ¿Qué queda fuera de esta etapa?
- ¿Cómo comprobamos que cada funcionalidad quedó terminada?
Empieza por el problema y no por las pantallas
«Queremos un sistema de gestión» no es un alcance. Esto sí empieza a serlo:
«Hoy las solicitudes de una distribuidora llegan por WhatsApp y correo. Una persona las pasa a Excel. Otra las digita en el sistema contable. Nadie sabe en qué estado está un pedido sin preguntar.»
Con esa descripción ya se puede hablar de módulos. Con la primera frase solo se puede hablar de presupuestos al aire.
Roles y permisos de usuarios en un sistema
Cada tipo de usuario necesita ver y hacer cosas distintas. Definirlo temprano evita rehacer pantallas después. Un ejemplo para una clínica:
| Rol | Qué hace en el sistema |
|---|---|
| Recepción | Registra pacientes y agenda citas |
| Personal asistencial | Consulta y completa la historia del paciente |
| Jefatura | Revisa indicadores y aprueba excepciones |
| Administración | Gestiona facturación y reportes |
Cada fila agrega pantallas y reglas de acceso. Por eso la cantidad de roles es uno de los factores que más mueve el costo.
Priorizar funcionalidades de un software
Casi siempre hay más ideas que presupuesto. La salida es ordenarlas en tres grupos:
- Imprescindible. Sin esto la primera versión no resuelve el problema.
- Importante. Aporta valor claro pero puede entrar en una segunda etapa.
- Futuro. Se anota para no perderlo y se decide más adelante.
Una pregunta que ayuda a ordenar: «Si esta funcionalidad no existiera el día del lanzamiento ¿podríamos operar igual?» Si la respuesta es sí no es imprescindible.
Integración de software con ERP
Decir «debe integrarse con nuestro ERP» no alcanza. El alcance tiene que precisar tres cosas:
- Qué datos viajan. Por ejemplo clientes y productos desde el ERP hacia el sistema nuevo y pedidos confirmados en sentido contrario.
- Cuándo viajan. En tiempo real o en lotes cada cierto tiempo.
- Qué pasa si falla. Cómo se reintenta y quién se entera cuando una de las dos partes no responde.
La gestión de errores es lo que más se olvida y lo que más se nota en producción. Si este punto pesa en tu proyecto, revisa [Arquitectura de integraciones escalables].
Migración de datos en un proyecto de software
Los datos históricos casi nunca están limpios. Antes de cotizar conviene saber de dónde salen (Excel o una base de datos antigua) cuántos registros son y qué tan consistentes están. Migrar datos desordenados puede llevar tanto trabajo como construir un módulo. Si no se menciona en el alcance aparece después como sorpresa.
Qué queda fuera del alcance de un proyecto
Esta sección protege a ambas partes. Escribirla no significa que esas cosas nunca se harán. Significa que no están en esta etapa. Un ejemplo:
| Incluido en la etapa 1 | Fuera de la etapa 1 |
|---|---|
| Aplicación web | Aplicación móvil propia |
| Gestión de clientes y pedidos | Portal para proveedores |
| Integración con el ERP | Tableros de analítica avanzada |
| Roles y permisos | Integración con una segunda sede |
Criterios de aceptación de un proyecto de software
«Que funcione bien» no se puede verificar. Un criterio de aceptación sí:
- Un vendedor puede registrar un cliente nuevo y generar una cotización en menos de cinco pasos.
- Los pedidos confirmados aparecen en el ERP sin digitarlos de nuevo.
- Un usuario sin permiso de aprobación no puede ver el botón de aprobar.
Con criterios así cada entrega se revisa con una lista y no con opiniones.
Desarrollo de software por fases y sprints
No hace falta definir todo al detalle antes de empezar. Trabajar en ciclos cortos permite ajustar con lo que se ve funcionando. Lo que sí hace falta es que el alcance de la etapa en curso esté claro. Así el avance se mide contra algo concreto.
Control de cambios en un proyecto de software
Los cambios van a llegar y eso es normal. Lo importante es tratarlos con un solo criterio. Ante cada pedido nuevo se pregunta:
- ¿Es una aclaración de algo que ya estaba en el alcance? Entonces se resuelve dentro del trabajo acordado.
- ¿Es una necesidad nueva? Entonces se evalúa su impacto en plazo y costo y se aprueba antes de hacerla.
Con esa regla nadie se sorprende cuando llega la factura ni cuando se mueve una fecha.
Estimar tiempos y costos de un software
El alcance es la base de cualquier estimación seria. Cuantos más roles integraciones y datos por migrar haya definidos mejor se puede estimar. Si quieres entender cómo se construye una cifra real y por qué un número sin Discovery es solo una referencia lee [Cómo cotizar un software a medida].
Checklist para definir el alcance de un proyecto de software
Antes de tu primera reunión con un proveedor comprueba si puedes responder:
- ☐ ¿Qué problema queremos resolver?
- ☐ ¿Quiénes usarán el sistema y qué hará cada rol?
- ☐ ¿Qué funcionalidades son imprescindibles?
- ☐ ¿Qué dejamos para una segunda etapa?
- ☐ ¿Con qué sistemas debe conectarse y qué datos viajan?
- ☐ ¿Qué datos históricos hay que migrar?
- ☐ ¿Qué reglas de negocio debe respetar?
- ☐ ¿Qué entregables esperamos?
- ☐ ¿Cómo validaremos cada funcionalidad?
- ☐ ¿Qué queda expresamente fuera?
Si varias respuestas siguen en blanco no pasa nada. Significa que la primera etapa del proyecto es precisamente convertirlas en un alcance viable.
Preguntas frecuentes
¿Qué es el alcance de un proyecto de software?
Es el acuerdo escrito sobre qué se construirá, quién lo usará, con qué se conectará y cómo se validará que está terminado. Incluye también lo que queda fuera.
¿Hay que definir todo el alcance antes de empezar a programar?
No. Se necesita claridad suficiente para la primera etapa. El resto se ajusta en ciclos cortos con un control de cambios claro.
¿Qué pasa si no definimos qué queda fuera del alcance?
Cada persona asume que su pedido estaba incluido. Aparecen discusiones sobre plazos y costos que un párrafo escrito habría evitado.
¿Cuánto tiempo toma definir el alcance?
Depende de la complejidad. Un proceso acotado puede aclararse en pocas sesiones. Un sistema con varias integraciones y áreas requiere más trabajo de levantamiento.
¿Quién debe participar en la definición del alcance?
Quien decide el presupuesto y quienes usan el proceso a diario. Si solo participa uno de los dos el alcance queda incompleto.
Si tienes un proceso que quieres sistematizar y no sabes por dónde ordenar el alcance conversemos.