1527. Identidad de la lección
1528. Objetivo de aprendizaje
Después de esta lección, podrás clasificar un contexto operativo posterior a la publicación como mantenimiento acotado o como modelo de operaciones en vivo, identificar las responsabilidades que intervienen y justificar la decisión con evidencia sobre recurrencia, responsables, seguimiento, coordinación de actividades dirigidas a los jugadores, gestión de incidentes o compromisos de servicio.
1529. Por qué importa
Un juego publicado genera trabajo adicional, pero no toda tarea posterior a la publicación necesita un modelo de operaciones en vivo. Tratar cada corrección, parche, cambio de contenido o incidente como si fuera el mismo tipo de operación oculta las responsabilidades y puede producir compromisos innecesarios. Un límite preciso ayuda al equipo a decidir qué debe programarse, vigilarse, comunicarse o prepararse para repetirse. También permite dar a la IA un encargo operativo delimitado, en lugar de pedirle de forma ambigua que “mantenga el juego funcionando”.
1530. Conocimientos previos
Debes poder usar el memorando de lanzamiento o no lanzamiento de 4.1 L3 — Escribe el memorando de lanzamiento o no lanzamiento. En particular, debes poder identificar una compilación concreta, su estado de lanzamiento, la evidencia que respalda una decisión y los umbrales que hacen aceptable un lanzamiento.
1531. Concepto central
Las operaciones en vivo son un modelo operativo, no un sinónimo de corregir errores después de la publicación.
Usa dos niveles de análisis distintos:
- Contexto operativo: clasifica la situación general como mantenimiento acotado posterior a la publicación o como modelo de operaciones en vivo.
- Responsabilidades: identifica qué tipos de trabajo aparecen dentro de ese contexto.
Un contexto de mantenimiento acotado posterior a la publicación resuelve una corrección o necesidad de compatibilidad finita, sin establecer coordinación operativa recurrente, una actividad continua dirigida a los jugadores ni un compromiso explícito de respuesta.
Un modelo de operaciones en vivo establece responsables, rutas de decisión, evidencia y compromisos repetibles para un juego que ya está disponible para los jugadores. Puede incluir cuatro áreas de responsabilidad relacionadas:
- Mantenimiento: conservar el funcionamiento del juego publicado mediante correcciones, trabajo de compatibilidad, seguimiento y tareas rutinarias.
- Operaciones de contenido: planificar, configurar, probar, activar y retirar contenido temporal o recurrente dirigido a los jugadores.
- Respuesta a incidentes: detectar, evaluar, contener, comunicar y resolver un problema inesperado que afecta a los jugadores.
- Compromisos de servicio: promesas explícitas sobre disponibilidad, horarios de soporte, expectativas de respuesta, comunicación o funcionamiento de un servicio continuo.
Estas cuatro áreas son responsabilidades, no clasificaciones alternativas del contexto general. El mantenimiento puede aparecer en cualquiera de los dos contextos. Por ejemplo, un parche de compatibilidad finito puede ser mantenimiento acotado, mientras que una corrección de configuración realizada durante un incidente de un evento activo es una responsabilidad de mantenimiento dentro de las operaciones en vivo.
El tamaño del cambio no determina su contexto. Un cambio pequeño de configuración puede formar parte de las operaciones en vivo si pertenece a una actividad programada para los jugadores y exige decisiones de activación, seguimiento, comunicación y reversión. Una corrección grande y puntual de compatibilidad puede seguir siendo mantenimiento acotado si no crea una relación operativa continua ni un compromiso de servicio.
1532. Modelo mental
Aplica el modelo en este orden.
Paso 1: clasifica el contexto operativo
| Contexto operativo | Prueba de límite | Evidencia habitual |
|---|---|---|
| Mantenimiento acotado posterior a la publicación | ¿Es una corrección finita, con un final definido y sin una relación operativa recurrente ni un compromiso explícito de servicio? | Alcance definido, comprobación de compatibilidad, resultado de regresión, condición de cierre |
| Modelo de operaciones en vivo | ¿Exige coordinación recurrente, una operación activa dirigida a los jugadores, seguimiento, una ruta de incidentes o un compromiso explícito de respuesta o comunicación? | Calendario, responsable recurrente, decisión de activación o reversión, registro de incidente, plan de comunicación, compromiso de soporte |
Paso 2: identifica las responsabilidades dentro del contexto
| Responsabilidad | Pregunta de diagnóstico | Evidencia habitual |
|---|---|---|
| Mantenimiento | ¿Qué conserva o restablece el funcionamiento previsto del producto publicado? | Alcance de la corrección, comprobación de compatibilidad, resultado de regresión |
| Operaciones de contenido | ¿Qué contenido dirigido a los jugadores se prepara, activa, gestiona o retira? | Especificación, calendario, condiciones de activación y retirada |
| Respuesta a incidentes | ¿Qué sucede cuando aparece un problema inesperado que afecta a los jugadores? | Señal de detección, gravedad, responsable, medida de contención, registro de recuperación |
| Compromisos de servicio | ¿Qué se ha comprometido explícitamente a proporcionar o comunicar el equipo? | Horario de soporte, objetivo de respuesta, declaración de disponibilidad, plan de comunicación |
El contexto operativo recibe una sola clasificación. Puede haber varias responsabilidades.
1533. Ejemplos concretos
Ejemplo A: mantenimiento acotado posterior a la publicación
Una actualización de plataforma rompe la entrada del mando. El equipo reproduce el problema, prepara un parche de compatibilidad, ejecuta pruebas de regresión, publica la corrección y cierra el trabajo. No hay un calendario recurrente, una operación activa de contenido dirigido a los jugadores ni un compromiso explícito de respuesta continua.
- Contexto operativo: mantenimiento acotado posterior a la publicación
- Responsabilidades: mantenimiento
- Evidencia: corrección finita, resultados de regresión y un punto de cierre definido
Ejemplo B: operaciones en vivo con varias responsabilidades
Un desafío de fin de semana cambia los objetivos y las recompensas disponibles. El equipo valida la configuración, la activa a una hora definida, hace seguimiento de los informes de los jugadores, decide si debe pausarla o revertirla, comunica los cambios importantes y la retira al terminar.
- Contexto operativo: operaciones en vivo
- Responsabilidades: operaciones de contenido y los compromisos de servicio que correspondan
- Evidencia: activación programada, seguimiento activo, decisiones operativas y retirada planificada
Durante el desafío, una configuración incorrecta entrega el objeto equivocado. El equipo desactiva el desafío, evalúa el impacto, comunica el estado, corrige la configuración, valida la recuperación y restaura la actividad.
- Contexto operativo: operaciones en vivo
- Responsabilidades: mantenimiento, operaciones de contenido y respuesta a incidentes; también hay compromisos de servicio si existe una promesa explícita de comunicación o respuesta
- Evidencia: operación activa dirigida a los jugadores, contención, evaluación del impacto, corrección, comunicación y recuperación
La corrección pertenece al mantenimiento, pero no se clasifica como mantenimiento ordinario porque ocurre dentro de un contexto activo de operaciones en vivo.
1534. Errores comunes
Error 1: mezclar los niveles de clasificación
Describir un incidente como “mantenimiento ordinario y operaciones en vivo a la vez” mezcla una etiqueta de contexto general con una responsabilidad interna. En su lugar, clasifica el contexto una sola vez y después enumera todas las responsabilidades presentes.
Error 2: clasificar según el esfuerzo de implementación
“Si es pequeño, es mantenimiento; si es grande, son operaciones en vivo” no es una regla fiable. Usa como evidencia la recurrencia, los responsables, el seguimiento, la coordinación de actividades dirigidas a los jugadores, la gestión de incidentes y los compromisos explícitos.
Error 3: suponer que las operaciones en vivo exigen contenido nuevo constante
Un modelo de operaciones en vivo no obliga a publicar contenido con frecuencia. Lo define la existencia de responsabilidades operativas repetibles. En la siguiente lección elegirás el modelo responsable más pequeño, en lugar de asumir que todos los juegos necesitan los mismos compromisos.
1535. Práctica guiada
Para cada escenario, completa los dos niveles de análisis:
- Clasifica el contexto operativo general como mantenimiento acotado posterior a la publicación u operaciones en vivo.
- Identifica todas las responsabilidades pertinentes: mantenimiento, operaciones de contenido, respuesta a incidentes y compromisos de servicio.
- Da una razón basada en evidencia para justificar la clasificación del contexto.
| Escenario | Contexto esperado | Responsabilidades que debes examinar |
|---|---|---|
| Una actualización de plataforma rompe la entrada del mando. El equipo prepara y valida un único parche de compatibilidad y después cierra el trabajo. | Mantenimiento acotado posterior a la publicación | Mantenimiento |
| Una misión mensual se configura, prueba, activa, supervisa y retira según un calendario publicado. | Operaciones en vivo | Operaciones de contenido; compromisos de servicio si el calendario constituye una promesa explícita |
| Una misión programada entrega el objeto equivocado. El equipo la desactiva, evalúa a los jugadores afectados, comunica el estado, corrige la configuración y restaura la misión. | Operaciones en vivo | Mantenimiento, operaciones de contenido, respuesta a incidentes y los compromisos de servicio que correspondan |
| El equipo revisa cada semana los informes de cierres inesperados y mantiene una ruta documentada de escalado para fallos graves que afectan a los jugadores. | Operaciones en vivo | Mantenimiento y respuesta a incidentes; compromisos de servicio solo si existe una promesa explícita |
No deduzcas que existe un compromiso de servicio solo porque se realiza trabajo. Identifícalo únicamente cuando el escenario indique una promesa explícita, una expectativa de respuesta, un horario de soporte o una obligación de comunicación.
1536. Validación y evidencia
Completa la evaluación práctica adjunta. Tu respuesta debe incluir:
- una clasificación del contexto operativo;
- todas las responsabilidades pertinentes;
- una o dos frases que citen evidencia concreta del escenario.
Una respuesta sólida mantiene separados los dos niveles, no clasifica una corrección interna como mantenimiento ordinario cuando la situación general pertenece a las operaciones en vivo y no inventa compromisos que el escenario no menciona.
1537. Puntos clave
- Primero clasifica el contexto general; después identifica sus responsabilidades.
- Los dos contextos son el mantenimiento acotado posterior a la publicación y el modelo de operaciones en vivo.
- El mantenimiento, las operaciones de contenido, la respuesta a incidentes y los compromisos de servicio son áreas de responsabilidad que pueden aparecer dentro de las operaciones en vivo.
- Puede haber trabajo de mantenimiento dentro de las operaciones en vivo sin que la situación general deba clasificarse como “ambas”.
- La recurrencia, los responsables, el seguimiento, la coordinación con los jugadores, la gestión de incidentes y los compromisos explícitos ofrecen mejor evidencia que el tamaño de la implementación.
1538. Próxima lección
Continúa con 4.2 L2 — Elige el modelo operativo responsable más pequeño.
1539. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué afirmación define mejor las operaciones en vivo?
Mostrar respuesta y explicación
Respuesta: Un modelo operativo repetible para mantener un juego publicado, gestionar sus operaciones y responder a problemas que afecten a los jugadores.
Por qué: Las operaciones en vivo establecen responsabilidades, rutas de decisión, evidencia y compromisos repetibles en torno a un juego publicado. No abarcan automáticamente toda corrección posterior a la publicación ni exigen una frecuencia fija de contenido.
¿Qué situación constituye claramente un contexto de mantenimiento acotado posterior a la publicación?
Mostrar respuesta y explicación
Respuesta: Preparar y cerrar un parche puntual de compatibilidad sin calendario continuo ni compromiso de servicio.
Por qué: Una corrección de compatibilidad finita, con un punto de cierre definido y sin relación operativa continua, es mantenimiento acotado. Las demás situaciones implican responsabilidades operativas recurrentes o activas.
¿Por qué un cambio pequeño de configuración puede pertenecer a un contexto de operaciones en vivo?
Mostrar respuesta y explicación
Respuesta: Porque puede exigir activación programada, seguimiento, comunicación y decisiones de reversión mientras los jugadores interactúan con el cambio.
Por qué: El contexto operativo, y no el tamaño de la implementación, determina la clasificación. Un cambio pequeño puede exigir coordinación recurrente o una operación activa dirigida a los jugadores.
¿Cómo debería analizar el equipo una misión programada que entrega el objeto equivocado, se desactiva y exige comunicarse con los jugadores afectados?
Mostrar respuesta y explicación
Respuesta: Clasificar el contexto como operaciones en vivo e identificar responsabilidades de mantenimiento, operaciones de contenido y respuesta a incidentes.
Por qué: La misión programada activa, la contención, la evaluación del impacto, la comunicación, la corrección y la recuperación sitúan la situación general en un contexto de operaciones en vivo. Corregir la configuración es una responsabilidad de mantenimiento dentro de ese contexto; desactivar y recuperar la misión también implica operaciones de contenido y respuesta a incidentes.