Definir el alcance y redactar el brief del proyecto final

2428. Identidad de la lección

Módulo

5.16 — Proyecto final

Lección

1 — Definir el alcance y redactar el brief del proyecto final

Tipo académico

Integración

Tipo de esquema

Práctica

Orden

1 de 3 en este módulo

Secuencia

Sigue a 5.15 L2 — Dirigir decisiones coherentes entre alternativas; entrega el trabajo a 5.16 L2 — Dirigir, revisar y validar la implementación

Tiempo estimado

45–60 minutos, incluida la práctica

2429. Objetivo de aprendizaje

Al terminar esta lección, podrás entregar un brief de proyecto final que establezca la promesa para el jugador, el alcance acotado, las responsabilidades, las restricciones, el flujo de trabajo con IA, las evidencias de validación y la definición de terminado.

2430. Por qué importa

Un proyecto final no es una acumulación de funcionalidades ambiciosas. Es una afirmación sobre lo que vas a construir, por qué importa y cómo otra persona podrá determinar si funciona. Un brief preciso permite tomar decisiones difíciles sin perder la promesa central del proyecto. También proporciona a la IA un contexto delimitado para colaborar, en lugar de dejar que expanda el trabajo sin control. El brief será la referencia para implementar, revisar y presentar las evidencias finales.

2431. Conocimientos previos

Ya deberías poder:

• expresar una promesa para el jugador y dirigir decisiones coherentes entre alternativas, como se trabajó en 5.15 L2 — Dirigir decisiones coherentes entre alternativas;
• distinguir los objetivos de la experiencia del jugador de los detalles de implementación;
• separar la intención creativa de las restricciones técnicas;
• usar la IA como colaboradora dirigida y evaluar sus resultados antes de aceptarlos;
• describir un método de validación que produzca evidencias observables.

Esta lección convierte esas decisiones en el contrato rector del proceso de construcción y revisión del proyecto final.

2432. Concepto central

Un brief de proyecto final es un contrato para obtener un resultado revisable. Convierte una intención en límites concretos. El contrato debe responder siete preguntas:

1. ¿Qué debe experimentar o conseguir el jugador?
2. ¿Qué está incluido y qué queda excluido de forma explícita?
3. ¿Quién es responsable de cada decisión o entrega importante?
4. ¿Qué restricciones técnicas, creativas, de tiempo o de herramientas aplican?
5. ¿Cómo puede contribuir la IA y qué responsabilidad sigue siendo tuya?
6. ¿Qué evidencias demostrarán que el resultado está terminado y es coherente?
7. ¿Qué condiciones definen que está terminado para poder aceptar el resultado?

Un objetivo como «crear un juego de acción convincente» no se puede revisar. En cambio, una formulación como «entregar un encuentro jugable en el que el jugador use dos herramientas legibles para escapar de una amenaza identificada, con un recorrido completo desde el inicio hasta el resultado y evidencias de validación registradas» sí es revisable: identifica una experiencia, un límite y un resultado observable.

2433. Modelo mental

Usa el contrato CAPSTONE:

Un brief útil es suficientemente específico para guiar la acción, pero suficientemente pequeño para mantenerse estable durante la implementación. Si una sección no puede evaluarse, conviértela en una condición observable o elimínala del contrato.

2434. Ejemplo concreto

Imagina que el objetivo significativo es: «Crear un momento de escape tenso que recompense la observación cuidadosa».

Un brief débil diría:

Crear una secuencia de escape tensa, con una atmósfera convincente, varios tipos de enemigos, múltiples rutas y sonido pulido.

Este brief mezcla una meta con una expansión de alcance sin límite. No establece evidencias ni un punto claro de finalización.

Un brief acotado diría:

Promesa central: El jugador identifica una pista ambiental visible, elige entre dos rutas de escape y alcanza un resultado seguro mientras está bajo presión. Incluido: un espacio de escape jugable, un patrón de amenaza, dos rutas con riesgos distintos, una presentación legible de la pista y un resultado claro de éxito y fracaso. Excluido: tipos adicionales de enemigos, sistemas de progresión, espacios extra y contenido posterior a este encuentro. Evidencias: una grabación de una partida desde el inicio, un registro breve de pruebas de al menos tres intentos y una lista que demuestre que se probaron ambas rutas, los dos resultados y la legibilidad de la pista. Terminado cuando: el encuentro puede iniciarse, completarse o fallarse, reiniciarse y explicarse sin depender de supuestos que no estén documentados.

La segunda versión todavía deja espacio para decisiones creativas, pero hace que el resultado sea inspeccionable e impide que las ideas cercanas se conviertan silenciosamente en requisitos.

