Etapas de desarrollo de un equipo: ¿en cuál se ha estancado el tuyo?

Tu equipo de desarrollo no avanza como estaba previsto y no sabes si es un problema de personas o de tiempos. El modelo de las etapas de desarrollo de un equipo, formalizado por el psicólogo Bruce Tuckman en 1965, responde precisamente a esa pregunta: todo equipo, incluido un equipo técnico en remoto, atraviesa fases previsibles antes de llegar a rendir. Dirijo un equipo de desarrolladores vietnamitas desde hace más de diez años y he visto este modelo cumplirse casi al detalle en cada nueva squad que hemos montado para un cliente.

El modelo de Tuckman: las 5 etapas de desarrollo de un equipo, explicadas sin rodeos

El modelo de Tuckman describe cinco fases por las que pasa cualquier grupo de personas antes de funcionar como un verdadero equipo: forming, storming, norming, performing y adjourning. Bruce Tuckman, doctor en psicología, construyó este modelo en 1965 analizando más de 50 estudios sobre dinámica de grupos, según rhperformances.fr. Doce años más tarde, con Mary Ann Jensen, añade la quinta fase, el adjournment, para cubrir el final de vida de un equipo.

¿Por qué este modelo sigue siendo la referencia en gestión de equipos técnicos?

Porque cabe en cinco palabras fáciles de recordar y encaja con lo que vive de verdad una squad de desarrolladores. En la etapa de formación, los miembros todavía se están tanteando: son correctos, prudentes, y esperan instrucciones claras por parte de la dirección. Llega después la confrontación, donde chocan los roles, los métodos de trabajo y a veces los egos. Manager-go.com describe bien ese giro: el equipo pasa de una energía individual a un intento de coordinación, a menudo doloroso.

Luego la normalización instala reglas comunes, rituales de stand-up, una forma compartida de hacer la revisión de código. La fase de rendimiento es aquella en la que el equipo supera la suma de sus individuos: toma decisiones sin esperar al manager, absorbe los imprevistos. Es la etapa que todo CTO que delega parte de su desarrollo quiere alcanzar lo antes posible, y es justo ahí donde el método de puesta en marcha del equipo lo cambia todo.

Por qué la fase de confrontación dura más con un equipo en remoto

Un equipo offshore no atraviesa el storming de forma distinta en el fondo, pero lo atraviesa más despacio si nadie compensa la ausencia de señales informales. En la oficina, un jefe de equipo detecta una tensión en cinco minutos de pasillo. En remoto, entre Francia y Vietnam, con seis horas de diferencia, esa misma señal tarda a veces dos semanas en aparecer, en forma de un ticket que ya no avanza.

¿Cómo reconocer el storming en un equipo en remoto?

Tres síntomas se repiten siempre: estimaciones de sprint que se disparan sin explicación clara, desarrolladores que dejan de hacer preguntas en las reuniones, y un product owner que empieza a micromanagear porque ya no sabe por dónde va el proyecto. Creo que en esta etapa nunca es un problema de competencia técnica, es un problema de encuadre. El modelo de Tuckman advierte además de que esta fase es necesaria: no se puede saltar para ir directamente al rendimiento, ni pagando más.

Donde muchos clientes se equivocan es al pensar que un equipo offshore más barato va a quedarse necesariamente más tiempo atascado en el storming. No es una cuestión de coste, es una cuestión de organización. Un equipo vietnamita senior, con un único referente técnico del lado del cliente y una demo semanal no negociable, sale de esta fase casi tan rápido como un equipo local.

Cómo una agencia offshore estructurada acelera el paso a la fase de rendimiento

La palanca principal no es el tamaño del equipo, es su estructura de dirección. Un Offshore Development Center bien construido, con un punto de contacto permanente y estándares de código escritos desde el primer día, absorbe gran parte de la ambigüedad que normalmente alimenta la fase de normalización. El sector digital en Francia sigue tensionado en los perfiles senior, lo que empuja de forma mecánica a las empresas a buscar fuera: según Syntec Numérique, el sector emplea a varios cientos de miles de trabajadores y le cuesta cubrir sus necesidades de desarrolladores con experiencia, un desequilibrio que explica en gran parte el auge del offshore en los últimos años.

¿Hay que imponer un único jefe de proyecto para acortar la fase de normalización?

Sí, sin excepción. El modelo de Tuckman insiste en el papel del líder en cada etapa, y esa responsabilidad no se reparte bien a distancia. En las squads que he visto arrancar en GoLive Software, aquellas con un solo referente técnico del lado de Vietnam salen del storming en dos o tres semanas. Aquellas en las que dos personas se reparten la coordinación sin jerarquía clara se quedan a veces dos meses, con los mismos desarrolladores y el mismo proyecto.

La tabla siguiente compara las duraciones observadas, etapa por etapa, entre un equipo clásico montado internamente y un equipo offshore vietnamita dirigido con un método ODC.

FUENTE: transcripciones citadas · ACT. 09/2026

Un equipo offshore mal montado nunca es víctima de su diferencia horaria, es víctima de su falta de estructura. Es la única frase de esta guía que hay que retener si solo puedes quedarte con una.

El papel de la IA en la aceleración de las etapas de desarrollo de un equipo

La inteligencia artificial no elimina ninguna de las cinco etapas del modelo de Tuckman, pero sí cambia la velocidad a la que un equipo las atraviesa, en particular el norming. Cuando cada desarrollador usa Claude Code o Cursor para producir código ya documentado y testeado, la fase en la que el equipo negocia sus estándares de calidad se acorta mecánicamente: los estándares ya están puestos en parte por la herramienta.

¿Puede la IA hacer que se salte una etapa del modelo de Tuckman?

No, y ahí es donde muchas empresas se equivocan en 2026. Creo que la IA no sustituye a los buenos desarrolladores, amplía su capacidad de producción, pero no sustituye el tiempo que necesita un equipo para aprender a confiar en sí mismo. Alguien sin formación de ingeniero que genera código con un agente de IA puede producir líneas que funcionan, pero no sabe gestionar la arquitectura, la seguridad ni los casos límite que un equipo de verdad resuelve atravesando juntos el storming y el norming.

He calculado el ahorro real de un equipo offshore asistido por Claude Code en varios proyectos recientes, y la conclusión es clara: lo que la IA cambia de verdad es la relación entre el número de desarrolladores necesarios y el resultado entregado. Un equipo vietnamita senior pequeño, bien organizado y asistido por IA, puede hoy competir con un equipo europeo mucho más grande y mucho más caro, siempre que ya haya alcanzado la etapa de rendimiento. Es justo por eso que creo que la ventaja de Vietnam se refuerza con la IA en lugar de erosionarse: costes razonables, una cultura técnica sólida, y ahora una productividad individual más alta.

Un equipo que ha entendido esto no espera a terminar de contratar para instalar sus estándares de código asistido por IA. Los pone ya en la etapa de formación, lo que acorta en la misma medida la confrontación que viene después.

Si tu equipo lleva más de dos meses estancado en la misma etapa, el problema casi nunca son las personas que ya están ahí. Es la falta de una dirección única y de rituales no negociables, dos cosas que una agencia offshore seria instala incluso antes del primer sprint. Un equipo bien montado, aunque sea en remoto, supera el storming y el norming en unas semanas, no en unos meses, y es ese plazo, más que la tarifa diaria, el que debe guiar tu elección de proveedor.