Extensión de equipo vs equipo dedicado vs gestionado: elige por capacidad

La extensión de equipo, un squad dedicado y un equipo totalmente gestionado pueden poner a los mismos ingenieros a trabajar en tu código. Lo que cambia es cuánto de tu propio equipo consume cada modelo: quién escribe los tickets, quién revisa el código, quién atiende el aviso de las 03:00. Elige el modelo que tu capacidad interna puede sostener y, después, escribe el contrato y el primer mes de forma que el reparto del trabajo quede explícito.

Las tres formas, tal como suelen venderse:

• Extensión de equipo (staff augmentation): de uno a tres ingenieros dentro de tu equipo, bajo tu engineering manager, trabajando sobre tu backlog.
• Squad dedicado (un equipo dedicado): de cuatro a seis personas con su propio tech lead, desarrolladores y QA. Tú te encargas de la dirección de producto; ellos, de la ejecución de ingeniería.
• Equipo totalmente gestionado: de seis a doce o más personas, con project manager, tech lead, desarrolladores, QA y DevOps. El partner se encarga de la entrega y te informa sobre resultados.

Tres preguntas que deciden el modelo

Respóndelas pensando en las personas que tienes hoy, con su carga actual.

1. 1¿Quién escribe y prioriza los tickets? Alguien tiene que convertir los objetivos en tareas lo bastante pequeñas para terminarlas en pocos días, con criterios de aceptación, y decidir su orden.
2. 2¿Quién revisa el código y es responsable de la arquitectura? Cada cambio necesita un revisor que conozca el sistema. Y alguien tiene que rechazar un diseño que hará daño dentro de un año.
3. 3¿Quién está de on-call para producción? Quien despliega un cambio tiene que estar localizable cuando falla, o saber exactamente quién lo está.

Después, interpreta las respuestas:

• Las tres son tuyas, con horas de sobra: extensión de equipo. Estás añadiendo manos a un sistema que ya funciona.
• Los tickets son tuyos; la revisión y la arquitectura no: un squad dedicado. El tech lead del partner asume la revisión y las decisiones técnicas dentro del área del squad.
• Solo las prioridades de negocio son tuyas: un equipo totalmente gestionado, con resultados, aceptación y on-call escritos en el contrato.
• Nadie es dueño de las prioridades: ningún modelo lo arregla. Un project manager puede escribir tickets, pero solo alguien de tu lado puede decidir qué importa.

"Con horas de sobra" es la parte que la gente se salta. Un ingeniero sénior que ya es el cuello de botella de las revisiones no puede asumir a tres autores más.

Ejemplo práctico: las horas que cada modelo quita a tu gente

Supón que quieres cuatro ingenieros más escribiendo código de producto. Las cifras son ilustrativas; sustitúyelas por las tuyas después del primer mes.

Extensión de equipo, cuatro ingenieros:

• Code review sénior, unas 3 horas por ingeniero: 12 horas.
• Product ownership (refinamiento, tickets, responder preguntas), unas 2 horas por ingeniero: 8 horas.
• Gestión (1:1, planificación, feedback al partner), alrededor de 1 hora por ingeniero: 4 horas.
• Total: 24 horas a la semana, más de la mitad de una persona sénior.

Squad dedicado (tech lead, tres desarrolladores, QA):

• Product owner (refinamiento, aceptación, la demo): 8 horas.
• Arquitectura (registros de decisión, cambios en interfaces compartidas): 4 horas.
• Una hora semanal con el tech lead del partner: 1 hora.
• Total: 13 horas a la semana.

Equipo totalmente gestionado (project manager, tech lead, cuatro desarrolladores, QA, DevOps):

• Responsable de negocio (prioridades, aceptación de hitos): 4 horas.
• Revisión de arquitectura y seguridad de las decisiones que afectan a tus otros sistemas o datos: 2 horas.
• Gobierno (informe semanal, revisión mensual, facturas): 2 horas.
• Total: 8 horas a la semana.

El onboarding va aparte. Para este ejemplo, cuenta con el doble de horas de revisión y de producto en las semanas uno a cuatro.

