Definir controles técnicos para un equipo pequeño

2383. Identidad de la lección

Módulo

5.14 — Dirección técnica

Lección

Definir controles técnicos para un equipo pequeño

Tipo académico

Flujo de trabajo

Tipo de lección

Mixta

Orden

2

Tiempo estimado

40–50 minutos para redactar el paquete durante la sesión a partir de un cambio acotado y una plantilla; la ejecución y evaluación en el proyecto pueden requerir tiempo adicional

Esta lección convierte una decisión técnica en un acuerdo operativo para un equipo pequeño: qué debe cumplirse, cómo se comprobará, cuándo debe escalarse un problema y cómo podrá revisarse o recuperarse el cambio.

2384. Objetivo de aprendizaje

Al terminar esta lección, podrás crear un paquete de dirección técnica que defina el criterio de terminado de una transición mediante controles priorizados, evidencias observables, umbrales de escalado, exclusiones explícitas, un punto de control revisable y una ruta de recuperación documentada.

2385. Por qué importa

Una expectativa como «la funcionalidad debe sentirse estable» todavía no sirve para producción. Un criterio de terminado hace que una transición o un hito pueda inspeccionarse al indicar qué condiciones deben cumplirse antes de avanzar. Los controles priorizados permiten aplicar ese criterio bajo presión: distinguen lo que bloquea la transición de lo que debe resolverse después. Un punto de control revisable y una ruta de recuperación hacen que la decisión siga siendo trazable después de evaluar el cambio. Esto es especialmente importante cuando la IA puede producir código más deprisa de lo que un equipo pequeño puede revisarlo.

2386. Conocimientos previos

Debes poder comparar opciones técnicas bajo restricciones, identificar compensaciones y registrar una decisión junto con sus supuestos, como se trabajó en 5.14 L1 — Tomar una decisión técnica bajo restricciones. También debes conocer el alcance actual del proyecto, sus sistemas de mayor riesgo, la diferencia entre un requisito y una preferencia de implementación, y el método habitual del proyecto para registrar cambios.

2387. Concepto central

Un control técnico es una condición que debe cumplirse antes de permitir una transición concreta. El paquete también debe indicar las herramientas utilizadas para producir e inspeccionar la evidencia, como el gestor de incidencias, el ejecutor de pruebas, las herramientas de ejecución o perfilado, la interfaz de revisión y el sistema de control de versiones. Un control no está completo desde el punto de vista operativo si el equipo no puede repetir la comprobación con las herramientas disponibles. La transición puede ser integrar un cambio, entregar una funcionalidad para pruebas de juego, avanzar un hito o preparar una compilación para revisión.

Un conjunto de controles priorizados se convierte en el criterio de terminado de esa transición. No afirma que todo el proyecto esté terminado. Responde de forma acotada a esta pregunta: «¿Qué debe cumplirse y qué evidencia debe existir antes de cruzar este límite?». Una transición está terminada cuando todos los controles bloqueantes han pasado, cada control obligatorio se ha superado o el responsable de la decisión ha aceptado explícitamente el riesgo, y los elementos no bloqueantes siguen visibles con responsable y punto de revisión.

En un cambio técnico, «terminado» también exige trazabilidad. El paquete debe identificar un punto de control revisable —como un commit, una solicitud de revisión, una revisión etiquetada o una instantánea equivalente— para que el estado evaluado no sea ambiguo. También debe registrar la evaluación realizada sobre ese estado y explicar cómo restaurar el último estado conocido como correcto o revertir el cambio si falla un control.

Una Ficha de control completa tiene seis campos obligatorios. El paquete también debe declarar sus exclusiones; añade una exclusión a un control concreto solo cuando ayude a delimitarlo.

1. Transición: ¿Qué se autoriza si el conjunto de controles se supera?
2. Prioridad: ¿Cómo afecta el fallo a esta transición? Usa P0, P1 o P2.
3. Condición: ¿Qué debe ser cierto?
4. Evidencia: ¿Qué artefacto u observación lo demuestra?
5. Responsable: ¿Quién realiza o confirma la comprobación?
6. Acción ante fallo: ¿Qué ocurre si la condición no se cumple?
7. Exclusión del control, cuando sea necesaria: ¿Qué asunto relacionado queda deliberadamente fuera de este control?

