1860. Identidad de la lección
Esta lección amplía la lección anterior, 4.12 L2 — Haz visibles las transferencias del equipo. Una transferencia visible no es automáticamente una transferencia utilizable. La persona receptora también necesita una interfaz precisa para realizar el trabajo.
1861. Objetivo de aprendizaje
Después de esta lección, podrás identificar ambigüedades en una solicitud de trabajo externalizado separando su alcance, entradas, salidas, restricciones y evidencias de aceptación.
1862. Por qué importa
El trabajo externalizado falla cuando quien solicita y quien recibe mantienen definiciones distintas de lo que significa “terminado”. Una solicitud breve puede ocultar recursos faltantes, supuestos incompatibles, un alcance sin límites o un criterio de aceptación que nadie puede comprobar. Tratar la transferencia como una interfaz hace explícitos esos supuestos antes de comenzar la implementación. Así se protege la coherencia del juego sin exigir que quien encarga el trabajo dicte cada detalle técnico.
1863. Conocimientos previos
Ya debes poder hacer visible una transferencia de equipo nombrando el artefacto, la persona responsable, la evidencia y la decisión de aceptación, como se practicó en 4.12 L2 — Haz visibles las transferencias del equipo. También debes distinguir entre el resultado deseado y la implementación utilizada para producirlo.
1864. Concepto central
Una solicitud de outsourcing es una interfaz entre dos personas o equipos. Debe definir cinco partes:
| Parte | Pregunta que responde | Ejemplo |
|---|---|---|
| Alcance | ¿Qué trabajo está incluido y qué queda fuera? | Crear un diseño para el menú de pausa; no rediseñar la pantalla de ajustes. |
| Entradas | ¿Qué información, recursos y decisiones recibe la persona? | Captura actual, resolución objetivo, textos y referencia visual. |
| Salidas | ¿Qué artefacto debe devolver? | Una especificación documentada del diseño y una referencia visual exportada. |
| Restricciones | ¿Qué condiciones debe respetar el resultado? | Navegación existente, texto legible, control y límites fijos de pantalla. |
| Aceptación | ¿Qué evidencia permite aceptar o rechazar el resultado? | El diseño supera las comprobaciones indicadas de navegación y legibilidad. |
Una solicitud puede ser detallada en un área y seguir siendo ambigua en conjunto. Por ejemplo, “haz que el menú de pausa se sienta más limpio” expresa una intención, pero no define un entregable acotado. La persona receptora tendría que adivinar qué producir o cómo se evaluará el resultado.
1865. Modelo mental
Usa el modelo SCOPE antes de asignar trabajo externo. El acrónimo se corresponde explícitamente con las cinco partes canónicas:
S — Scope / Alcance: trabajo incluido y exclusiones explícitas
C — Context / Contexto: entradas, referencias y supuestos actuales
O — Output / Salida: artefacto o decisión que debe devolverse
P — Parameters / Parámetros: restricciones que el resultado debe respetar
E — Evidence / Evidencia: evidencia de aceptación: comprobaciones y pruebas
observables para evaluar el resultado
En este mapeo, Contexto significa Entradas, Parámetros significa Restricciones y Evidencia significa evidencia de aceptación. Se conserva el acrónimo SCOPE, pero las cinco partes de la interfaz siguen siendo Alcance, Entradas, Salidas, Restricciones y Aceptación.
La evidencia y la aceptación están relacionadas, pero no son lo mismo. La evidencia es la prueba observable producida por las comprobaciones, como una captura, un resultado de prueba o una lista de verificación completada. La aceptación es la decisión de quien solicita el trabajo de aceptar o rechazarlo usando esa evidencia. La evidencia respalda la aceptación; no es la decisión de aceptación en sí misma.
La secuencia no exige una documentación interminable. Es una prueba de ambigüedad. Si la persona receptora tendría que adivinar una respuesta a cualquiera de las cinco preguntas, existe un vacío en la interfaz.
Distingue también entre:
- Resultado: qué debe ganar el juego o el equipo.
- Interfaz: qué recibe la persona externa y qué debe devolver.
- Implementación: cómo decide producir el resultado.
La interfaz debe hacer comprobable el resultado sin dictar innecesariamente la implementación.
1866. Ejemplo concreto
Considera esta solicitud:
“Mejora el menú de pausa para que se sienta más pulido y funcione bien con mando.”
La solicitud tiene una dirección, pero deja varias decisiones sin resolver:
- Alcance: ¿el trabajo se limita al menú de pausa o incluye las pantallas de ajustes y controles?
- Entradas: ¿qué diseño actual, textos, tamaños de pantalla y asignaciones del mando deben utilizarse?
- Salidas: ¿se espera una maqueta visual, una pantalla implementada, una especificación de navegación o todo lo anterior?
- Restricciones: ¿debe conservarse la estructura de navegación? ¿Están incluidos la localización, las zonas seguras y la accesibilidad?
- Aceptación: ¿qué acciones del mando deben funcionar y qué evidencia lo demuestra?
Una interfaz más sólida podría decir:
“Crea un diseño revisado para un único menú de pausa, usando las dimensiones actuales de pantalla. Utiliza la captura, los textos y el mapa de controles proporcionados. Conserva los destinos y el orden actuales del menú. Devuelve una composición visual y una tabla breve de navegación. El resultado se acepta cuando todos los destinos enumerados son accesibles con las acciones asignadas del mando, el foco permanece visible y todos los textos caben en sus áreas definidas. No modifiques las pantallas de ajustes ni de controles.”
Esta versión aún deja espacio para el criterio de implementación, pero ofrece a ambas partes un límite compartido y un final comprobable.
1867. Error común
El error común es tratar una palabra de calidad como si fuera una especificación. Términos como “pulido”, “responsivo”, “limpio” y “profesional” pueden comunicar intención, pero no definen alcance, entradas, salidas, restricciones ni aceptación. Pueden conservarse como dirección de diseño solo después de hacer explícitos los requisitos observables que las rodean.
Otro error consiste en especificar demasiado la implementación y dejar vaga la aceptación. Indicar qué archivos, herramientas o secuencia debe usar la persona externa no responde si el artefacto final satisface las necesidades del juego.
1868. Práctica guiada
Analiza la siguiente solicitud de outsourcing:
“Crea un nuevo indicador de advertencia de enemigos para el HUD de combate. Hazlo claro, que encaje con el estilo del juego y asegúrate de que no estorbe.”
Crea una tabla de cinco filas con estas columnas: Parte de la interfaz, Qué afirma la solicitud, Qué sigue siendo ambiguo y Una pregunta de aclaración. Usa una fila para cada elemento: alcance, entradas, salidas, restricciones y aceptación.
Después toma una decisión: elige la única ambigüedad que debe resolverse primero. Explica por qué resolverla reduce el mayor riesgo posterior. No reescribas todavía toda la solicitud; primero identifica el límite que controla las demás decisiones.
1869. Validación / evidencia
Tu evidencia consta de:
- Una tabla de cinco filas sobre las ambigüedades.
- Una ambigüedad seleccionada como la de mayor riesgo.
- Una justificación que conecte esa elección con el riesgo de alcance, implementación o aceptación.
Tu trabajo es suficiente cuando otra persona puede distinguir qué puede decidir la persona externa y qué debe decidir quien encarga el trabajo antes de comenzar. Una solicitud no está lista solo porque suena específica; está lista cuando su salida prevista y su evidencia de aceptación pueden comprobarse.
1870. Comprobación de conocimientos
Responde al cuestionario asociado a esta lección. Las preguntas comprueban si puedes distinguir un resultado de una interfaz, localizar límites faltantes y seleccionar evidencias de aceptación útiles.
1871. Ideas clave
- Una solicitud de outsourcing es una interfaz entre quien encarga el trabajo y quien lo realiza externamente.
- El alcance, las entradas, las salidas, las restricciones y la aceptación revelan tipos distintos de ambigüedad.
- Una palabra de calidad no sustituye a una evidencia de aceptación observable.
- Define el resultado y sus límites sin dictar innecesariamente la implementación.
- Resuelve primero la ambigüedad con mayor riesgo posterior.
1872. Próxima lección
Continúa con 4.13 L2 — Escribe un brief externo listo para IA.
1873. Contratos de handoff (fix-handoff-contracts)
Abre academy-fixtures/labs/handoff-contracts. Ejecuta node run.mjs. Registra entradas, salidas, owner, invariantes, fallo (escritura ilegal) y validación. Luego fix-save-roundtrip: academy-fixtures/labs/save-roundtrip → node run.mjs.
1874. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué elemento define las condiciones observables y la evidencia usadas para decidir si el trabajo externalizado es aceptable?
Mostrar respuesta y explicación
Respuesta: Criterios de aceptación
Por qué: Los criterios de aceptación definen las comprobaciones observables y la evidencia usadas para aceptar o rechazar el resultado.
¿Cuál es la principal ambigüedad de la solicitud “Haz que el HUD de combate se sienta más pulido”?
Mostrar respuesta y explicación
Respuesta: No define un resultado observable ni un criterio de aceptación.
Por qué: “Pulido” comunica una intención, pero no identifica el entregable ni cómo se evaluará el resultado.
¿Qué solicitud conserva mejor la libertad de implementación mientras define una interfaz utilizable?
Mostrar respuesta y explicación
Respuesta: Devuelve el artefacto definido, respeta las restricciones indicadas y demuestra las comprobaciones de aceptación mediante tu propio enfoque de implementación.
Por qué: Una buena interfaz define la salida, las restricciones y la evidencia de aceptación, pero deja margen para que la persona colaboradora elija cómo implementarla.
¿Por qué debe resolverse primero la ambigüedad de mayor riesgo antes de reescribir toda la solicitud de outsourcing?
Mostrar respuesta y explicación
Respuesta: Evita que los detalles posteriores se construyan sobre un límite que podría ser incorrecto.
Por qué: Un límite de alto riesgo que siga sin resolverse puede invalidar decisiones posteriores sobre alcance, entradas, salidas y aceptación; por eso debe aclararse primero.