Escribe un brief externo listo para IA

1875. Identidad de la lección

Módulo

4.13 — Externalización

Lección

Escribe un brief externo listo para IA

Tipo académico

Construcción guiada

Tipo de esquema

práctica

Orden

Lección 2 del módulo

Tiempo estimado

45–60 minutos, incluida la práctica

Esta lección convierte la interfaz de transferencia de la lección anterior en un brief utilizable. El brief está diseñado tanto para un contratista humano como para un colaborador asistido por IA. Define los entregables requeridos, qué se puede cambiar, qué debe permanecer estable, cómo se revisará el resultado y qué evidencia hace falta antes de integrarlo.

1876. Objetivo de aprendizaje

Después de esta lección, podrás redactar un brief de externalización con alcance acotado, entradas y entregables explícitos, puntos de revisión, restricciones de integración y criterios de aceptación observables.

1877. Por qué importa

Externalizar no elimina la responsabilidad de diseño de quien dirige el trabajo. Una solicitud vaga transfiere ambigüedad en lugar de transferir una tarea. Esa ambigüedad se convierte en retrabajo, implementaciones inconsistentes o riesgo de integración cuando la contribución vuelve al juego. Un buen brief da libertad para resolver un problema definido, pero conserva las reglas del proyecto y la autoridad de revisión.

En una contribución asistida por IA, este límite es todavía más importante: el colaborador puede producir un resultado plausible sin conocer qué supuestos del proyecto son innegociables. El brief proporciona esos supuestos antes de comenzar la implementación. Nombrar los entregables también evita que un informe informal de progreso se trate como una transferencia terminada.

1878. Conocimientos previos

Ya deberías poder:

• distinguir alcance, entradas, implementación y aceptación a partir de A handoff is an interface;
• indicar qué evidencia se utiliza para aceptar o rechazar trabajo externalizado;
• describir una tarea como una interfaz entre quien solicita, quien contribuye y el punto de integración;
• identificar qué parte de una tarea de juego se puede delegar con seguridad y qué parte sigue bajo revisión de la persona responsable del proyecto.

No se requiere un motor ni un lenguaje de programación específico para este ejercicio de redacción.

1879. Concepto central

La delegación acotada consiste en delegar un resultado definido sin delegar la autoridad para redefinir el problema.

Un brief externo debe separar siete elementos:

1. Resultado: qué debe existir para el jugador o para el equipo.
2. Entradas: información, archivos, convenciones y estado inicial que puede utilizar el colaborador.
3. Entregables: materiales concretos que debe devolver el colaborador, como archivos modificados, un recurso, un informe breve, capturas o evidencia de pruebas.
4. Límites: qué puede cambiar y qué debe permanecer intacto.
5. Puntos de revisión: momentos en los que el trabajo debe detenerse para ser inspeccionado o aprobado.
6. Evidencia de aceptación: comprobaciones observables que determinan si el resultado se acepta.
7. Requisitos de entrega y compatibilidad: versión de la herramienta o del motor, formatos de archivos fuente editables y de exportación, convenciones de nombres y rutas, mecanismo de entrega (rama, parche o paquete), límites del repositorio o paquete y una declaración explícita de que el colaborador no está autorizado para fusionar cambios, salvo que ese permiso se conceda por separado.

Los entregables son un campo obligatorio del brief, no un detalle administrativo opcional. Los criterios de aceptación describen si el resultado es aceptable; los entregables describen qué debe devolverse para poder revisarlo e integrarlo. Un brief puede exigir tanto una implementación modificada como un resumen de cambios, evidencia de pruebas y una lista de limitaciones conocidas.

El colaborador es responsable de proponer la implementación dentro de los límites. La persona responsable del proyecto conserva la responsabilidad sobre esos límites, la decisión de revisión y la integración en el juego completo.

1880. Modelo mental

Usa el modelo Brief → Punto de control → Evidencia:

También puedes comprobar un brief completo con esta frase:

“El colaborador puede cambiar X, usando Y, pero no debe cambiar Z; los entregables requeridos son D; el trabajo se revisa en G, y la aceptación exige E.”

Si falta uno de estos campos, la tarea probablemente está subespecificada. Si el brief contiene por adelantado cada decisión de implementación, la tarea está sobrerrestringida y la delegación deja de aportar valor.

1881. Ejemplo concreto

Solicitud débil:

Mejora el panel del inventario para que se sienta más limpio y fácil de usar.

Brief externo listo para IA:

Tarea: Revisar la presentación de la selección de objetos en el panel del inventario existente.

Resultado deseado: Cuando el jugador se desplace entre los objetos disponibles, el objeto seleccionado debe distinguirse visualmente, el nombre y la cantidad deben seguir siendo legibles y el panel debe comunicar los objetos no disponibles sin cambiar las reglas del inventario.

Entradas: Usa la pantalla actual del inventario, los datos existentes de los objetos, el comportamiento actual de selección, las convenciones tipográficas del proyecto y la captura de pantalla del diseño objetivo. Solicita aclaraciones si falta alguna entrada necesaria.