El paquete añade tres campos de trazabilidad para el cambio bajo revisión:

8. Punto de control: ¿Qué commit, revisión, etiqueta o instantánea equivalente se está evaluando?
9. Evaluación: ¿Qué prueba, inspección o comparación significativa se ejecutó sobre ese punto y qué resultado produjo?
10. Ruta de recuperación: ¿Qué punto conocido como correcto puede restaurarse, quién puede revertir el cambio y qué condición activa esa recuperación?

«Usar código limpio» no es un control porque no define un umbral observable. «La funcionalidad supera los casos de aceptación indicados, no produce nuevos errores en la consola durante la escena de prueba y tiene una revisión asignada antes de la entrega del hito» se acerca más, pero solo está completa cuando el paquete también indica su prioridad, responsable, acción ante fallo, transición, alcance excluido, punto evaluado, evaluación significativa y ruta de recuperación.

La priorización es esencial. Un equipo pequeño no puede inspeccionar todas las propiedades en cada transición. Empieza por los controles que protegen el contrato con el jugador, evitan retrabajo costoso o revelan un riesgo que después no se podrá absorber de forma segura. La trazabilidad importa por la misma razón: un resultado sin un estado identificado no puede reproducirse, compararse ni revertirse con fiabilidad.

2388. Modelo mental

Usa el modelo Ficha de control → Criterio de terminado → Punto de control:

Reúne las fichas en un criterio de terminado para la transición:

• P0 — bloqueante: Todas las fichas P0 deben superarse. De lo contrario, la transición no puede continuar.
• P1 — obligatorio: Todas las fichas P1 deben superarse antes del siguiente hito, o la persona responsable debe aceptar explícitamente el riesgo.
• P2 — mejora registrada: El asunto no bloquea la transición actual, pero necesita responsable y punto de revisión.
• Trazabilidad — estado revisable: El paquete identifica el punto exacto evaluado, el resultado de una evaluación significativa y la acción de recuperación ante un cambio fallido.

Estas son las definiciones operativas de P0, P1 y P2 utilizadas en esta lección. El equipo puede asignarlas a sus propias etiquetas de prioridad, siempre que conserve las mismas consecuencias de bloqueo, aceptación del riesgo, asignación de responsables y revisión.

El criterio de terminado debe escribirse en una frase. Por ejemplo: «Esta funcionalidad está lista para pruebas internas cuando todos los controles P0 han pasado, los elementos P1 se han resuelto o cuentan con aceptación explícita del riesgo, cada elemento P2 tiene responsable y fecha de revisión, y el punto evaluado y la ruta de recuperación están registrados». Esa frase es la definición operativa de terminado. Si todo es P0, no existe una priorización útil. Si ningún elemento tiene una consecuencia definida, el documento solo contiene recomendaciones. Si falta el punto de control o la evaluación, el equipo no puede saber qué estado superó el control.

2389. Ejemplo concreto

Imagina que un equipo pequeño prepara una interacción nueva para una prueba interna. Su criterio de terminado podría contener estas Fichas de control:

El paquete también registra:

• Punto de control: el commit revisable o la instantánea equivalente que contiene el cambio de la interacción.
• Evaluación: los tres casos de aceptación, la comprobación de regresión en la escena de destino y sus resultados.
• Ruta de recuperación: restaurar el último punto conocido como correcto si G-01 o G-02 falla después del cambio; registrar el motivo, el estado restaurado y el responsable del seguimiento.

Por tanto, el criterio de terminado es: G-01 y G-02 deben superarse para entregar la funcionalidad a pruebas; G-03 debe resolverse o aceptarse antes del siguiente hito; G-04 debe conservar responsable y fecha; y el punto evaluado, el resultado de la evaluación y la ruta de recuperación deben estar registrados. El paquete también debe declarar exclusiones: no habrá una refactorización amplia de sistemas vecinos, no se hará una pasada adicional de contenido, no se dará soporte a una plataforma aún no comprometida y no se afirmará que el rendimiento final ya está listo.

