La mayoría de los «documentos de alcance» son una lista de funciones con viñetas y una cifra. Eso no es un documento de alcance. Es una suposición con formato.
Uno real es lo bastante específico como para que dos equipos de ingeniería distintos, leyendo solo el documento, construyeran un producto reconociblemente idéntico. Esto es lo que eso realmente requiere.
La respuesta corta
| Sección | Qué previene |
|---|---|
| Enunciado del problema | Construir lo equivocado con eficiencia |
| Flujos de usuario | Funciones que no se conectan en un producto que funciona |
| Lista de funciones priorizada | Ampliación de alcance disfrazada de «solo una cosa más» |
| Arquitectura técnica | Reconstruir en el mes cuatro porque el stack no escalaba |
| Lista de pantallas / prototipo | Sorpresas de diseño a mitad de la construcción |
| Presupuesto módulo a módulo | Una única cifra que nadie puede verificar ni ajustar |
| Riesgos y dependencias | Un retraso de calendario por algo que nadie señaló |
| Exclusiones explícitas | La fuente más frecuente de disputas de alcance |
Ocho secciones. Si faltan dos o tres, tiene una propuesta, no un plan.
Un enunciado del problema, no una lista de funciones
El documento debe abrir con el problema que se resuelve y quién lo tiene, en lenguaje sencillo, antes de nombrar una sola función. Suena obvio y se salta constantemente.
Por qué importa: cada decisión de alcance posterior se pone a prueba contra esto. Cuando aparece una solicitud de función en la semana seis, «¿resuelve esto el problema declarado?» es un filtro más rápido y honesto que «¿suena útil?».
Una versión débil: «Una app para conectar operadores de flotas con mecánicos». Una versión que funciona nombra el dolor real - los operadores actualmente dedican de dos a seis horas por avería buscando un mecánico disponible por teléfono, sin forma de verificar su capacidad de antemano.
Flujos de usuario antes que listas de funciones
Las funciones aisladas no dicen si el producto funciona. Los flujos sí.
El documento debe mapear las dos o tres rutas centrales que un usuario realmente recorre de principio a fin - no cada pantalla, sino la secuencia que hace funcionar el producto. Aquí es donde descubre que «añadir un sistema de valoraciones» exige implícitamente «gestionar disputas cuando la valoración es injusta», algo que nadie había pensado en definir por separado.
Una lista de funciones realmente priorizada
No una lista plana de viñetas - una lista ordenada según qué rompe el producto si falta frente a lo que estaría bien tener. Ya hemos escrito sobre reducir una lista de 46 funciones a 11 usando exactamente esta prueba: si esto falta, ¿sigue funcionando el bucle central?
Cada función que pasa esa prueba entra en «Imprescindible». Todo lo demás va a una sección «Fase dos» claramente etiquetada - documentada, estimada a grandes rasgos, y explícitamente fuera de lo que se construye ahora. Esta sola práctica evita más disputas de alcance que cualquier cláusula contractual.
Arquitectura técnica, con razones
No solo una lista de tecnologías - el razonamiento detrás de cada elección, porque eso es lo que permite a alguien evaluar si las decisiones siguen teniendo sentido seis meses después.
Un documento de alcance debe indicar el stack, el enfoque de hosting, y las dos o tres decisiones caras de revertir - la elección de base de datos para un producto transaccional, si las notificaciones van por WhatsApp o solo por email, si la arquitectura necesita soportar varias plataformas después aunque lance en una sola ahora.
Pantallas o un prototipo, no una descripción
«Un panel limpio y moderno» no es una especificación. Cinco a ocho pantallas clave, idealmente como prototipo clicable, eliminan la mayor fuente de sorpresas a mitad de la construcción: que el fundador y el equipo tengan imágenes distintas de la misma función en la cabeza.
No hace falta que sea un diseño final al píxel. Debe ser lo bastante específico como para que «el panel de administración» deje de ser una abstracción y se convierta en algo real y discutible.
Un presupuesto desglosado por módulo, no una cifra única
Un precio único esconde cada suposición que lo produjo. Un desglose módulo a módulo - cuentas y permisos, flujo transaccional central, pagos, panel de administración, etc. - hace dos cosas que una cifra única no puede: muestra qué es caro y por qué, y permite recortar un módulo concreto si el presupuesto no alcanza, en lugar de renegociar todo.
Riesgos y dependencias nombrados con precisión
El lenguaje genérico de riesgo («riesgo técnico», «riesgo de calendario») no sirve de nada. Una sección de riesgos real nombra lo concreto que podría ralentizar el proyecto - el calendario de aprobación de un proveedor de pagos, una API de terceros con límites de tasa poco claros, una decisión del fundador aún pendiente - y quién es responsable de resolverlo.
Esta sección es también donde se identifica el camino crítico: las dos o tres cosas que, si se retrasan, retrasan la fecha de lanzamiento sin importar lo bien que vaya el resto de la ingeniería.
Qué queda explícitamente excluido
Esta es la sección que la mayoría de los documentos de alcance omite por completo, y es la que más disputas evita después.
Indique claramente qué no está incluido: costes de servicios de terceros, redacción de contenido, migración de datos, soporte más allá de una ventana definida, una segunda plataforma. La mejor versión de esta sección es larga y algo tediosa de leer. Eso es una cualidad, no un defecto - la vaguedad aquí es la fuente de disputas del tipo «pensé que eso estaba incluido».
Cómo es uno real
Publicamos un Blueprint de ejemplo anonimizado que muestra las ocho secciones rellenadas para un proyecto real - no una plantilla con texto de relleno, un documento de alcance real con decisiones reales y cifras reales. Leerlo es más rápido que leer una descripción de él.
La prueba de si el suyo es real
Entregue el documento a un ingeniero que nunca haya hablado con usted y pídale que estime el calendario. Si puede hacerlo sin una llamada aclaratoria, es un documento de alcance. Si vuelve con diez preguntas, tiene una lista de funciones con un precio pegado - y esas diez preguntas son exactamente lo que surgirá como solicitudes de cambio una vez que el proyecto ya esté en marcha, cuando responderlas es mucho más caro.
¿Quiere ver cómo es un documento de alcance completo frente a un proyecto real? Nuestro Blueprint de ejemplo es el documento completo, no un extracto. O cuéntenos su proyecto y lo definiremos correctamente antes de darle una cifra.
Preguntas frecuentes
Escrito por
Shakhbozbek Usmonov
Founder & CEO, Steppe Venture Builders
