El infierno del multi-proyecto: estar en tres equipos a la vez y en ninguno de verdad

Publicado el 13 de julio de 2026  •  13 minutos  • 2753 palabras

Hay un momento en la carrera de cualquiera en tecnología en el que deja de tener “un proyecto” y pasa a tener una colección.

No eres un arquitecto de soluciones; eres un plato combinado. En tu caso ni siquiera hablamos de dos o tres frentes: hablamos de un mínimo de cuatro proyectos a la vez, cada uno con su ecosistema, sus dramas y sus diapositivas propias.

Y, claro, luego te preguntas por qué terminas muchos días con la sensación de no haber profundizado en nada.

Vamos a llamarlo por su nombre: el infierno del multi-proyecto.

El bonito PowerPoint donde esto tiene sentido

Sobre el papel, la cosa siempre empieza de forma muy razonable.

En una reunión alguien abre una diapositiva con un diagrama de cajitas: proyectos A, B, C y D. En cada cajita aparecen nombres. Al lado del tuyo pone “20%”, “30%”, “10%”, “40%”.

La idea suena casi científica: así aprovechamos mejor “el recurso”. Tú ya no eres una persona, eres un porcentaje.

La narrativa es impecable: hay que “maximizar utilización”, que “no haya gente infrautilizada”, que “apalanquemos el conocimiento transversal”. Todo palabras que quedan fenomenal en consultoría.

Nadie menciona un pequeño detalle: tu cerebro no factura por porcentajes. No hay un thread por proyecto esperando en pausa hasta que tú lo despiertes. No hay context switch barato.

La realidad es mucho menos elegante: estás en una reunión de un proyecto, te hablan de fechas, decisiones, dependencias… y tu cabeza está todavía arrastrando un trozo del modelo de datos del otro proyecto, más una duda de arquitectura del tercero y la preocupación de que en el cuarto hay un riesgo que nadie ha entendido.

Pero, oye, en el Excel el 20/30/10/40 cuadra.

El coste real de saltar de piscina en piscina

Lo que hacen los PowerPoints es esconder un hecho bastante incómodo que la psicología cognitiva lleva décadas repitiendo: no sabemos hacer multitarea, hacemos cambio de tarea.

Cada vez que cambias de contexto, tu cerebro tiene que soltar un conjunto de modelos mentales y cargar otros nuevos. Eso no es instantáneo, no es gratis y no mejora con práctica; solo te engañas mejor.

Hay estudios que lo cuantifican con una precisión desagradable. En entornos de trabajo del conocimiento, cada vez que te interrumpen o cambias de tarea, puedes tardar unos 20-23 minutos en recuperar el nivel de foco que tenías antes.

Y no estoy exagerando, hablo de cosas normales: volver a acordarte de dónde estaba ese edge case, qué limitaciones tenía aquella API, por qué habías descartado una opción de diseño. Son pequeñas cosas que suman, como recoge este artículo sobre por qué el cerebro no rinde con la multitarea y confirma este análisis sobre el coste del cambio de contexto .

Cuando se analizan equipos de ingeniería reales, con miles de developers, los datos dan miedo: con tres proyectos en paralelo, fácilmente se te va un 40% del día solo en el coste de cambio de contexto.

No es que estés en Twitter, es que estás reconstruyendo en tu cabeza el mapa de cada sistema, una y otra vez, según este análisis sobre cómo el cambio de contexto destruye la productividad y los mismos datos sobre el coste del cambio de contexto .

Hay investigaciones específicas en desarrollo de software que lo describen con precisión casi quirúrgica: cambiar de tarea obliga a tu memoria de trabajo a hacer malabares, pierdes parte de lo que estabas manteniendo en mente y la probabilidad de errores aumenta.

Y da igual que lleves veinte años programando: el hardware es el mismo, tal y como muestran este estudio sobre el coste cognitivo de las interrupciones en programación y esta investigación de la Universidad de Essex sobre multitarea en desarrollo de software .

Multi-proyecto para “aprovecharte mejor”

Entonces llega la parte divertidísima: los responsables que no han leído nada de esto deciden que lo más eficiente es repartirte entre el mayor número de proyectos posible.

Total, si en uno “no tienes ahora mucho que hacer”, te pueden meter en otro para rellenar.