2435. Flujo de trabajo con IA

Usa la IA para aclarar y poner a prueba el contrato, no para decidir por ti el propósito del proyecto.

1. Redacta la primera versión del brief sin pedirle a la IA que invente el concepto.
2. Entrégale el brief y pídele que detecte lenguaje ambiguo, alcance oculto, restricciones en conflicto, evidencias ausentes y criterios que no puedan probarse.
3. Compara cada sugerencia con la promesa para el jugador y con tu capacidad disponible.
4. Acepta, rechaza o modifica las sugerencias de forma explícita. Registra en el brief las decisiones que cambien el resultado.
5. Pide a la IA una comprobación final de coherencia: cada elemento incluido debe apoyar la promesa, cada condición de terminado debe tener una evidencia y cada responsabilidad debe nombrar a la persona encargada.
6. Trata el brief final como tu decisión. La IA puede revelar vacíos; no es dueña del alcance ni de la aceptación del resultado.

Si la IA propone una funcionalidad atractiva pero innecesaria para demostrar la promesa, colócala en una lista de fuera de alcance o de posibles trabajos futuros, en lugar de incorporarla automáticamente al proyecto final.

2436. Error común

El error más frecuente es redactar un inventario de funcionalidades y llamarlo brief. Una lista de mecánicas, recursos visuales y tareas técnicas no explica qué experiencia importa más para el jugador ni cómo se juzgará el resultado. Otro error habitual es usar términos vagos como «pulido», «divertido» o «profesional» sin indicar una evidencia observable. Sustituye esas palabras por condiciones que un revisor pueda inspeccionar, ejecutar, comparar o reproducir.

2437. Práctica guiada

Redacta un brief de una página usando el contrato CAPSTONE. Completa estos campos:

1. Promesa central: escribe una frase que empiece por «El jugador podrá…».
2. Resultado significativo: explica qué hace que este proyecto merezca construirse o revisarse.
3. Dentro del alcance: enumera solo los elementos mínimos necesarios para cumplir la promesa.
4. Fuera del alcance: enumera al menos tres incorporaciones tentadoras que no serán necesarias para terminar.
5. Responsabilidades: indica quién se encarga de la dirección creativa, las decisiones de implementación, los cambios asistidos por IA, las pruebas y la aceptación final. Si trabajas solo, indica tu nombre y distingue los papeles que desempeñas.
6. Restricciones: especifica la plataforma o entorno objetivo, el tiempo disponible, los límites técnicos, los límites de contenido y cualquier otra condición no negociable.
7. Flujo con IA: establece para qué puede ayudar la IA, qué debes revisar y qué decisiones no pueden delegarse.
8. Evidencias: nombra las compilaciones, grabaciones, notas de prueba, capturas, trazas u otros artefactos que demostrarán el resultado.
9. Definición de terminado: escribe entre cinco y ocho condiciones binarias o inspeccionables. Evita «bueno», «pulido» o «completo» salvo que definas cómo se comprobarán.

Después toma una decisión de alcance: elimina un elemento incluido y explica si la promesa central queda debilitada, permanece igual o deja de poder validarse. Solo vuelve a incluirlo si puedes defender que es necesario.

2438. Práctica independiente

Entrega tu brief a un compañero o a la IA con esta consigna:

Encuentra cada afirmación ambigua, ilimitada, sin responsable, sin evidencia o desconectada de la promesa central. No añadas funcionalidades. Devuelve la afirmación, el riesgo que crea y una pregunta que obligue a tomar una decisión más clara.

Para cada observación, revisa el brief o registra una razón fundamentada para rechazarla. Termina con una versión compacta que un colaborador pueda utilizar sin necesitar una explicación oral tuya.

2439. Validación / evidencia

2440. Puntos clave

• Un brief de proyecto final es un contrato para obtener un resultado revisable, no una lista de funcionalidades.
• El alcance se define tanto por las exclusiones como por las inclusiones.
• Las responsabilidades deben abarcar decisiones, revisión, pruebas y aceptación, no solo implementación.
• La IA puede desafiar ambigüedades y revelar vacíos, pero tú conservas la responsabilidad sobre el alcance y el criterio.
• La definición de terminado debe conectar condiciones observables con evidencias concretas.

2441. Siguiente lección

Continúa con 5.16 L2 — Dirigir, revisar y validar la implementación. Usa el brief entregado, las notas de revisión y la respuesta al desafío de alcance como entrada rectora para las decisiones de implementación. No añadas trabajo fuera del contrato sin registrar y evaluar un cambio explícito de alcance.

2442. Comprobación