2390. Flujo de trabajo nativo de IA

La IA puede ayudar a redactar, clasificar y cuestionar una lista de controles. No puede decidir si una evidencia es fiable, si un fallo es aceptable para el proyecto o qué punto de control debe considerarse autorizado. Mantén visible la decisión humana.

1. Define el contexto. Proporciona a la IA la transición, el requisito de cara al jugador, las restricciones, la decisión técnica anterior y el punto y método de evaluación previstos. No le pidas que invente hechos del proyecto que no aparecen en la información proporcionada.
2. Solicita candidatos. Pide controles en el formato completo de Ficha de control, incluyendo transición, prioridad, condición, evidencia, responsable, acción ante fallo y exclusión. Pide también que identifique la evidencia necesaria para comprobar el punto de control, la evaluación y la recuperación. Exige que los supuestos aparezcan separados.
3. Cuestiona la lista. Pregunta qué controles son vagos, duplicados, imposibles de inspeccionar o están mal priorizados. Pregunta qué evidencia refutaría cada control y qué resultado debería activar la recuperación.
4. Contrasta con el proyecto. Elimina supuestos inventados. Sustituye comprobaciones genéricas por evidencias que el equipo realmente pueda producir. Define prioridades según la consecuencia y el momento, no según la redacción de la IA. Confirma que la ruta de recuperación sea viable antes de registrarla.
5. Registra el paquete. Conserva los controles finales, el criterio de terminado en una frase, las exclusiones, los responsables, las reglas de escalado, el punto de control, el resultado de la evaluación y la ruta de recuperación en un documento revisado por una persona. El paquete final es una decisión del equipo, no una autoridad generada por IA.

Puedes usar este prompt:

Actúa como revisor técnico escéptico. Dadas esta transición, requisito, restricciones, riesgos conocidos, punto de control propuesto, método de evaluación y opción de recuperación, propone como máximo seis Fichas de control completas. Para cada una, indica prioridad, condición observable, evidencia, responsable, acción ante fallo y exclusión. Identifica qué debe registrarse para que el punto de control sea revisable, la evaluación sea significativa y la ruta de recuperación pueda ejecutarse. Marca todos los supuestos. Después identifica controles vagos, cobertura duplicada y exclusiones que falten. No inventes historial del proyecto ni afirmes que un control ha sido superado.

Después de recibir la respuesta, inspecciona cada candidato. Pregunta: «¿Podría otro revisor repetir esta comprobación a partir del punto de control indicado y contribuye esta ficha al criterio de terminado de la transición?». Si la respuesta es no, reescribe el control antes de aceptarlo.

2391. Git workflow

Usa el proceso habitual de control de versiones del proyecto para que el cambio sea revisable y recuperable. No trates un directorio de trabajo sin trazabilidad como evidencia suficiente.

1. Identifica el último commit, revisión etiquetada o punto de control equivalente conocido como correcto antes del cambio.
2. Mantén el cambio técnico lo bastante aislado para que un revisor pueda identificar qué se evaluó. Crea un commit revisable, una solicitud de revisión, una revisión etiquetada o un punto de control equivalente según el proceso del proyecto.
3. Registra el identificador del punto de control en el paquete de dirección técnica antes de evaluar. El programa exige usar Git; si realmente no está disponible, documenta la justificación de la excepción, el identificador y la ubicación exacta de la instantánea equivalente, la limitación de ese método y la persona responsable de verificarla.
4. Ejecuta una evaluación significativa sobre ese punto exacto. La evaluación debe recorrer el requisito o exponer la regresión técnica de mayor riesgo; la existencia de un commit no demuestra que la funcionalidad opere.
5. Registra el método de evaluación, el entorno o recorrido de prueba cuando corresponda, una fecha o etiqueta de sesión si el proyecto la utiliza y el resultado aprobado/fallido. No marques una prueba como superada sin haberla ejecutado.
6. Documenta la recuperación antes de aceptar el cambio: indica el punto conocido como correcto, el desencadenante de la reversión, la persona o rol responsable y la verificación necesaria después de recuperar.
7. Si falla un control bloqueante, detén la transición y usa la ruta documentada cuando corresponda. Registra si el cambio se revirtió, se corrigió en un nuevo punto de control o quedó detenido para una decisión explícita sobre el riesgo.