Ejemplo práctico: el coste mensual de cada modelo

Mismo escenario, con cifras inventadas para que la aritmética sea legible, no presupuestos: una tarifa plana de 8.000 € al mes por cada rol externo y 80 € por hora del tiempo de tu propia gente, con coste completo (salario, cotizaciones de la empresa, beneficios, equipo y gastos generales, divididos entre las horas trabajadas). Un mes son 4,3 semanas.

• Extensión de equipo: 4 × 8.000 € = 32.000 € facturados, más 24 h × 4,3 × 80 € = 8.256 € de tiempo interno. Unos 40.300 €, por cuatro ingenieros escribiendo código.
• Squad dedicado: 5 × 8.000 € = 40.000 €, más 13 h × 4,3 × 80 € = 4.472 €. Unos 44.500 €, por tres desarrolladores, un lead que también programa y QA.
• Equipo totalmente gestionado: 8 × 8.000 € = 64.000 €, más 8 h × 4,3 × 80 € = 2.752 €. Unos 66.750 €, por cuatro desarrolladores y todos los roles a su alrededor.

Sobre el papel, gana la extensión. El problema son las 24 horas: salen de tus personas más sénior, y 80 € no reflejan lo que esas personas construirían en ese tiempo. Si tus ingenieros sénior ya llenan la semana con revisiones e incidentes, las 12 horas de revisión salen del roadmap o no se hacen nunca. Con código sin revisar es como empieza a acumularse la deuda técnica. En ese caso, los 4.200 € extra al mes del squad pagan un tech lead que haga la revisión.

Un equipo gestionado incluye roles que, si no, cubrirías tú (gestión de proyecto, QA, releases e infraestructura), así que compáralo con lo que te cuestan esos roles internamente. Para los costes que una tarifa esconde, consulta los costes ocultos del desarrollo offshore barato.

Quién hace qué en cada modelo

Pon este reparto por escrito en el statement of work; si no está escrito, cada lado da por hecho que lo cubre el otro.

Extensión de equipo:

• Backlog y decisiones técnicas: tuyos.
• Code review: en los dos sentidos. Tus ingenieros revisan sus cambios y ellos revisan los tuyos.
• QA y releases: tu proceso y tu pipeline; escriben tests como todos los demás.
• On-call: entran en tu rotación solo si el contrato lo dice y lo paga.
• Contratación y sustitución: el partner busca candidatos; tú entrevistas y apruebas a cada uno.
• Gestión de personas: la dirección del día a día es tuya. Carrera, salario y evaluación del desempeño siguen con el partner como empleador.

Squad dedicado:

• Backlog: tu product owner fija las prioridades; el tech lead desglosa los elementos y los estima.
• Decisiones técnicas: el tech lead, dentro del área del squad. Los cambios en interfaces compartidas o modelos de datos pasan por tu revisión de arquitectura.
• Code review: dentro del squad; tus ingenieros revisan lo que cruza la frontera.
• QA: el ingeniero de QA del squad, contra criterios de aceptación que valida tu product owner.
• Releases: el squad, a través de tu pipeline y con tus reglas de cambio.
• On-call: el squad cubre sus propios servicios en su horario laboral, con una ruta de escalado escrita para el resto.
• Contratación, sustitución y gestión de personas: el partner; tú entrevistas como mínimo al tech lead.

Equipo totalmente gestionado:

• Backlog: tú fijas prioridades e hitos; el project manager del partner los convierte en un plan.
• Decisiones técnicas: el partner, con registros de decisión que puedes leer y tu veto sobre todo lo que afecte a tus otros sistemas, datos o seguridad.
• Code review, QA y releases: el partner, contra los criterios de aceptación del contrato, en entornos que son tuyos, con tu derecho a auditar cualquier cambio.
• On-call: el partner, con tiempos de respuesta escritos en el contrato.
• Contratación, sustitución y gestión de personas: el partner, dentro de los plazos del contrato.

Cláusulas del contrato que cambian según el modelo

Las comprobaciones generales sobre un partner (selección, referencias, certificaciones, duración del contrato) están en cómo evaluar un partner nearshore en Europa. Las cláusulas de abajo son aquellas cuya respuesta correcta depende del modelo. Llévalas a la negociación como preguntas; los valores son ejemplos.