Un estudio hecho en una multinacional gorda, con cientos de empleados, miró precisamente esto: cuántos proyectos puede manejar una persona antes de que todo empiece a romperse.

Lo que encontraron no sorprende a nadie que haya tenido agenda: cuando superas los cinco proyectos a la vez, el rendimiento se desploma. Se retrasan fechas, baja la calidad, la gente siente que llega siempre “tarde” a todas partes.

No solo es malo para ti; es malo para la empresa, para los proyectos y para los clientes, según este artículo del Foro Económico Mundial sobre el impacto de demasiados proyectos en la productividad y el burnout y este análisis de RTE Brainstorm sobre el mismo problema .

Y aquí estás tú, con cuatro proyectos como mínimo, que ya bordea (casi por el lado de fuera) el límite “científico”, y seguramente con mini frentes colgando alrededor (una consultoría aquí, una revisión de arquitectura allí, un favorcito técnico más allá).

Normal que tengas la sensación de que nunca terminas nada del todo. No es una impresión subjetiva; es lo que dicen los datos: el cerebro, cuando lo trocean así, deja de profundizar y pasa a sobrevivir, como recogen la investigación de la Universidad de Essex sobre multitarea en desarrollo de software y el artículo sobre por qué el cerebro no rinde con la multitarea .

Estar en tres equipos y no pertenecer a ninguno

Otra faceta que no sale en los estudios pero se nota en el estómago es la pertenencia. Cuando estás en un equipo de verdad, tienes caras, ritmos, bromas internas. Sabes quién sufre con qué módulo, a qué usuario le duele qué, qué decisiones llevan historia detrás. Hay una narrativa compartida.

Cuando estás repartido entre tres o cuatro equipos, esa pertenencia se diluye. Eres un invitado permanente. Llegas a una daily y están hablando de algo que empezó anteayer en un hilo de Slack donde no estabas. Te pierdes el contexto; te ponen al día a toda prisa; opinas con información parcial. A la siguiente reunión del otro proyecto te pasa lo mismo, pero con personajes distintos.

La gente te introduce siempre igual: “Este es X, nuestro arquitecto de soluciones. Está con nosotros… bueno, también con otros equipos”. En la práctica eres un arquitecto itinerante. Vas dejando opinión y planos por donde pasas, pero con poco tiempo para ver cómo se asientan realmente las cosas.

Ese “estar en todas partes y en ninguna” desgasta de una forma rara. No es solo carga de trabajo. Es la sensación constante de estar a medias: a medias de contexto, a medias de compromiso, a medias de profundidad. Como si siempre hubieras llegado tarde cinco minutos.

Las agendas Tetris y los días sin huecos

Si dibujas un día habitual, la cosa tiene forma de Tetris: reunión de proyecto A a las 9, de proyecto B a las 10, hueco de 45 minutos que apenas da para desbrozar correo y abrir código, proyecto C a las 12, comida medio leyendo un documento del proyecto D, por la tarde otra de A, una de B, luego ese ratillo heroico de 17:30 a 19:00 en el que intentas hacer “trabajo de verdad”.

Las empresas que se dedican a medir estas cosas han mirado el coste real de este patrón de fragmentación y ponen números: un trabajador del conocimiento medio tiene 6-8 cambios de contexto fuertes al día, y eso sale en unos 28.000 dólares al año por cabeza en tiempo perdido, si sumas lo que cuesta que la gente vuelva a entrar mentalmente en la tarea.

Multiplica por un equipo de 50 y te da una cifra que haría llorar a cualquier CFO. Pero como ese dinero se pierde en minutos dispersos, nadie lo ve, según este estudio sobre el coste del cambio de contexto y cómo programar mejor la agenda y los mismos datos sobre el coste del cambio de contexto .

El estudio de Parnin, Blincoe y compañía sobre multitarea en proyectos de software es muy revelador: analizaban patrones de actividad y llegaban a la conclusión de que muchos developers solo pasan entre 0,3 y 2 minutos seguidos en la misma actividad antes de cambiar. No porque sean despistados, sino porque el entorno se organiza así. Así no profundiza ni un cerebro cuántico, como recoge también este repaso sobre el mito de la multitarea .

