1540. Identidad de la lección
1541. Objetivo de aprendizaje
Después de esta lección, podrás comparar tres opciones de modelo operativo y justificar un modelo proporcional que se ajuste a las necesidades del producto, las promesas de soporte, las rutas de decisión y la capacidad del equipo.
1542. Por qué importa
Un modelo operativo se vuelve arriesgado cuando el equipo promete más soporte del que puede prestar de forma fiable. Un producto pequeño puede necesitar una persona responsable, una única vía de soporte supervisada y algunas reglas de respuesta. Quizá no necesite cobertura continua, contenido recurrente ni una gran infraestructura de servicios.
El modelo operativo mínimo responsable no es el que exige menos trabajo en términos absolutos. Es el conjunto mínimo de compromisos y mecanismos que protege las experiencias importantes del jugador y sigue siendo viable para el equipo.
1543. Conocimientos previos
Debes poder distinguir el mantenimiento posterior al lanzamiento, de alcance acotado, de las operaciones en vivo, e identificar responsabilidades, rutas de decisión, evidencia y compromisos. También debes poder describir la superficie de lanzamiento: plataformas compatibles, rutas críticas del jugador, riesgos operativos y funciones disponibles.
1544. Concepto central
Construye el modelo a partir de las necesidades del producto, no de rutinas habituales de la industria. Para cada responsabilidad conservada o reducida, especifica:
- Necesidad: ¿Qué experiencia del jugador debe protegerse?
- Promesa: ¿Qué soporte o respuesta ofrecerá el equipo?
- Disparador de respuesta: ¿Qué condición observable inicia la respuesta?
- Acción o decisión: ¿Cuál es la intervención útil mínima y quién la autoriza?
- Responsable y suplencia: ¿Quién actúa primero y quién decide si esa persona no está disponible?
- Evidencia de cierre: ¿Qué condición observable demuestra que la respuesta está contenida, resuelta o aplazada de forma deliberada?
- Límite de capacidad: ¿Cuándo debe el equipo reducir, aplazar o detener la respuesta?
No combines el disparador con la evidencia de cierre. Un informe con pasos reproducibles puede iniciar la revisión; una solución temporal verificada, una compilación corregida, un aplazamiento documentado o la imposibilidad de reproducir el problema tras unas comprobaciones definidas pueden cerrar la respuesta. La evidencia concreta debe corresponder a la responsabilidad diseñada.
Una frase como “lo supervisaremos todo y responderemos rápido” no constituye un modelo operativo. Una formulación acotada identifica la vía oficial, el calendario, el disparador, la decisión autorizada, la persona responsable, la suplencia, la condición de cierre y las exclusiones.
1545. Tabla de ajuste entre promesa y capacidad
| Necesidad del producto | Promesa para el jugador | Disparador de respuesta | Acción o decisión y quién la autoriza | Responsable y suplencia | Evidencia de cierre | Límite de capacidad |
|---|---|---|---|---|---|---|
| ¿Qué debe protegerse? | ¿Qué recibirá razonablemente el jugador? | ¿Qué inicia la respuesta? | ¿Cuál es la intervención mínima y quién puede aprobarla? | ¿Quién actúa primero y quién toma la decisión si hace falta? | ¿Qué demuestra la contención, la resolución o el aplazamiento explícito? | ¿Qué queda fuera de cobertura o supera la capacidad? |
Aplica la prueba de conservar, reducir o eliminar:
- Conserva una responsabilidad si protege una ruta crítica del jugador o responde a un fallo previsible de gran impacto.
- Redúcela si la necesidad es válida, pero la cobertura, la cadencia, el tiempo de respuesta o la superficie propuesta supera la capacidad.
- Elimínala si genera actividad sin proteger una necesidad definida del producto.
1546. Matriz comparativa consolidada
Usa esta matriz una sola vez para comparar la forma del producto, la opción operativa, la protección y la carga. No repitas después otra comparación separada de las formas del producto.
| Forma del producto | Opción operativa candidata | Protección que se conserva | Promesa o carga de capacidad que se evita deliberadamente |
|---|---|---|---|
| Lanzamiento único | Autoservicio y avisos de lanzamiento | Documentación, información sobre problemas conocidos y comunicaciones esenciales del lanzamiento | No se promete una respuesta individual habitual ni una cadencia continua de contenido |
| Lanzamiento de un parche de mantenimiento | Soporte programado y acotado | Una vía definida para informar de defectos o incompatibilidades y tomar decisiones delimitadas sobre parches | No se promete supervisión continua ni actualizaciones recurrentes automáticas |
| Producto de servicio en vivo | Soporte continuo, solo cuando sea necesario y sostenible | Servicios, cadencia o dependencias operativas continuas que el producto realmente necesita | No se prometen canales, tiempos de respuesta ni contenido que excedan la capacidad disponible |
Son puntos de partida, no asignaciones automáticas. Si un lanzamiento único puede sufrir un fallo crítico que exige una vía de respuesta, el autoservicio quizá no sea suficiente. Si el producto no depende de una operación continua, el soporte permanente puede añadir obligaciones sin proteger una necesidad real.
1547. Ejemplo resuelto
Considera un lanzamiento ficticio para un jugador, con partidas guardadas locales, una compilación distribuida mediante una tienda, un único buzón oficial de soporte y un equipo pequeño que puede revisar informes en días laborables programados.
El equipo recomienda soporte programado y acotado. Descarta el soporte continuo porque el producto no presenta ninguna dependencia declarada de una operación permanente y el equipo no puede mantener esa cobertura. El soporte continuo solo sería apropiado si el producto llegara a depender de un servicio que exigiera esa atención.
Clasifica tres necesidades:
- Informes de fallos que impiden iniciar el juego: conservar.
- Comentarios generales repartidos por todas las redes sociales: reducir a un único buzón oficial.
- Eventos de contenido semanales: eliminar, porque ninguna necesidad indicada del producto los exige.
Una fila completada:
| Necesidad del producto | Promesa para el jugador | Disparador de respuesta | Acción o decisión y quién la autoriza | Responsable y suplencia | Evidencia de cierre | Límite de capacidad |
|---|---|---|---|---|---|---|
| Informes que indican que el juego no se inicia | El buzón oficial se revisa en días laborables programados y se priorizan los bloqueos de inicio. | Un informe identifica la compilación e incluye evidencia reproducible del fallo de inicio. | La persona responsable de soporte registra y reproduce el problema; la persona responsable del lanzamiento autoriza una solución temporal, una corrección o un aplazamiento. | Responsable de soporte; la persona responsable del lanzamiento asume la decisión si hace falta. | Se verifica una solución temporal, una compilación corregida supera la comprobación pertinente o se registra un aplazamiento justificado junto con la acción de comunicación. | No hay supervisión continua ni se promete un cambio de código inmediato. |
El disparador inicia la respuesta y la evidencia de cierre establece cómo termina. La acción también se distingue de la autorización: quien atiende primero puede investigar, pero una persona concreta debe autorizar un cambio en la versión o su aplazamiento.
1548. Práctica guiada
Crea un modelo operativo de una página con las restricciones del lanzamiento ficticio anterior o con restricciones equivalentes facilitadas por el docente.
- Utiliza la matriz consolidada para comparar las tres opciones: autoservicio y avisos, soporte programado y acotado, y soporte continuo de servicio en vivo.
- Recomienda la opción mínima responsable. Indica una alternativa rechazada y la condición que permitiría elegirla.
- Identifica exactamente tres necesidades operativas y marca cada una como conservar, reducir o eliminar.
- Usa como referencia la fila resuelta sobre el bloqueo de inicio. Redacta dos filas adicionales para necesidades conservadas o reducidas. Cada fila debe separar el disparador, la acción o decisión autorizada y la evidencia de cierre.
- Escribe una no-promesa explícita sobre un canal, una cadencia, una plataforma, un tiempo de respuesta o un tipo de solicitud.
- Comprueba la viabilidad. Si ninguna función disponible puede asumir o autorizar la respuesta, reduce, aplaza o elimina la promesa.
La recomendación debe incluir una decisión con consecuencias reales, como revisar en horarios programados en vez de ofrecer cobertura continua, mantener una única vía oficial de soporte en vez de varias o aplicar una solución temporal verificada en vez de cambiar el código de inmediato ante un problema no crítico.
1549. Validación y evidencia
Un artefacto completo contiene:
- Una única comparación consolidada de las tres opciones operativas y formas del producto.
- Un modelo recomendado a partir de las restricciones de producto y capacidad facilitadas.
- Una alternativa rechazada y la condición que la haría apropiada.
- Tres necesidades con decisiones de conservar, reducir o eliminar.
- La fila resuelta del ejemplo y dos filas redactadas por el estudiante.
- En cada fila conservada o reducida redactada por el estudiante: promesa, disparador, acción o decisión mínima, persona que la autoriza, responsable, suplencia, evidencia de cierre y límite de capacidad.
- Una no-promesa explícita.
- Una decisión con consecuencias reales.
Otro miembro del equipo debe poder determinar qué inicia cada respuesta, quién actúa, quién autoriza la decisión importante, cuál es la intervención mínima, qué condición observable cierra o aplaza la respuesta y qué decide no prometer el equipo.
La comprobación de conocimientos es formativa. Entrega el artefacto del modelo operativo para la evaluación práctica puntuada asociada con esta lección.
1550. Puntos clave
- Elige las responsabilidades a partir de las necesidades del producto, no de rutinas copiadas de servicios en vivo.
- Separa los disparadores de respuesta de la evidencia de cierre.
- Indica la acción o decisión útil mínima y quién la autoriza.
- Conserva las protecciones críticas, reduce los compromisos sobredimensionados y elimina las actividades sin propósito definido.
- Un modelo responsable permite inspeccionar los responsables, las suplencias, los límites y las no-promesas.
1551. Próxima lección
Continúa con 4.3 — Observabilidad. Los riesgos conservados, los disparadores, las acciones autorizadas y la evidencia de cierre de este modelo servirán como punto de partida para formular preguntas operativas observables en la siguiente lección.
1552. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué hace que un modelo operativo sea proporcional?
Mostrar respuesta y explicación
Respuesta: Protege necesidades importantes del producto con promesas, responsables, evidencia, acciones y límites de capacidad explícitos.
Por qué: La proporcionalidad depende del ajuste entre las necesidades del producto, las promesas, los responsables, la evidencia, las acciones autorizadas, los límites y la capacidad real.
Un equipo pequeño no puede supervisar todos los canales sociales. ¿Cuál es la respuesta más responsable?
Mostrar respuesta y explicación
Respuesta: Elegir un canal oficial, definir su calendario de revisión e indicar que los demás canales no son vías oficiales de soporte.
Por qué: Reducir la superficie oficial de soporte y definir un calendario de revisión convierte una promesa inmanejable en un compromiso acotado.
¿Qué afirmación distingue correctamente un disparador de respuesta de la evidencia de cierre?
Mostrar respuesta y explicación
Respuesta: El disparador inicia la respuesta; la evidencia de cierre demuestra que quedó contenida, resuelta o aplazada de forma deliberada.
Por qué: El disparador define cuándo comienza el trabajo. La evidencia de cierre define la condición observable con la que la respuesta termina o se aplaza de forma explícita.
¿Cuándo debe eliminarse una responsabilidad operativa propuesta?
Mostrar respuesta y explicación
Respuesta: Cuando genera actividad sin proteger una necesidad definida del producto.
Por qué: La eliminación es apropiada cuando la actividad no tiene un propósito de protección definido. La dificultad, por sí sola, no justifica eliminarla.