Dentro del alcance: Resaltado de selección, presentación del nombre y la cantidad, estado visual de objeto no disponible y espaciado dentro del panel existente.

Fuera del alcance: Estructuras de datos del inventario, ordenamiento de objetos, costes, datos de guardado, asignaciones del mando, reglas de navegación y otras pantallas.

Entregables requeridos: InventoryPanel.presentation.ts con los tres estados de selección implementados; InventoryPanel.presentation.test.ts; captures/inventory-selection-1920x1080.png; y CHANGELOG-inventory-selection.md.

Requisitos de entrega y compatibilidad:

• Versión de herramienta o motor: No aplica en este ejemplo. Usa la cadena de herramientas fijada por el repositorio e indica en el resumen de cambios las versiones utilizadas.
• Formatos fuente editables: TypeScript (.ts) para los archivos de presentación y pruebas, y Markdown (.md) para el resumen de cambios.
• Formato de exportación: PNG a 1920×1080 para la captura de revisión requerida.
• Convenciones de nombres y rutas: Usa exactamente los nombres de archivo y las rutas indicados arriba. No cambies el nombre ni la ubicación de archivos existentes.
• Mecanismo de entrega: Devuelve un único parche identificado que contenga los archivos requeridos y ningún cambio ajeno a la tarea.
• Límite del repositorio: El parche solo puede modificar InventoryPanel.presentation.ts y InventoryPanel.presentation.test.ts, y solo puede añadir la captura PNG y el resumen Markdown indicados.
• Requisitos de acceso: Acceso de solo lectura a los archivos actuales de presentación del inventario, la interfaz existente de datos de objetos, las convenciones tipográficas y la captura del diseño objetivo. No se requiere acceso de escritura al repositorio.
• Límite de autoridad: El colaborador puede preparar el parche, pero no está autorizado para fusionar los cambios, aplicar el parche ni integrarlo. Esa decisión corresponde a la persona responsable del proyecto.

Restricciones de integración: Conserva los identificadores de los objetos y los eventos de selección existentes. No añadas dependencias nuevas. Mantén la contribución aislada en la capa de presentación del inventario. Enumera todos los archivos modificados e identifica cualquier supuesto utilizado.

Puntos de revisión:

1. Antes de implementar: entrega una interpretación breve de los estados solicitados e identifica las ambigüedades.
2. Después de la primera pasada visual: entrega una captura o grabación que muestre los estados seleccionado, no seleccionado y no disponible a 1920×1080.
3. Antes de integrar: entrega el resumen final de cambios, los entregables requeridos, la evidencia de pruebas y cualquier limitación conocida.

Criterios de aceptación:

• A la resolución de prueba documentada y escala de UI 100%, quien revisa puede identificar seleccionado, no seleccionado y no disponible sin depender del color, usando un marcador no cromático (icono, borde o etiqueta) en la captura o en una nota de inspección estructurada.
• En esa misma captura, el nombre y la cantidad del objeto son totalmente visibles: sin recorte, sin solaparse con el resaltado, y con contraste suficiente para leer las cadenas sin ampliar.
• Los valores del inventario y el comportamiento de navegación existentes no cambian.
• Una segunda comprobación a escala de UI 125% deja esas dos cadenas sin recortar; si no puedes hacer la comprobación visual, se acepta una nota de verificación entre pares o una lista de inspección.
• El colaborador entrega todos los entregables requeridos, incluida la lista de archivos modificados y cualquier comprobación fallida u omitida.

Decisión de integración: La persona responsable del proyecto revisa la evidencia e integra la contribución únicamente después de comprobar los criterios de aceptación y completar la revisión de los entregables.

Observa lo que el brief no hace: no prescribe cada valor de color, curva de animación o método de implementación. Esas decisiones siguen disponibles para el colaborador, pero están limitadas por los estados requeridos, los entregables y las restricciones de integración.

1882. Flujo de trabajo nativo de IA

Un colaborador asistido por IA debe trabajar por etapas, no recibir autoridad sin límites:

1. Reformulación: Pide a la IA que reformule el resultado, el alcance, las exclusiones, los entregables requeridos, los puntos de control y los criterios de aceptación. Corrige la reformulación antes de implementar.
2. Plan: Pide un plan de cambios y una lista de archivos o sistemas potencialmente afectados. Rechaza los planes que crucen los límites del alcance o no contemplen un entregable requerido.
3. Propuesta pequeña: Solicita una modificación de implementación o presentación acotada cada vez.
4. Evidencia: Exige un informe de archivos modificados, supuestos, comprobaciones realizadas, problemas pendientes y cada entregable requerido.
5. Revisión humana: Compara el resultado con los criterios de aceptación y las restricciones de integración. La declaración de la IA de que terminó no es evidencia.

La IA puede proponer una implementación. No decide si el alcance debe ampliarse, si una excepción es aceptable, si un entregable es suficiente ni si la contribución se integra.

1883. Error común