• Qué pagas. La extensión y los squads se facturan por tiempo: pagas por personas, al mes. Un equipo gestionado también puede facturarse por resultados (hitos, un alcance cerrado). Eso traslada el riesgo de entrega al partner, pero solo funciona con criterios de aceptación lo bastante precisos para zanjar un desacuerdo.
• Aceptación. Quién da por bueno un entregable, contra qué, en cuántos días laborables y qué pasa si nadie responde. Imprescindible para facturar por resultados, útil para un squad.
• Plazo de sustitución. Días laborables hasta que se presenta un candidato de sustitución (ejemplo: diez), y si la persona que sale y la que entra se solapan, y a cargo de quién (ejemplo: dos semanas, facturadas una sola vez). Dale al tech lead del squad una cláusula propia.
• Preaviso y reducción. El preaviso para retirar a una persona o terminar la colaboración, y si puedes reducir un rol cada vez. Un equipo gestionado necesita más tiempo, porque antes tiene que moverse el conocimiento.
• Transferencia de conocimiento y salida. Lo que debe existir siempre, no solo al final: repositorios en tu organización desde el primer día, registros de decisión, un runbook por cada servicio que opera el partner, infraestructura como código y un inventario de cuentas. A la salida: un traspaso con personas concretas y una prueba de que tu equipo despliega y restaura sin ayuda.
• Cesión de la propiedad intelectual. Todo lo producido bajo el contrato se te cede: código, documentación y configuración, incluido el trabajo de subcontratistas.
• Obligaciones de seguridad. Acceso solo a través de tu proveedor de identidad con MFA, roles de mínimo privilegio, ninguna cuenta compartida, dispositivos del partner que cumplan tu política de dispositivos, baja de accesos en un plazo fijado (ejemplo: el mismo día laborable) confirmada por escrito, y notificación de incidentes en un número fijado de horas.
• Datos personales. Si la gente del partner puede llegar a datos personales (bases de datos de producción, logs, tickets de soporte), los trata por cuenta tuya, y el artículo 28 del RGPD exige un contrato escrito con el encargado del tratamiento: tratamiento solo según tus instrucciones documentadas, confidencialidad, medidas de seguridad, tu autorización previa por escrito antes de recurrir a otro encargado, y supresión o devolución de los datos al terminar el servicio.

¿No tienes claro qué modelo puede sostener tu equipo? Solicita una evaluación gratuita del modelo de equipo: vemos quién es dueño de tu backlog, cuántas horas de revisión tienen de verdad tus ingenieros sénior y quién lleva hoy el on-call, y después te recomendamos un modelo y te entregamos un esquema de contrato para él.

Primer día: accesos acotados al modelo

El onboarding, el acuerdo de trabajo y el plan de la primera semana están en cómo crear y gestionar un equipo de ingeniería remoto. Lo que cambia con el modelo es lo que cada persona puede tocar.

• Cuentas a través de tu proveedor de identidad. Una cuenta nominal por ingeniero en tu directorio, MFA obligatorio y todas las herramientas con inicio de sesión a través de él. Así, desactivar una cuenta debería retirar el acceso en todas partes.
• Ninguna credencial compartida. Nada de logins de equipo ni de claves pegadas en el chat. Los secretos salen de tu gestor de secretos, acotados por entorno.
• Roles en los repositorios según el modelo. Ingenieros de extensión: permisos de desarrollador, sin admin. Squad: el tech lead mantiene los repositorios del squad. Equipo gestionado: admin en los repositorios que le corresponden, que siguen estando en tu organización. La protección de ramas y la revisión obligatoria se aplican a todos.
• Roles en la nube según el modelo. Extensión y squad: acceso de lectura a producción, despliegues solo a través del pipeline, acceso elevado solo durante el on-call. Equipo gestionado: permisos operativos en los entornos que opera, con logs de auditoría que puedes leer.
• Grupos, no individuos. Asigna los roles a un grupo por equipo, por ejemplo partner-squad-billing, para que añadir o quitar a una persona sea un único cambio revisable.
• Prueba la baja el primer día. Desactiva una cuenta de prueba de ese grupo y comprueba que pierde los repositorios, la consola de la nube, el chat y cualquier clave o token que haya creado. Mejor encontrar ahora la herramienta que queda fuera del single sign-on que el último día de alguien.
• Un primer ticket entregado la primera semana. Pequeño y real, a través de todo el pipeline: la prueba de que el acceso funciona de extremo a extremo.