Tú, como arquitecto, lo sufres con un plus: tu trabajo no es solo escribir código, es sostener modelos mentales grandes. Dominios completos, flujos de negocio, despieces de sistemas.

Eso no cabe en tandas de 15 minutos. Necesitas bloques largos para pensar. En modo multi-proyecto, esos bloques son una especie en extinción.

Profundidad imposible: la arquitectura “de pasillo”

Lo más traicionero del multi-proyecto para alguien de arquitectura es que convierte decisiones que deberían pensarse en serio en arquitectura de pasillo.

Entre reunión y reunión, entre dos llamadas, haces malabares: lees por encima, decides algo “razonable” para desbloquear al equipo, prometes mirar con más detalle luego.

Ese “luego” casi nunca existe.

Claro, más tarde te despiertas a las tres de la mañana pensando: “igual este patrón de integración que he aceptado aquí entra en conflicto con lo que propuse allí”.

No es postureo de arquitecto torturado. Es la realidad de estar intentando mantener en la cabeza cuatro contextos a la vez, cada uno con su legado, sus restricciones y sus stakeholders ansiosos.

La literatura de interrupciones en desarrollo de software insiste justamente en eso: interrumpir tareas de diseño y arquitectura tiene un coste más alto que interrumpir tareas mecánicas, porque rompes más estado interno.

Y cuando eres tú mismo el que se interrumpe porque tiene que saltar a otra reunión de otro proyecto, es aún peor: las auto-interrupciones son, paradójicamente, más dañinas que las externas.

Te cambias de sitio antes de haber cerrado el capítulo mental, tal y como detalla este estudio sobre el coste cognitivo de las interrupciones en programación .

La sensación permanente de no acabar nada

Con este panorama, no es raro que aparezca esa sensación de que “no terminas nada del todo”.

No es solo una emoción; es una consecuencia directa del sistema.

Cuando tu tiempo se trocea en tantos frentes, tiendes a dejar cabos sueltos, apañar soluciones suficientes para hoy y fiarlo mucho a que “el equipo ya lo remata”.

Pero tú sabes que muchas veces el equipo va a rematar con las prisas de siempre, sin esa revisión profunda que habrías hecho si hubieras tenido un día entero para vivir solo en ese contexto. No es que no quieras, es que no te dejan.

Las investigaciones sobre gestión de multiproyecto lo resumen de forma bastante seca: estar en demasiados proyectos a la vez perjudica tanto los plazos como la calidad y la moral. Se entrega más tarde, con más estrés y con una experiencia subjetiva mucho más pobre. La gente trabaja más para conseguir menos sensación de logro.

Es como correr en cinta: mucho esfuerzo, cero desplazamiento, según recogen tanto RTE Brainstorm como el Foro Económico Mundial .

“Pero así estás más visible”, decían

Hay otro argumento envenenado que se usa para justificar el multi-proyecto: “así tienes exposición a más áreas, conoces más negocio, eres más estratégico”.

Sobre el papel hasta suena bien. En la práctica suele significar “te vamos a poner en todos los berenjenales complicados porque eres de fiar, pero sin darte tiempo para respirar en ninguno”.

Conoces mucho, sí, pero todo a medias. ¿El dominio de pagos de aquí? Lo conoces lo suficiente para no romperlo, pero no lo suficiente para rediseñarlo sin mirar. ¿La lógica de facturación de allá? La entiendes, pero se te escapan detalles. ¿El modelo de datos del otro lado? Te suena, pero tendrías que volver a leerlo.

Es el conocimiento tipo turista: has estado en todas partes, pero en ninguna has vivido de verdad.

Los estudios dicen lo que ya intuías

Cuando te da la vena de friki y empiezas a buscar estudios sobre esto, te reconoces con una risa floja al ver cómo te describen.

Por ejemplo, este trabajo clásico sobre multitarea en proyectos de software (también disponible como preprint en arXiv ) se dedicó a analizar registros de actividad de programadores en varios proyectos industriales y descubrió que los que estaban en muchos proyectos a la vez solo eran más productivos si concentraban el trabajo por días, es decir, si cada día tocaban pocos frentes

En cuanto empezaban a saltar entre proyectos muchas veces en la misma jornada, la productividad caía en picado, en línea con lo que ya apuntaba este estudio de Parnin y Blincoe .