Un registro mínimo de trazabilidad es: punto evaluado → evaluación significativa y resultado → decisión → desencadenante de recuperación y punto conocido como correcto. El registro debe permitir que otra persona determine qué estado se probó y qué debe hacer si el cambio causa una regresión.

2392. Error común

El error principal es tratar una lista de intenciones de calidad como un criterio de terminado. «Valoramos la mantenibilidad», «la funcionalidad debe estar pulida» y «hay que revisar el resultado de la IA» son intenciones o estándares. Solo se vuelven operativos cuando el paquete define la transición, la prioridad, la condición, la evidencia, el responsable, la acción ante fallo y la exclusión.

Otro error es tratar un commit o punto de control como prueba de calidad. Un estado revisable establece qué puede inspeccionarse; no demuestra que el requisito funcione. Debe ejecutarse una evaluación significativa sobre ese estado y documentarse una ruta de recuperación antes de aceptar el cambio.

También es un error hacer que todos los controles sean bloqueantes. Eso elimina la diferencia entre un fallo crítico para la entrega y una mejora registrada. Es igualmente incorrecto describir la reversión como «ya lo arreglaremos». Si el equipo no pretende admitir una plataforma, una variante de contenido o un objetivo de rendimiento en la transición actual, debe declararlo como exclusión. Si un cambio puede causar una regresión, hay que indicar qué estado conocido como correcto puede restaurarse y qué evento activa esa acción.

2393. Práctica guiada

Crea un paquete de dirección técnica para una funcionalidad o sistema acotado del proyecto actual. Si no tienes disponible un contexto de proyecto, usa una interacción pequeña como «el jugador activa un objeto, recibe un cambio de estado y puede continuar por el recorrido previsto».

Distribuye el esfuerzo de revisión con este método: identifica los controles cuyas consecuencias de fallo sean mayores; dedica más revisión a los riesgos difíciles de detectar o revertir; asigna cada actividad a una persona o rol; y justifica el tiempo o porcentaje según el riesgo y la reversibilidad. Incluye la redacción de controles, la verificación de evidencias, la revisión de riesgos y la revisión de la recuperación. Por ejemplo: 20 % para redactar controles — implementador; 40 % para verificar evidencias — revisor, porque los dos controles P0 protegen la entrega a pruebas; 25 % para revisar riesgos — responsable técnico, porque una pérdida de estado sería difícil de detectar más adelante; 15 % para revisar la recuperación — implementador y revisor, porque el punto de control aislado facilita la reversión. Los porcentajes deben sumar el 100 %, o los tiempos deben sumar el presupuesto declarado.

Completa estos pasos:

1. Nombra la transición que controlará el paquete: revisión de código, prueba interna, entrega de hito u otro límite concreto.
2. Expresa el requisito dirigido al jugador en una sola frase.
3. Enumera los tres riesgos de mayor consecuencia. Separa, cuando sea posible, el fallo para el jugador, el fallo técnico y el fallo de alcance.
4. Identifica el último estado conocido como correcto y crea o designa un punto de control revisable para el cambio técnico: un commit, una solicitud de revisión, una revisión etiquetada o una instantánea equivalente.
5. Redacta entre cuatro y seis Fichas de control completas. Incluye al menos un control P0, uno P1 y uno P2, salvo que el contexto aporte una razón documentada para no hacerlo.
6. Para cada control, escribe una evidencia que otra persona pueda inspeccionar sin depender de tu memoria.
7. Define una evaluación significativa para el punto de control. Debe ejercitar el requisito dirigido al jugador o el comportamiento técnico de mayor riesgo. Registra el método y el resultado; no lo marques como superado hasta haberlo ejecutado.
8. Escribe el criterio de terminado en una sola frase. Indica qué debe pasar, qué requiere aceptación explícita del riesgo y cómo seguirán visibles los elementos P2.
9. Define una regla de escalado. Por ejemplo: un fallo P0 bloquea la transición de inmediato; un fallo P1 requiere que la persona responsable de la decisión acepte el riesgo antes de la revisión del hito; un problema P2 necesita responsable y punto de revisión.
10. Documenta la ruta de recuperación. Indica el punto conocido como correcto, la condición que activa la reversión, quién la ejecuta y cómo se verificará la recuperación.
11. Escribe al menos tres exclusiones. Deben ser específicas para evitar una ampliación de alcance probable.
12. Pide a una herramienta de IA que cuestione el paquete con el prompt anterior. Compara sus sugerencias con el contexto real del proyecto, conserva solo los cambios justificados y marca cualquier supuesto sin resolver.
13. Distribuye el esfuerzo de revisión entre las actividades, indica el tiempo o porcentaje y su responsable, y justifica la distribución según las consecuencias de fallo y la dificultad de detectar o revertir cada riesgo.

