Resultado visible
Crearás 02-alcance-v1.md: una decisión razonada sobre el tipo de web, las funciones imprescindibles, las mejoras posteriores y las exclusiones. No pagarás con tiempo, errores y mantenimiento por funciones que todavía no resuelven una necesidad demostrada.
Puedes descargar la plantilla de alcance o copiarla desde esta lección.
Antes de empezar
Necesitas la ficha 01-ficha-problema.md de la lección anterior. Si todavía contiene datos críticos como [PENDIENTE], puedes decidir estructura y límites, pero no debes convertir esos datos en contenido publicado.
Al terminar podrás:
- diferenciar landing, web multipágina, catálogo y aplicación;
- reconocer cuándo una función introduce cuentas, datos persistentes o soporte;
- clasificar cada función como imprescindible, posterior o excluida;
- proponer una alternativa manual honesta para la primera versión;
- explicar qué evidencia justificaría aumentar la complejidad.
Una idea importante: la complejidad no se ve entera en la pantalla
Dos interfaces pueden mostrar el mismo botón «Reservar», pero esconder sistemas muy distintos:
- un enlace que abre el teléfono;
- un formulario que envía una solicitud;
- una agenda que consulta disponibilidad;
- una reserva confirmada con pago, cancelación y recordatorios.
El texto del botón ocupa el mismo espacio. La responsabilidad técnica y operativa no.
Cada función nueva puede añadir:
- datos que guardar y proteger;
- identidad, sesiones y recuperación de cuenta;
- permisos diferentes para clientes y personal;
- estados que deben mantenerse coherentes;
- servicios externos y claves;
- errores, reintentos y duplicados;
- moderación o atención al usuario;
- obligaciones de información, facturación o privacidad;
- mantenimiento después de publicar.
Por eso «Codex puede programarlo» no responde «¿debemos construirlo ahora?».
Vocabulario sin jerga
Landing de una página
Una página enfocada en una propuesta y una acción. Puede ser adecuada para validar interés, presentar un evento o explicar un servicio muy concreto.
No significa una página interminable con todo mezclado. Necesita jerarquía, navegación interna si es larga y un objetivo claro.
Web informativa multipágina
Varias páginas con responsabilidades distintas: Inicio, Servicios, Carta, Proyectos, Preguntas frecuentes o Contacto. Es apropiada cuando la persona necesita consultar grupos de información diferentes o compartir URLs concretas.
Puede seguir siendo completamente estática y profesional.
Catálogo
Una colección estructurada que se puede recorrer, ordenar o filtrar: platos, cursos, inmuebles, productos o proyectos. Un catálogo no implica compra. Puede generarse desde archivos o datos sin cuentas de usuario.
Aplicación web
Permite operar un proceso y mantener estado: crear presupuestos, gestionar citas, guardar favoritos, editar expedientes o trabajar con un panel. Suele requerir datos, reglas, permisos, errores y soporte.
Comercio o transacción en tiempo real
Añade compromisos difíciles de deshacer: cobrar, reservar inventario, emitir confirmaciones, cancelar, devolver dinero o coordinar disponibilidad concurrente. Normalmente exige integrar servicios especializados y diseñar operación, no solo interfaz.
Mapa de decisiones
| Necesidad principal | Primera opción razonable | Sube de nivel cuando exista evidencia de… |
|---|---|---|
| Explicar una propuesta y una acción | Landing | públicos, servicios o búsquedas claramente diferentes |
| Informar sobre un negocio | Web de 4–6 páginas | mucho contenido cambiante, sedes o responsables distintos |
| Mostrar una colección sin pago | Catálogo | filtros reales, stock, edición frecuente o volumen creciente |
| Recibir interés o una solicitud | Canal existente o formulario mínimo | seguimiento, volumen y responsable para responder |
| Guardar datos propios de cada persona | Aplicación con cuentas | necesidad validada, permisos definidos y soporte disponible |
| Vender o confirmar disponibilidad | Servicio especializado o integración | reglas, operación, cancelaciones, incidencias y cumplimiento preparados |
Árbol de decisión en siete preguntas
Responde en orden. Detente en la opción más sencilla que permita completar la tarea.
1. ¿La persona solo necesita leer, comparar o contactar?
Empieza con contenido estático. Un generador, HTML o Next.js pueden producirlo, pero no necesitas una base de datos solo para mostrar información.
2. ¿Una única página conserva una jerarquía clara?
Si la página mezcla públicos, servicios extensos o contenidos que se comparten por separado, usa varias páginas. No fuerces una landing porque parezca más fácil.
3. ¿Existe una colección que crecerá o necesita filtros?
Usa un catálogo con un formato repetible. Antes de añadir una base de datos, comprueba si archivos Markdown, JSON o un CMS sencillo cubren la frecuencia de actualización.
4. ¿La persona debe enviar información?
Decide quién la recibe, para qué, durante cuánto tiempo y qué respuesta ofrece. Empieza con el mínimo de campos y una confirmación honesta. Un formulario sin responsable es un buzón roto.
5. ¿La información debe conservarse entre visitas?
Si el estado solo ayuda en el mismo dispositivo y no es crítico, el navegador puede ser suficiente. Si debe sincronizarse, compartirse o recuperarse, necesitarás persistencia y reglas de acceso.
6. ¿Cada persona ve o modifica datos distintos?
Eso introduce identidad, autenticación y autorización. No basta con ocultar un botón: el servidor o la base de datos deben impedir accesos indebidos.
7. ¿La acción crea un compromiso real?
Pagos, reservas confirmadas, documentos jurídicos, diagnósticos o decisiones financieras requieren operación, registro y recuperación. Integra herramientas adecuadas o conserva un proceso humano hasta poder demostrar seguridad y soporte.
Una tienda, un área privada o una reserva en tiempo real añaden autenticación, pagos, protección de datos, incidencias y soporte. No son «una página más».
Caso conductor: Lumbre y Oliva
La ficha de la lección 1 pide consultar carta, precios, horario y preparar una solicitud de mesa. No pide confirmar disponibilidad en tiempo real.
Opción A: aplicación completa de reservas
Necesitaría inventario de mesas y turnos, concurrencia, estados, cancelación, protección frente a duplicados, notificaciones, acceso del personal y un procedimiento cuando algo falla.
Opción B: primera versión honesta
Una web estática de cuatro páginas:
- Inicio: propuesta y recorrido principal;
- Carta: platos, precios y alérgenos en HTML;
- Visita: horario, dirección, contacto y solicitud;
- Privacidad: comportamiento real del formulario.
El formulario valida localmente y prepara un correo revisable. Explica que no consulta disponibilidad ni confirma una mesa. La información esencial sigue accesible sin JavaScript.
La opción B no finge tener una agenda. Resuelve la tarea validada y permite aprender si realmente llegan solicitudes antes de asumir el coste de la opción A.
Puedes revisar la implementación y sus pruebas en Lumbre y Oliva, caso de Aulafy Taller.
La escalera de complejidad
No todos los proyectos deben recorrerla entera.
| Nivel | Añade | Responsabilidad nueva | Evidencia para subir |
|---|---|---|---|
| 1. Contenido | páginas, enlaces, contacto | exactitud y actualización | personas no encuentran o no entienden algo |
| 2. Interacción local | filtros, validación, calculadora | estados de interfaz y alternativa | la interacción mejora una tarea observada |
| 3. Envío | formulario o servicio externo | privacidad, entrega, spam y respuesta | volumen que no cubre el canal manual |
| 4. Persistencia | base de datos | modelo, permisos, copias y borrado | datos que deben conservarse o compartirse |
| 5. Cuentas | identidad y sesiones | autenticación, autorización y soporte | valor recurrente específico por persona |
| 6. Transacción | pago o reserva confirmada | consistencia, incidencias y devolución | operación preparada y demanda validada |
«Subir» no siempre mejora el producto. A veces la decisión profesional es permanecer en un nivel y mantenerlo bien.
Cómo clasificar funciones
Usaremos tres categorías con criterios estrictos.
IMPRESCINDIBLE
Sin esta función, la persona principal no puede conseguir el resultado definido en la ficha. Debe tener información confirmada, responsable y criterio de aceptación.
DESPUÉS
Puede aportar valor, pero depende de comprobar demanda, volumen, contenido, operación o capacidad de mantenimiento. Escribe la condición concreta para reconsiderarla.
EXCLUIDA
No debe construirse en este proyecto o esta fase por riesgo, falta de autoridad, coste desproporcionado o conflicto con el propósito. Excluir no significa olvidar: registra el motivo.
Matriz de coste oculto
Para cada función, responde:
| Pregunta | Si la respuesta es «sí»… |
|---|---|
| ¿Guarda datos? | define necesidad, retención, acceso, borrado y copia |
| ¿Necesita cuenta? | diseña alta, acceso, recuperación y soporte |
| ¿Distingue roles? | aplica autorización en servidor o base de datos |
| ¿Depende de un tercero? | documenta claves, límites, fallos y sustitución |
| ¿Puede duplicarse? | añade idempotencia o revisión humana |
| ¿Promete tiempo real? | define fuente de verdad y conflictos simultáneos |
| ¿Cobra o compromete inventario? | prepara confirmación, cancelación e incidencias |
| ¿Acepta contenido público? | añade normas, denuncia y moderación |
| ¿Afecta salud, derechos o dinero? | limita alcance y busca revisión especializada |
Si una función abre cuatro responsabilidades nuevas y todavía no tiene usuarios, probablemente pertenece a «después».
Ejemplo resuelto: clínica ficticia
Una clínica pide «web, tienda, diagnóstico con IA, agenda y chatbot». La primera versión segura incluye información revisada, equipo, preguntas frecuentes y una solicitud de cita que no pide historial médico. Agenda integrada y pagos quedan en fase dos; diagnóstico automático se excluye.
| Función pedida | Decisión | Motivo | Alternativa inicial | Reconsiderar cuando… |
|---|---|---|---|---|
| Información de tratamientos | IMPRESCINDIBLE | permite comprender la oferta | contenido revisado por responsable | cambien servicios o evidencia |
| Solicitud de cita | IMPRESCINDIBLE | facilita el siguiente paso | datos mínimos y respuesta humana | exista volumen para agenda integrada |
| Agenda en tiempo real | DESPUÉS | añade disponibilidad y conflictos | solicitud sin confirmación automática | haya proceso, responsable y fuente de verdad |
| Pago online | DESPUÉS | añade devolución e incidencias | pago por canal existente | operación y condiciones estén preparadas |
| Diagnóstico con IA | EXCLUIDA | riesgo sanitario y falta de alcance clínico | información general y contacto profesional | no se reconsidera dentro de esta web |
| Chatbot | DESPUÉS | necesita fuentes, límites y derivación | FAQ revisada | preguntas repetidas que la FAQ no resuelva |
La alternativa manual no es un fracaso
Una primera versión puede conectar con un proceso humano existente:
- correo revisado cada día;
- llamada durante horario publicado;
- hoja interna controlada;
- servicio especializado de reservas o pagos;
- confirmación manual con un plazo explicado.
La alternativa debe ser real, tener responsable y capacidad. «Ya responderemos» no es un proceso. Documenta horario, plazo, mensaje y qué ocurre si no llega la solicitud.
El desarrollo progresivo conserva contenido y función esencial disponibles mientras añade mejoras cuando el navegador, la conexión o el proyecto lo permiten.
Plantilla de alcance V1
Copia en 02-alcance-v1.md:
# Alcance de la primera versión
## Decisión
- Tipo de web:
- Persona y necesidad:
- Acción principal:
- Versión uno en una frase:
## Funciones
| Función | IMPRESCINDIBLE / DESPUÉS / EXCLUIDA | Motivo | Dependencias | Alternativa inicial | Reconsiderar cuando… |
|---|---|---|---|---|---|
| | | | | | |
## Datos y operación
- Datos que se muestran:
- Datos que se reciben:
- Datos que se guardan:
- Responsable de responder:
- Plazo prometido:
- Procedimiento si falla:
## Páginas de la V1
-
## Límites que deben verse en la interfaz
-
## Criterios de salida
- [ ] La V1 cabe en una frase.
- [ ] Existe una única acción principal.
- [ ] Cada función imprescindible responde a una necesidad.
- [ ] Cada función posterior tiene condición para reconsiderarse.
- [ ] Las exclusiones peligrosas están explicadas.
- [ ] Datos, responsables y alternativa manual están identificados.
Prompt para Codex
La documentación de Codex recomienda describir objetivo, contexto, restricciones y qué significa terminar. En una decisión compleja conviene planificar antes de implementar.
Trabaja en modo análisis. No crees, instales ni modifiques archivos.
OBJETIVO
Elegir el tipo de web y el alcance profesional más pequeño que satisfaga
la necesidad de 01-ficha-problema.md.
CONTEXTO
[PEGA LA FICHA Y LA LISTA DE FUNCIONES SOLICITADAS]
CLASIFICACIÓN
- IMPRESCINDIBLE: sin ella no se completa el resultado principal.
- DESPUÉS: necesita evidencia, volumen u operación que todavía no existe.
- EXCLUIDA: riesgo, falta de autoridad o conflicto con el propósito.
PARA CADA FUNCIÓN
1. necesidad a la que responde;
2. datos que muestra, recibe o guarda;
3. cuentas, roles, servicios y dependencias;
4. fallo más importante y forma de recuperación;
5. responsable de operarla después de publicar;
6. alternativa manual o más sencilla;
7. evidencia concreta para reconsiderarla.
LÍMITES
- No elijas tecnología por moda.
- No supongas presupuesto, equipo, tráfico ni datos inexistentes.
- No conviertas una solicitud en confirmación automática.
- Señala [PENDIENTE] cuando falte una decisión del negocio.
- Si hay riesgo sanitario, jurídico o financiero, limita el alcance y marca
la revisión profesional necesaria.
SALIDA
1. Recomendación: landing, multipágina, catálogo o aplicación.
2. Versión uno en una frase.
3. Tabla IMPRESCINDIBLE / DESPUÉS / EXCLUIDA.
4. Páginas o recorridos mínimos.
5. Datos y operación necesarios.
6. Cinco criterios de salida observables.
7. Máximo cinco preguntas que podrían cambiar la recomendación.
TERMINADO CUANDO
La propuesta pueda construirse y probarse sin depender de una función
pospuesta ni prometer una capacidad que no existe.
Cómo revisar la recomendación de Codex
No aceptes automáticamente la opción más técnica. Comprueba:
- ¿Cada imprescindible enlaza con una necesidad de la ficha?
- ¿La recomendación distingue mostrar, enviar, guardar y confirmar?
- ¿Las cuentas aparecen solo porque existe estado personal persistente?
- ¿Cada función posterior tiene una condición medible, no «más adelante»?
- ¿La alternativa manual tiene responsable y plazo?
- ¿Las exclusiones protegen a la persona o solo reducen trabajo?
Pide una segunda revisión si Codex propone base de datos, autenticación o pagos sin explicar datos, permisos, fallos y soporte.
Práctica guiada
Usa tu ficha o elige uno de estos proyectos:
- portafolio de estudiante con tres proyectos;
- restaurante con carta y solicitud de mesa;
- academia con niveles, horarios y solicitud de prueba;
- pequeña aplicación de presupuestos que debe guardar clientes y documentos.
Paso 1. Lista deseos sin filtrarlos
Incluye también ideas ambiciosas: cuentas, chatbot, pagos, panel o notificaciones. Todavía no decidas.
Paso 2. Aplica la matriz de coste oculto
Marca datos, identidad, roles, terceros, tiempo real, transacciones y moderación.
Paso 3. Clasifica
Exige una necesidad y un criterio para cada imprescindible. Escribe la condición de entrada de cada función posterior.
Paso 4. Elige el tipo de web
Selecciona la opción más sencilla que incluya todos los imprescindibles. Si una función obliga a convertirla en aplicación, comprueba si puede sustituirse temporalmente por un proceso manual.
Paso 5. Prueba la frase de la V1
La primera versión es [TIPO DE WEB] para que [PERSONA]
pueda [RESULTADO] mediante [ACCIÓN PRINCIPAL], sin [LÍMITE CLAVE].
Ejemplo:
La primera versión es una web estática de cuatro páginas para que una persona pueda consultar carta y horario y preparar una solicitud de mesa, sin prometer disponibilidad en tiempo real.
Paso 6. Haz una crítica adversarial
Critica este alcance sin editar archivos. Intenta demostrar uno de estos fallos:
- una función imprescindible no responde a la necesidad principal;
- una función pospuesta es necesaria para que la V1 tenga sentido;
- una función aparentemente simple introduce datos, permisos o soporte;
- la alternativa manual no tiene responsable o capacidad;
- una exclusión deja a la persona sin salida;
- un criterio de reconsideración no se puede medir.
Por cada hallazgo cita la frase exacta y propone la corrección mínima.
No añadas funciones nuevas salvo que sean necesarias para corregir un fallo.
ALCANCE:
[PEGA 02-alcance-v1.md]
Rúbrica de salida
Puntúa 0, 1 o 2:
| Criterio | 0 | 1 | 2 |
|---|---|---|---|
| Tipo de web | elegido por moda | razonable pero no justificado | deriva de necesidades y responsabilidades |
| Acción principal | varias compiten | existe pero es vaga | una acción y un después claros |
| Imprescindibles | lista de deseos | parcialmente justificados | todos enlazan con necesidad y prueba |
| Posteriores | «algún día» | tienen motivo | tienen evidencia concreta de entrada |
| Exclusiones | no existen | reducen alcance | explican riesgo o falta de autoridad |
| Datos y operación | ignorados | incompletos | datos, responsable, plazo y fallo definidos |
| Recuperación | se supone que funciona | alternativa vaga | alternativa real y comunicada |
Necesitas 11 de 14 puntos y ningún cero en imprescindibles, datos u operación y recuperación.
Criterio de salida
Tu versión uno debe caber en una frase y tener una acción principal. Otra persona debe poder distinguir qué funciona al publicar, qué depende de confirmación humana y qué no se construirá.
Guarda:
02-alcance-v1.md;evidencias/02-matriz-funciones.md;evidencias/02-revision.txtcon puntuación y cambios.
No compres servicios, crees cuentas externas ni publiques durante esta práctica.
Error frecuente y recuperación
Error 1: añadir funciones porque Codex puede programarlas. Recuperación: exige persona, necesidad, responsable y prueba. Si falta uno, aplaza.
Error 2: llamar MVP a una demo que no completa ninguna tarea. Recuperación: reduce funciones, no el resultado principal. La versión debe ser pequeña y utilizable.
Error 3: confundir formulario con proceso. Recuperación: define quién recibe, cuándo responde, qué registra y cómo recupera un mensaje perdido.
Error 4: construir cuentas para guardar una preferencia menor. Recuperación: prueba primero almacenamiento local o una experiencia sin cuenta y mide si la sincronización aporta valor.
Error 5: dejar una función peligrosa en «después» sin límites. Recuperación: si no pertenece al propósito o falta autoridad, clasifícala como excluida.
Autoevaluación
1. ¿Una web multipágina necesita base de datos? No. Puede generarse de forma estática y actualizarse desde archivos versionados.
2. ¿Cuándo un catálogo empieza a parecer una aplicación? Cuando necesita estado personal, edición frecuente, stock, reglas, cuentas o transacciones; el número exacto de elementos no decide por sí solo.
3. ¿Por qué un área privada aumenta tanto el alcance? Porque añade identidad, sesiones, recuperación de cuenta, autorización, datos personales y soporte.
4. ¿Una alternativa manual siempre es aceptable? No. Debe tener capacidad, responsable, plazo y comunicación clara. En alto riesgo puede ser necesaria revisión especializada o exclusión completa.
5. ¿Qué diferencia hay entre solicitar y reservar? Solicitar expresa una intención pendiente de respuesta. Reservar compromete disponibilidad y exige una fuente de verdad, confirmación y gestión de conflictos.
Siguiente paso
Con el alcance decidido, la lección 3 prepara un espacio de trabajo seguro para Codex. Todavía no construirás la web: primero definirás instrucciones duraderas, permisos y una inspección inicial sin cambios.