¿Funciona? Léelo en tu historial de git

Tu historial de git ya registra cuándo empezó el trabajo y cuándo llegó a la rama principal. El script de abajo recibe un archivo con las direcciones de correo del partner e informa de:

• Merges por semana ISO que contienen commits suyos.
• Mediana de horas desde el primer commit de una rama hasta su merge: lead time hasta el merge, no hasta producción.
• Mediana de horas desde el último commit de una rama hasta su merge: una aproximación de cuánto espera el trabajo terminado a la revisión y la aprobación.
• Directorios de primer nivel que solo ha cambiado el partner en el periodo: lo que tendrías que volver a aprender si la colaboración terminara.

Recibe direcciones, no un dominio, porque los ingenieros que inician sesión a través de tu proveedor de identidad pueden hacer commits con una dirección de tu dominio. Haz commit de un .mailmap para que las direcciones de cada persona se resuelvan en una sola, y pon en la lista las canónicas.

#!/usr/bin/env bash
# Usage: team-metrics.sh REPO BRANCH SINCE AUTHORS_FILE
#   e.g. team-metrics.sh ~/src/app main "12 weeks ago" partner-authors.txt
# AUTHORS_FILE: one email address per line, for everyone on the partner's team.
set -euo pipefail
export LC_ALL=C   # dot as decimal separator, byte-order sort
repo=$1 branch=$2 since=$3 authors_file=$4

author_args=(--fixed-strings)
while IFS= read -r email || [ -n "$email" ]; do
  if [ -n "$email" ]; then author_args+=(--author="$email"); fi
done < "$authors_file"
[ "${#author_args[@]}" -gt 1 ] || { echo "No addresses in $authors_file" >&2; exit 1; }

median() {
  sort -n | awk '{ v[NR] = $1 }
    END { if (!NR) print "n/a"; else if (NR % 2) print v[(NR + 1) / 2];
          else print (v[NR / 2] + v[NR / 2 + 1]) / 2 }'
}

# 1. Every merge into BRANCH that contains at least one commit from the team:
#    ISO week, hours from the branch's first commit to the merge (lead time to merge),
#    hours from its last commit to the merge (a proxy for the review and approval wait).
merges=$(mktemp)
git -C "$repo" log "$branch" --first-parent --merges --since="$since" \
  --date=format:'%G-W%V' --format='%H %ct %cd' |
while read -r merge merged_at week; do
  [ -n "$(git -C "$repo" log -1 --format=%H "${author_args[@]}" "$merge^1..$merge^2")" ] || continue
  first=$(git -C "$repo" log --format=%at "$merge^1..$merge^2" | awk 'NR == 1 || $1 < m { m = $1 } END { print m }')
  last=$(git -C "$repo" log -1 --format=%ct "$merge^2")
  echo "$week $(( (merged_at - first) / 3600 )) $(( (merged_at - last) / 3600 ))"
done > "$merges"

echo "Merges per week with the team's commits:"
cut -d' ' -f1 "$merges" | sort | uniq -c
echo "Median hours, first commit to merge: $(cut -d' ' -f2 "$merges" | median)"
echo "Median hours, last commit to merge:  $(cut -d' ' -f3 "$merges" | median)"
rm -f "$merges"

# 2. Top-level directories that only the team changed in the window: what you
#    would have to relearn if the engagement ended tomorrow.
echo "Directories changed only by the team (file changes, directory):"
git -C "$repo" log "$branch" --no-merges --since="$since" --format='author:%aE' --name-only |
awk -v list="$authors_file" '
  BEGIN { while ((getline line < list) > 0) if (line != "") team[tolower(line)] = 1 }
  /^author:/ { ours = (tolower(substr($0, 8)) in team); next }
  NF { n = split($0, part, "/"); dir = (n > 1 ? part[1] "/" : "./")
       if (ours) t[dir]++; else o[dir]++ }
  END { for (dir in t) if (!(dir in o)) print t[dir], dir }' | sort -rn