Las decisiones obligatorias son tu orden de prioridades y el desencadenante de recuperación. Si dos controles compiten por un tiempo limitado, elige cuál se revisa primero y explica qué consecuencia protege ese orden. Después decide qué evidencia justificaría conservar el cambio, corregirlo en un nuevo punto de control o restaurar el estado conocido como correcto.

2394. Validación / evidencia

2395. Evaluación práctica

Puntúa el paquete terminado de 0 a 18 puntos. En cada criterio, asigna 0 = ausente o inutilizable, 1 = presente pero incompleto, o 2 = completo y listo para tomar decisiones:

1. Adecuación a la transición: Los controles regulan el límite y el requisito acotado que se han indicado.
2. Justificación de prioridades: Las prioridades P0, P1 y P2 se justifican por sus consecuencias y el momento en que deben resolverse.
3. Evidencia reproducible: Otro revisor puede repetir cada comprobación a partir de la evidencia indicada.
4. Autoridad de escalado: Los umbrales de fallo indican quién bloquea, acepta el riesgo o programa el seguimiento.
5. Trazabilidad del punto de control: El estado exacto evaluado está vinculado con el método y el resultado de la evaluación.
6. Viabilidad de la recuperación: El desencadenante, el estado conocido como correcto, el rol responsable y la verificación permiten ejecutar la reversión.
7. Exclusiones: Las exclusiones del paquete evitan ampliaciones previsibles del alcance; se añaden exclusiones a controles concretos cuando aclaran sus límites.
8. Distribución del esfuerzo de revisión: Los tiempos o porcentajes suman el presupuesto declarado, tienen responsables y se justifican según el riesgo y la reversibilidad.
9. Tratamiento de las sugerencias de IA: Las sugerencias aceptadas, rechazadas y pendientes quedan registradas con motivos basados en el proyecto.

El paquete se considera completo con 14 puntos o más y sin ningún cero en evidencia reproducible, trazabilidad del punto de control o viabilidad de la recuperación. Si no alcanza ese umbral, revísalo y vuelve a evaluarlo. La puntuación valora la calidad y trazabilidad de las decisiones, no una herramienta o terminología concreta.

2396. Ideas clave

• Un conjunto de controles técnicos priorizados es el criterio de terminado de una transición o un hito concreto, no una afirmación de que todo el proyecto esté terminado.
• Una Ficha de control completa indica transición, prioridad, condición, evidencia, responsable y acción ante fallo. Las exclusiones son obligatorias para el paquete y pueden añadirse a controles concretos cuando aclaren sus límites.
• Un punto de control revisable identifica el estado exacto evaluado; no sustituye una evaluación significativa.
• Una ruta de recuperación indica el estado conocido como correcto, el desencadenante, el rol responsable y la verificación necesaria después de revertir o recuperar.
• Los controles P0 bloquean; los P1 requieren resolución o aceptación explícita del riesgo antes del siguiente hito; los P2 permanecen asignados y programados sin bloquear la transición actual.
• La IA sirve para redactar y cuestionar controles, pero las personas deben verificar la evidencia, evaluar el cambio y aceptar el riesgo del proyecto.

2397. Siguiente lección

Siguiente: 5.15 — Dirección creativa, donde la dirección técnica se entrega al trabajo de dirección creativa con su alcance, restricciones, decisiones pendientes y estado del punto de control técnico claramente identificados.

2398. Comprobación