Una agencia que crece suele llegar a un punto incómodo: desarrollo absorbe cada vez más trabajo operativo, pero contratar un equipo completo de plataforma todavía parece prematuro.
La decisión no es simplemente contratar o externalizar DevOps. Hay que decidir qué capacidad necesita la agencia, con qué continuidad y qué ownership debe conservar.
Cuándo encaja una contratación interna
Un perfil interno suele tener sentido cuando:
- existe trabajo operativo estable para ocupar la mayor parte de su capacidad;
- la plataforma es una ventaja competitiva central;
- el equipo puede ofrecer respaldo, revisión y desarrollo profesional;
- hay presupuesto para más de una persona a medio plazo;
- el conocimiento necesita permanecer diariamente dentro del producto.
Contratar una sola persona sin respaldo puede trasladar el problema: la operación deja de depender de un fundador o desarrollador y pasa a depender del nuevo perfil DevOps.
Cuándo encaja una capacidad externa
Managed Platform Operations puede ser adecuado cuando:
- la carga existe, pero varía entre proyectos y meses;
- se necesita experiencia en varias capas sin contratar varios perfiles;
- la prioridad es estabilizar y estandarizar antes de formar un equipo;
- la agencia necesita ofrecer mantenimiento a sus clientes;
- existe una persona técnica interna que puede mantener el contexto y las decisiones.
El modelo no debería ser una bolsa opaca de horas. Necesita sistemas bajo alcance, responsabilidades, backlog, revisiones y límites contractuales claros.
Qué debería incluir el servicio
Un alcance recurrente puede cubrir:
- mantenimiento de infraestructura como código;
- evolución de pipelines;
- gestión de accesos y secretos;
- onboarding de proyectos;
- observabilidad y respuesta a alertas acordadas;
- backups y pruebas de recuperación;
- revisión de costes;
- documentación y runbooks;
- roadmap trimestral.
No incluye automáticamente desarrollo funcional, soporte ilimitado ni responsabilidad sobre la lógica de las aplicaciones.
Comparación por criterio
Continuidad
Un equipo interno bien dimensionado ofrece gran continuidad. Un único perfil interno no. Un partner operativo debe demostrar respaldo y procedimientos para no recrear la misma dependencia.
Contexto
El equipo interno acumula contexto con rapidez. El modelo externo necesita rituales explícitos: backlog compartido, decisiones registradas, responsables y revisiones.
Velocidad de inicio
Una capacidad externa puede comenzar con un assessment y un alcance acotado. La contratación requiere búsqueda, selección y onboarding, pero puede ser mejor inversión cuando la necesidad es permanente y estratégica.
Coste
No se debe comparar solo salario frente a tarifa. Hay que incluir selección, tiempo sin cubrir, gestión, herramientas, guardias, respaldo y capacidad no utilizada.
Control
El control no depende de que el equipo sea interno. Depende de que repositorios, cuentas, documentación, accesos y decisiones permanezcan bajo la empresa cliente.
Matriz de decisión: cinco preguntas que cambian la respuesta
No existe un umbral universal de empleados o facturación. La decisión mejora cuando se puntúa la situación actual con evidencia:
| Criterio | Señal a favor de capacidad externa | Señal a favor de equipo interno |
|---|---|---|
| Carga | Backlog variable o inferior a una dedicación estable | Trabajo estable para varias personas |
| Contexto | Procesos repetibles y límites claros | Plataforma central para diferenciar el producto |
| Urgencia | Hay que estabilizar en semanas | Existe margen para contratar y formar |
| Especialidades | Se alternan CI/CD, cloud, Kubernetes, seguridad y costes | Predomina una plataforma y existe mentoría interna |
| Continuidad | El proveedor documenta respaldo y sustitución | La empresa puede construir rotación y guardias propias |
La tabla no toma la decisión por sí sola. Sirve para hacer visibles los supuestos. Si una respuesta depende de “la persona que sabe”, todavía no existe una capacidad operativa; existe una dependencia.
El contrato debe describir responsabilidad, no actividad
“Cuarenta horas de DevOps” no explica qué sistema se atiende, qué prioridad tiene un incidente o quién acepta un cambio. Un alcance operativo debería poder resumirse de forma parecida a esta:
servicio:
sistemas: [produccion-saas, pipelines, observabilidad]
responsabilidad_nubyron:
- mantener infraestructura como codigo
- revisar y ejecutar cambios aprobados
- verificar backups y alertas incluidas
responsabilidad_cliente:
- codigo y logica de aplicacion
- prioridades de producto
- aprobacion de cambios de riesgo alto
cobertura:
ventana: "laborables, horario acordado"
guardia_24x7: false
evidencia:
- backlog y estado de cambios
- decisiones de arquitectura
- resultado de comprobaciones operativasEl YAML es ilustrativo, no una plantilla contractual. Lo importante es que un tercero pueda leer el alcance y distinguir obligación, colaboración y exclusión.
Cómo comparar el coste sin engañarse
La comparación correcta separa cuatro capas:
- Capacidad directa: salario o tarifa y horas realmente disponibles.
- Capacidad de respaldo: revisión, sustitución, vacaciones y respuesta fuera de rutina.
- Coste de coordinación: tiempo de producto, desarrollo y dirección para priorizar y revisar.
- Riesgo residual: trabajos sin dueño, conocimiento concentrado y ventanas sin cobertura.
Un servicio externo caro puede ser ineficiente si únicamente revende horas. Una contratación aparentemente económica también puede serlo si trabaja sola, recibe todas las interrupciones y no tiene tiempo para automatizar. La unidad útil no es el precio por hora, sino el coste de mantener una responsabilidad operativa con el nivel de continuidad necesario.
Onboarding mínimo antes de tocar producción
Antes de ejecutar cambios deberían quedar revisados:
- propietario de cada cuenta, repositorio y dominio;
- inventario de entornos y dependencias críticas;
- accesos actuales y procedimiento de revocación;
- estado real de backups y recuperación;
- canales, severidades y personas autorizadas;
- backlog inicial y criterio de priorización;
- exclusiones, horario y procedimiento de escalado;
- formato de documentación y entrega de evidencias.
Si el onboarding no puede completarse, el primer resultado del servicio debería ser precisamente cerrar esas carencias. Empezar directamente por una migración o por “mejorar Kubernetes” suele ocultar riesgos previos.
Prueba de salida: el criterio que protege al cliente
Antes de contratar también conviene preguntar cómo termina la relación. Una salida sana permite que el cliente:
- revoque accesos sin detener producción;
- conserve repositorios, automatizaciones e historial;
- identifique cambios pendientes y riesgos aceptados;
- entregue la operación a un perfil interno o a otro proveedor;
- ejecute los procedimientos críticos sin depender de conversaciones privadas.
Esta prueba evita que Managed Platform Operations se convierta en una caja negra. También obliga al equipo interno a conservar el contexto suficiente para gobernar el servicio.
Como referencia para evaluar el rendimiento de entrega, el programa DORA de Google Cloud mantiene investigación y métricas sobre entrega de software. Esas métricas deben interpretarse dentro del sistema concreto; no sustituyen el análisis de responsabilidades ni justifican promesas universales.
Un camino combinado
Ambos modelos pueden ser etapas del mismo plan:
- diagnosticar y estabilizar;
- crear una base de entrega común;
- operar externamente durante el crecimiento;
- incorporar perfiles internos cuando la carga lo justifique;
- transferir o mantener un modelo híbrido.
La pregunta útil no es “¿externalizamos DevOps?”. Es: ¿qué capacidad operativa necesitamos durante los próximos doce meses y cómo evitamos que dependa de una persona?
Responderla exige comparar carga real, criticidad, frecuencia de cambios y coste de coordinación. El modelo correcto es el que reduce riesgo sin crear una dependencia nueva.
