---
title: Formación Ops
route: /es/ops-training
lang: es
part_of: Onirion
version: "4.0"
date: 2026-09-22
author: Alexis Boyer
license: Todos los derechos reservados
one_line: La formación ayuda a los equipos que hacen posible el trabajo de los Product Builders a hacer utilizables sus servicios compartidos.
layers:
  summary: /es/ops-training
  complete_text: /es/complete.md
  markdown: /es/ops-training.md
---

# Formación Ops

La formación ayuda a los equipos que hacen posible el trabajo de los Product Builders a hacer utilizables sus servicios compartidos.

## Formato y precio

Desde 4500 € por grupo, IVA no incluido

Dos días (14 horas), en inglés o en francés, hasta ocho participantes

Incluye una llamada de preparación de 60 a 90 minutos y una revisión de seguimiento de 90 minutos, dos o tres semanas después

Reservar una formación: lcnlechevaliernoir@gmail.com

o escribe a lcnlechevaliernoir@gmail.com

**La pregunta central**

¿Puede un Product Builder empezar una iniciativa real usando las convenciones, los componentes, las API, los accesos y los circuitos de revisión de la organización, sin reconstruir los cimientos ni esperar a un responsable sin designar?

**Para quién es**

Design Ops, Frontend Ops, Backend/API Ops, Data Ops, y los responsables de accesos, entrega, observabilidad y revisión de cuyos servicios depende un Product Builder.

**Lo que no es**

No es un ejercicio guiado de Claude Design ni de programación de una funcionalidad.

*Figura — imagen, 3:2: Una mesa de taller con el primer paquete de arranque extendido encima, impreso a razón de una hoja por capacidad, mientras se anota.*

## Lo que pone en marcha cada capacidad

El mismo orden que la fila horizontal de «El principio», para que la fila que reconoces allí sea la fila a la que llegas aquí.

| Capacidad | Recursos de trabajo para los Product Builders |
| --- | --- |
| Design Ops | Patrones y componentes revisados, pautas de interacción y de estados, un circuito de revisión de diseño, y una forma clara de conservar el diseño aceptado para la implementación. |
| Frontend Ops | Un repositorio starter aprobado y mantenido, o una configuración equivalente, con una versión conocida, un responsable e instrucciones para clonar y arrancar, además de convenciones de estructura, componentes, estado, enrutamiento, accesibilidad, localización, pruebas e integración. |
| Backend y API Ops | Patrones de referencia para autenticación, permisos, migraciones y pruebas; contratos de API fáciles de encontrar, con su significado de negocio; versionado, convenciones de errores, entornos de pruebas, convenciones de backend escritas como criterios con los que se puede verificar un cambio, que empiezan por la receta para los cambios más comunes y se mantienen al día con lo que encuentran las revisiones, con un revisor designado, y un circuito para pedir o construir una API que falta. |
| Data Ops | Definiciones y contratos de eventos claros, datos de prueba adecuados, reglas de acceso y de calidad, y una forma de responder a una pregunta de aprendizaje concreta. |
| Accesos y entrega | Un responsable designado y un plazo de respuesta para accesos con el alcance adecuado; ramas protegidas, controles obligatorios, entornos identificados y evidencia de qué versión se está ejecutando. |
| Observabilidad y revisión | Acceso de solo lectura a los logs útiles, a los errores y al estado de las integraciones; un circuito de diagnóstico y de incidentes; y un circuito de revisión técnica fiable, con un responsable designado. |

## Cuando falta algo

1. **El Product Builder envía una solicitud acotada** — Contexto, restricciones, un plazo de respuesta y un criterio de aceptación.
2. **El responsable de Ops decide** — Ampliar el servicio compartido, o conceder una excepción.
3. **Las dos partes verifican el resultado** — En el producto integrado, no en el documento.

## Cómo se desarrolla la formación

Dos días, 14 horas, en inglés o en francés, para un máximo de ocho participantes de los equipos de Ops, con al menos un Product Builder y un sponsor que pueda resolver las cuestiones de responsabilidad.

1. **Preparación** — Una llamada de 60 a 90 minutos para elegir un itinerario real de un Product Builder, reunir las pautas existentes e identificar a los responsables de Ops que pueden decidir durante el taller.
2. **Día 1 — ver el trabajo desde el lado del Product Builder** — Seguir cómo empezaría esa iniciativa un Product Builder, comprobar si cada servicio es operativo y no solo está documentado, y definir el servicio mínimo que debe ofrecer cada equipo.
3. **Día 2 — construir el primer paquete de arranque** — Cada equipo redacta su primera contribución utilizable, acuerda cómo se piden y se verifican las capacidades que faltan, y pide a un Product Builder que recorra el paquete y marque lo que es utilizable, lo que no está claro y lo que está bloqueado.
4. **Revisión de seguimiento** — Una revisión de 90 minutos, dos o tres semanas después, para comprobar si un Product Builder pudo usar los primeros recursos en una iniciativa real.

## Con lo que se va el grupo

Un paquete de arranque para Product Builders, versión 0

1. Un mapa del itinerario elegido y de sus bloqueos actuales.
2. Responsables designados y un pequeño catálogo de los servicios compartidos que necesita ese itinerario.
3. Borradores de convenciones de frontend y de backend/API, con el repositorio starter aprobado o un plan concreto para construir uno.
4. Un mapa de API y de accesos: qué existe, quién es su responsable, cómo obtener accesos con el alcance adecuado y qué falta.
5. Pautas de diseño y de datos donde ese itinerario las necesite.
6. Una comprobación de preparación de los controles obligatorios, las ramas desplegables, los entornos, la evidencia de qué versión se está ejecutando, los diagnósticos y la revisión técnica.
7. Un contrato de solicitud y respuesta entre Product Builders y responsables de Ops, con tiempos de respuesta, evidencia de aceptación y escalado.
8. Un plan a 30/60/90 días con responsables que rinden cuentas.

## El kit gratuito sigue completo.

Nada de lo que un Product Builder necesita para un primer recorrido está reservado a la formación.

El taller produce un paquete inicial y un plan priorizado. Redactar un conjunto completo de convenciones de producción, construir nuevas API, aprovisionar accesos y hacer cambios de plataforma son trabajo posterior de los equipos responsables.

Reservar una formación: lcnlechevaliernoir@gmail.com