El error común es escribir criterios de aceptación como preferencias:

• “Hazlo más pulido.”
• “Mantenlo intuitivo.”
• “Usa una animación bonita.”

Estas frases pueden comunicar gusto, pero no establecen una decisión de revisión. Convierte cada preferencia en una condición observable, una situación de prueba o un artefacto de comparación. Si una cualidad no se puede comprobar mirando, jugando, midiendo o inspeccionando la contribución, todavía no es un criterio de aceptación suficiente.

Un error relacionado es omitir los entregables porque se espera que el colaborador simplemente “devuelva el trabajo terminado”. Sin una lista concreta, puede devolver una implementación sin la lista de archivos modificados, la evidencia de pruebas, las capturas o las limitaciones necesarias para revisarla. Especifica los materiales de transferencia en el brief y comprueba su presencia por separado de la calidad de la implementación.

Otro error es permitir que el colaborador modifique sistemas cercanos “ya que está trabajando ahí”. Eso amplía el riesgo de integración sin pasar por un punto de revisión. Registra esas mejoras adyacentes como solicitudes separadas.

1884. Práctica guiada

Redacta un brief externo completo para una tarea acotada de un proyecto de juego. Entrega ese brief como la evaluación práctica calificada de esta lección; el cuestionario sigue siendo solo una comprobación de conocimiento. Elige una tarea como:

• revisar un estado de presentación de un menú;
• añadir un efecto de feedback visual a una interacción existente;
• preparar un cambio pequeño de presentación relacionado con accesibilidad;
• documentar un cambio de ajuste de gameplay muy definido sin modificar la regla subyacente.

No elijas una tarea que requiera redefinir la economía, la progresión, el contrato de dificultad o las interacciones principales del juego. El ejercicio trata sobre delegación y límites de integración, no sobre ampliar el diseño.

Usa esta secuencia:

Paso 1 — Define el resultado

Escribe una frase que describa el resultado observable. Evita verbos de implementación como “refactoriza todo” o “hazlo mejor”.

Paso 2 — Acota la tarea

Enumera:

• las entradas que recibe el colaborador;
• los sistemas, archivos, pantallas o comportamientos dentro del alcance;
• las exclusiones explícitas;
• las dependencias o supuestos que deben confirmarse.

Paso 3 — Nombra los entregables

Escribe los materiales exactos que el colaborador debe devolver. Incluye la contribución y el paquete de revisión, por ejemplo:

• archivos o recursos modificados;
• un resumen breve de cambios;
• capturas, grabaciones u otra evidencia de presentación definida;
• resultados de pruebas, incluidas las comprobaciones fallidas u omitidas;
• supuestos y limitaciones conocidas.

No escribas “entrega el trabajo terminado” como único entregable. Cada elemento requerido debe poder identificarse en la transferencia. Añade un campo de Entrega y compatibilidad: versión de herramienta o motor, formatos de fuente y exportación, reglas de nombres o rutas, mecanismo de rama/parche/paquete, límite de repositorio y ausencia de autoridad de fusión salvo concesión aparte.

Paso 4 — Añade puntos de revisión

Define al menos dos puntos de control:

• uno antes de implementar o después de interpretar la solicitud;
• otro antes de integrar.

Para cada punto, indica quién revisa el trabajo, qué entregables se esperan y qué evidencia se necesita.

Paso 5 — Escribe criterios de aceptación

Escribe al menos cuatro criterios. Cada uno debe nombrar el entorno de prueba, la acción, el estado observable esperado y la condición de aprobado o fallido. No uses “se distingue de un vistazo” ni “sigue siendo legible” sin un método de comparación. Incluye una comprobación que no dependa solo del color o que acepte evidencia alternativa. Incluye al menos un criterio que proteja el comportamiento existente, otro que compruebe el informe de cambios o limitaciones y otro que confirme que están presentes todos los entregables y archivos de entrega.

Paso 6 — Identifica el riesgo de integración

Nombra la forma más probable en que la contribución podría dañar o complicar el proyecto. Añade una restricción o requisito de evidencia que reduzca ese riesgo.

Paso 7 — Realiza la prueba de reformulación

Lee tu brief como si fueras un colaborador externo sin contexto implícito. Escribe una reformulación de cinco líneas que incluya los entregables esperados. Si la reformulación introduce una interpretación nueva u omite un material requerido, revisa el brief antes de considerarlo terminado.

1885. Validación / evidencia

1886. Conclusiones clave

• Delega un resultado acotado, no la autoridad para redefinir el problema.
• Trata los entregables como un campo obligatorio del brief: nombra cada material necesario para la revisión y la integración.
• Separa resultado, entradas, límites, puntos de revisión y evidencia de aceptación.
• Trata la salida de la IA como una propuesta que requiere evidencia y revisión humana.
• Convierte las preferencias en criterios de aceptación observables y protege la integración nombrando exclusiones.

1887. Siguiente lección

Continúa con 4.14 — Fundamentos legales.

1888. Comprobación