La parte de tiempos necesita merge commits; si tu plataforma hace squash o rebase al mergear, toma los tiempos de revisión de su API de merge requests. Ejecútalo cada mes y compáralo con tu propio equipo en el mismo repositorio, nunca con el benchmark de otra empresa.

Señales de que el modelo está fallando

Los números muestran que algo ha cambiado; estas señales muestran qué parte se ha roto.

Extensión de equipo:

• La mediana del último commit al merge no deja de subir: tus revisores son el cuello de botella, y la comprobación de capacidad falló.
• Todas las preguntas van a las mismas dos personas, y su propio rendimiento baja.
• Los tickets llegan a medio escribir y se reescriben durante el standup.

Squad dedicado:

• Tus ingenieros vuelven a revisar la mayoría de los cambios del squad. O no se confía en la revisión del tech lead, o no se debería.
• Los directorios que solo toca el squad no dejan de crecer mientras no aparecen registros de decisión nuevos.
• Las demos enseñan trabajo terminado que tu product owner nunca pidió.

Equipo totalmente gestionado:

• Los informes describen actividad (tickets cerrados, horas imputadas) en lugar de los resultados del contrato.
• La aceptación de hitos se retrasa, porque nunca se acordaron los criterios de aceptación.
• Nadie sabe decir quién atiende un aviso a las 03:00 de un servicio que opera el partner, o el runbook ya no coincide con producción.

Pasar de un modelo a otro

Cada cambio tiene condiciones previas; compruébalas antes de que cambie el contrato.

De extensión a squad, normalmente porque tus ingenieros sénior no dan abasto con las revisiones:

• Dale al squad un área acotada (un servicio, una línea de producto, un conjunto de directorios) con interfaces escritas hacia el resto.
• Entrevista tú al tech lead: esa persona toma ahora decisiones que antes tomabas tú.
• Pasa a los ingenieros de la extensión al squad siempre que puedas; son ellos los que tienen el contexto.
• Acuerda qué cambios siguen pasando por tu revisión de arquitectura.

De squad a equipo gestionado, normalmente porque quieres que el área se opere, no solo que se construya:

• Pon por escrito los criterios de aceptación y los niveles de servicio: a partir de ahora aceptas resultados en lugar de supervisar trabajo.
• Traspasa y ensaya el on-call y los runbooks, incluida tu ruta de escalado.
• Mantén los repositorios, las cuentas cloud y los pipelines en tu organización. El partner los opera; tú eres el dueño.

De vuelta hacia la extensión o hacia dentro, normalmente porque has contratado o el área está terminada:

• Ejecuta el informe de directorios: todo lo que solo ha tocado el partner necesita un responsable con nombre en tu lado.
• Haz que tus ingenieros se encarguen de los próximos releases y de una restauración mientras el partner aún puede ayudar.
• Reduce un rol cada vez, con el tech lead al final.

Evaluación gratuita del modelo de equipo

Si estás a punto de incorporar ingenieros externos, o una colaboración está rindiendo por debajo de lo esperado, nuestro servicio de equipos dedicados revisará tu situación sin coste. La evaluación cubre:

• Capacidad: quién escribe y prioriza tus tickets, cuántas horas de revisión tienen tus ingenieros sénior y quién lleva hoy el on-call.
• Encaje del modelo: qué modelo puede sostener hoy tu equipo y qué debe estar listo antes del siguiente.
• Esquema de contrato: facturación, aceptación, sustitución y preaviso, salida, propiedad intelectual y accesos, redactado para tu caso.

Recibes por escrito una lista de hallazgos, un modelo recomendado y un esquema de contrato, sin ningún compromiso. Solicita tu evaluación gratuita del modelo de equipo, o descubre cómo trabajan nuestros equipos de ingeniería nearshore desde Portugal.