Otro estudio, más general sobre trabajadores del conocimiento, habla directamente de que cambiar de tarea continuamente puede generar hasta un 40% de pérdida de rendimiento. No porque seas vago, sino porque tu cerebro se queda atascado en el arranque cada vez, según este repaso sobre el mito de la multitarea y el artículo sobre por qué el cerebro no rinde con la multitarea .

Y luego está el dato más cercano a tu caso: el mismo límite de los cinco proyectos que ya hemos visto.

Tú estás en cuatro de base, justo al borde. Si en algún momento te añaden “solo uno más, que es como un 10%”, ya sabes matemáticamente dónde entras.

¿Tiene salida este infierno o toca acostumbrarse?

La parte tentadora aquí sería terminar diciendo: “pues ya sabes, di que no, céntrate, bla bla”. Pero sé que muchas veces no depende de ti. Los sistemas que crean multi-proyecto lo hacen por decisiones de arriba: por no contratar más, por no priorizar mejor, por no aceptar que hay cosas que no se pueden hacer a la vez.

Lo que sí puedes hacer, al menos en el margen, es poner algo de forma al caos. Por ejemplo, intentar agrupar días por proyecto. Decir explícitamente: “este día estoy con A, este con B, este con C; si me metes una reunión de D aquí, me cargas un coste de cambio de contexto que pagamos todos”.

No siempre colará, pero no decirlo garantiza que nadie se entera.

También ayuda dejar más rastro escrito: RFCs cortos, decisiones de arquitectura anotadas, pequeños resúmenes de contexto. Cuanto más contexto tengas fuera de tu cabeza, menos se pierde cada vez que saltas de sitio. No convierte cuatro proyectos en uno, pero baja un poco la factura cognitiva.

Y, sobre todo, viene bien recordarte que esa sensación de no llegar a la profundidad que te gustaría no es un fallo tuyo. Es el síntoma de un sistema mal diseñado, que confunde exprimir al máximo el calendario con aprovechar bien el talento.

Tu cerebro, con un proyecto bien enfocado, se podría permitir el lujo de entrar en modo profundidad brutal. Con cuatro a la vez, bastante hace con no fundirse.

Y los estudios, por una vez, están de tu parte.

Fuentes y referencias

Para quien necesite enseñarle estos datos a su jefe (con tacto), aquí están las fuentes:

• Por qué el cerebro no rinde con la multitarea — News-Medical. Artículo sobre los límites cognitivos de la multitarea y cómo afecta al foco.
• El coste del cambio de contexto — contextcost.com. Recopilación de datos sobre el impacto del cambio de contexto en la productividad.
• Cómo el cambio de contexto destruye la productividad — pandev-metrics. Análisis del coste de cambiar de tarea en equipos de ingeniería.
• El coste cognitivo de las interrupciones en programación — arXiv. Estudio sobre cómo las interrupciones afectan a la memoria de trabajo durante el desarrollo de software.
• Multitarea en desarrollo de software — Universidad de Essex. Investigación sobre el efecto del cambio de tarea en programadores.
• Demasiados proyectos, productividad y burnout — Foro Económico Mundial. Análisis del impacto de la sobrecarga de proyectos en plazos, calidad y bienestar.
• Proyectos de trabajo y burnout en el lugar de trabajo — RTE Brainstorm. Artículo sobre cómo demasiados proyectos simultáneos afectan a plazos, estrés y moral.
• El coste del cambio de contexto y cómo programar mejor la agenda — skdul.ai. Estudio sobre el coste económico del cambio de contexto y posibles soluciones de agenda.
• Estudio de Parnin y Blincoe sobre multitarea en proyectos de software — ICSE 2016. Análisis de patrones de actividad de programadores en múltiples proyectos.
• El mito de la multitarea — unsizify.com. Repaso de por qué la multitarea reduce el rendimiento real.
• Preprint sobre multitarea y productividad en desarrollo de software — arXiv. Versión preprint del estudio sobre concentración de trabajo por días.
• Trabajo clásico sobre multitarea en proyectos de software — Chase et al. Estudio sobre cómo la concentración del trabajo por días afecta a la productividad de los developers.