¿Una persona o un equipo? Cómo definir la composición mínima de un proyecto según competencias, dependencias y riesgo

La investigación no respalda una regla simple como "los equipos pequeños siempre son mejores" o "los equipos grandes siempre producen más".

Un metaanálisis de 2023, con 208 efectos independientes y 21.435 equipos, encontró una relación global prácticamente nula entre tamaño del equipo y rendimiento de la tarea, pero una variación muy amplia según el contexto. Los autores muestran que la importancia del tamaño cambia, entre otros factores, con la complejidad de la tarea y las necesidades de coordinación. [4]

Un experimento sobre una tarea compleja de cartografía de crisis también mostró beneficios y costes de los equipos más grandes: la colaboración aumentó con el tamaño, mientras cambiaban los patrones de esfuerzo individual. En ese experimento concreto, los equipos más grandes superaron a un número equivalente de personas trabajando de forma independiente. No es una receta universal para cualquier trabajo. [5]

La conclusión práctica es sencilla: el número de personas debe derivarse de la naturaleza del trabajo, no de una cifra mágica.

La Scrum Guide de 2020 describe el Scrum Team como pequeño, multidisciplinar y autogestionado. También indica que normalmente tiene 10 personas o menos. [3]

Es una orientación útil dentro de Scrum, pero no una ley universal para todos los proyectos, servicios, sectores o modelos de trabajo.

Un proyecto de construcción, una campaña de marketing, una evaluación de seguridad, un sistema financiero y un pequeño sitio informativo tienen necesidades muy diferentes. No conviene trasladar una sola cifra directamente entre estos contextos.

El Service Standard británico exige que los equipos de servicios digitales sean multidisciplinares y tengan acceso a las competencias adecuadas. También señala que la composición debe responder a lo que el equipo necesita conseguir en cada fase. [1]

Otra guía de GOV.UK indica que el tamaño del equipo y las funciones necesarias cambian durante las distintas fases de construcción de un servicio. [2]

De ahí sale una regla práctica:

primero describe el trabajo y las responsabilidades, después identifica las competencias y solo al final asigna personas concretas.

No se puede dimensionar un equipo para un alcance poco claro.

Anota como mínimo:

• qué resultado debe producirse,
• qué está dentro del alcance,
• qué queda fuera,
• cuáles son los requisitos de calidad principales,
• qué límites de tiempo y presupuesto existen,
• quién aceptará el resultado,
• si el equipo solo debe entregar la solución o también operarla.

Un proyecto "crear una aplicación" y otro "diseñar, crear, proteger, desplegar y operar una aplicación durante un año" requieren una cobertura de trabajo completamente distinta.

En lugar de asignar puestos inmediatamente, enumera los tipos de trabajo que realmente deben realizarse.

En un servicio digital pueden incluir:

• comprender las necesidades de los usuarios,
• diseñar la solución,
• construir la parte visible para el usuario,
• desarrollar lógica e integraciones del lado del servidor,
• probar,
• seguridad,
• accesibilidad,
• despliegue y operación,
• coordinar alcance y decisiones.

Otro tipo de proyecto tendrá una lista diferente.

GOV.UK señala que un equipo que construye y opera un servicio digital necesita un conjunto amplio de competencias que cubra, entre otras cosas, necesidades de usuarios, diseño, construcción, pruebas, seguridad, despliegue y operación. [2]

No toda competencia necesaria exige una persona a tiempo completo dentro del equipo.

Clasifica cada área:

Permanente - se necesita de forma regular e influye directamente en decisiones cotidianas.
Periódica - se necesita en fases o puntos de control concretos.
Disponible externamente - puede proporcionarla otra persona o equipo si el tiempo de respuesta y la responsabilidad están suficientemente claros.

GOV.UK permite expresamente que el equipo tenga acceso a conocimiento especializado sin que el especialista sea necesariamente un miembro permanente. [1]

Esto suele evitar aumentar artificialmente el equipo sin perder una competencia importante.

Dos personas pueden reunir todas las competencias necesarias y aun así formar una mala configuración si todo el trabajo depende de una cadena estrecha.

Revisa:

• qué tareas pueden avanzar en paralelo,
• cuáles deben esperar a otras,
• quién toma decisiones que bloquean trabajo posterior,
• de qué equipos o proveedores externos depende el proyecto,
• dónde la ausencia de una persona detendría varias áreas a la vez.

GOV.UK incluye la gestión de dependencias con otros equipos entre las capacidades necesarias para crear servicios digitales. [2]

Cuando más de un equipo trabaja en un servicio, también aparece la necesidad adicional de coordinar planes y progreso entre equipos. [8]

Algunas competencias necesarias no aparecen en una lista de funciones del producto, pero su ausencia puede ser costosa.

Según el proyecto, pueden incluir:

• seguridad,
• protección de datos,
• accesibilidad,
• requisitos legales o sectoriales,
• fiabilidad,
• migración de datos,
• integraciones con sistemas críticos,
• tecnología que el equipo no haya utilizado antes.

GOV.UK recomienda acceso a conocimiento especializado cuando el proyecto lo necesita y señala que la composición debe reflejar también las hipótesis más arriesgadas de la fase actual. [1]

Esto no exige automáticamente un puesto a tiempo completo para cada riesgo. Sí significa que una persona competente debe tener una responsabilidad explícita y capacidad real para influir en las decisiones.

Una persona puede saber diseñar, desarrollar, probar y desplegar. Eso no significa que pueda realizar todos esos tipos de trabajo a la vez con cualquier plazo.

El material de PMI sobre planificación de recursos destaca la importancia de ajustar competencias, disponibilidad, coste y experiencia a las necesidades del proyecto. [7]

Para cada persona, revisa:

• cuánto tiempo puede dedicar realmente,
• qué tareas compiten por su atención,
• si el trabajo requerido debe avanzar en paralelo,
• si el plazo presupone cambios poco realistas entre muchos tipos de trabajo,
• si alguien deberá seguir operando la solución después del lanzamiento.

Cubrir las competencias sin cubrir el tiempo disponible no es cubrir todo el proyecto.

La composición mínima también debe considerar la continuidad.

Pregúntate:

• qué ocurre si una persona clave no está disponible,
• si solo una persona entiende una parte crítica de la solución,
• si decisiones y conocimiento están documentados,
• si otra persona puede asumir las tareas más importantes,
• si el proyecto puede detenerse de forma segura durante una ausencia.

No todo proyecto pequeño necesita redundancia completa. En un proyecto corto y de bajo riesgo, aceptar conscientemente ese riesgo puede ser razonable.

En un proyecto crítico, la misma dependencia de una sola persona puede ser inaceptable.

Un proyecto no necesita una persona diferente para cada nombre de función.

Si una persona posee realmente las competencias requeridas, tiene capacidad suficiente y no crea un riesgo inaceptable, puede cubrir varios ámbitos de forma responsable.

Por ejemplo, en un proyecto pequeño una persona puede combinar diseño de interfaz y realización. En otro, puede combinar análisis de negocio y coordinación del alcance.

No unas responsabilidades solo porque "alguien tiene que hacerlo". La combinación solo tiene sentido si la persona puede desempeñar ambas responsabilidades al nivel exigido y dispone de tiempo suficiente.

Una persona puede ser una configuración razonable cuando se cumplen a la vez estas condiciones:

• el alcance es pequeño y está bien definido,
• las competencias necesarias entran realmente en sus capacidades,
• las tareas requieren poco trabajo paralelo,
• las dependencias externas son limitadas,
• el riesgo es aceptable,
• el plazo corresponde a la capacidad real,
• la falta de sustitución se acepta conscientemente.

Puede ser el caso de un pequeño material informativo, un análisis sencillo, una consulta puntual o una implementación limitada en un entorno conocido.

Aun así, depende del alcance concreto. La etiqueta "proyecto pequeño" no resuelve la cuestión por sí sola.

Un equipo está más justificado cuando aparecen varias de estas condiciones:

• las competencias necesarias son demasiado amplias para una persona,
• muchas actividades deben avanzar en paralelo,
• el plazo es menor que una ejecución secuencial realista,
• el proyecto tiene muchas dependencias e interfaces,
• el riesgo requiere conocimiento especializado independiente,
• la solución debe construirse y operarse al mismo tiempo,
• una sola persona se convertiría en un punto crítico del proyecto,
• la responsabilidad cubre varias disciplinas claramente diferentes.

En estas condiciones, añadir capacidades que faltan importa más que aumentar simplemente el número de personas.

Añadir personas aumenta el conocimiento disponible y la capacidad potencial, pero también puede aumentar dependencias, transferencias de trabajo y la necesidad de coordinar decisiones.

Un estudio de proyectos de software publicado en Journal of Systems and Software mostró que las relaciones entre tamaño del equipo, productividad, esfuerzo y tiempo son complejas y no siempre coinciden con las expectativas intuitivas. [6]

El metaanálisis sobre tamaño de equipos también muestra que los resultados dependen del contexto de la tarea y del coste de los procesos de equipo. [4]

Por tanto, la pregunta no es "¿cuántas personas podemos añadir?", sino "¿la siguiente persona elimina una limitación real del proyecto más de lo que aumenta el coste de coordinación?"

No toda competencia importante debe estar presente cada día.

La presencia permanente tiene más sentido cuando la persona toma decisiones con frecuencia, su trabajo tiene muchas dependencias con otras áreas o se necesita reacción rápida.

El apoyo periódico puede bastar cuando la competencia es necesaria en momentos concretos, como una revisión, consulta, evaluación de riesgos o aceptación especializada.

Hay una condición: la disponibilidad debe ser real, no nominal. Debe estar claro:

• quién es responsable,
• cuándo está disponible,
• qué tiempo de respuesta se espera,
• qué decisiones puede tomar,
• qué ocurre si detecta un problema.

Tener acceso teórico a un especialista sin responsabilidad definida puede verse bien en un organigrama y fallar en un proyecto real.

Supongamos que el objetivo es lanzar un sistema de reservas en línea.

Variante A: prototipo sencillo para probar la idea
El alcance es limitado, no hay pagos ni datos especialmente sensibles y el objetivo es probar el proceso con un pequeño grupo de usuarios. Una persona versátil podría cubrir diseño y realización, con apoyo puntual cuando sea necesario.

Variante B: servicio público con cuentas, pagos e integraciones
Aparecen más especialización, pruebas, riesgos, dependencias y trabajo paralelo. Un equipo de varias personas resulta mucho más justificable.

Variante C: servicio que funciona de forma continua y requiere respuesta rápida a problemas
A la construcción se añaden operación, supervisión, respuesta a incidentes y continuidad del conocimiento. La composición necesaria para lanzar puede no bastar para operar de forma sostenible.

Es el mismo tipo general de producto, pero un alcance, un riesgo y un modelo operativo diferentes generan necesidades de equipo diferentes.

1. Empiezas por una lista preparada de puestos en vez del trabajo que hay que realizar.

2. Supones que cada función necesita una persona distinta.

3. Miras solo las competencias e ignoras el tiempo disponible.

4. Añades personas sin eliminar dependencias y cuellos de botella.

5. Ignoras competencias impulsadas por el riesgo porque no crean una función visible.

6. Haces depender varias áreas críticas de una sola persona sin aceptar conscientemente el riesgo.

7. Tratas la composición inicial como fija hasta el final del proyecto.

GOV.UK señala expresamente que el tamaño y las funciones del equipo cambian durante las fases de desarrollo de un servicio. [2]

Es una regla razonable también fuera de los servicios públicos:

• al principio puede hacer falta más investigación y definición del problema,
• durante la realización ganan peso las competencias de producción y prueba,
• antes del lanzamiento pueden aumentar las necesidades de seguridad, calidad y preparación operativa,
• después del lanzamiento cambia el equilibrio entre evolución y operación.

La composición mínima depende de la fase y el alcance, no es una cifra fija asignada al proyecto para siempre.

Para cada área importante, anota cinco cosas:

Área de trabajo - ¿qué debe hacerse?
Competencia - ¿qué conocimiento y habilidad se necesitan?
Responsabilidad - ¿quién decide y responde por el resultado?
Disponibilidad - ¿la competencia es permanente, periódica o externa?
Riesgo de ausencia - ¿qué ocurre si falta la competencia o la persona no está disponible?

Solo después asigna personas concretas.

Si una persona cubre varias filas, revisa su tiempo y sus dependencias. Si una fila necesita varias personas, comprueba si el motivo es capacidad, control independiente o trabajo paralelo.

1. ¿Todas las áreas de trabajo obligatorias tienen responsable?
2. ¿Cada responsabilidad crítica tiene una persona con la competencia adecuada?
3. ¿Alguien cubre varias funciones y dispone realmente de tiempo suficiente?
4. ¿El proyecto exige trabajo paralelo que la composición actual no puede sostener?
5. ¿Conocemos las principales dependencias de otras personas, equipos y proveedores?
6. ¿Los riesgos importantes tienen acceso al conocimiento especializado adecuado?
7. ¿La ausencia de una persona puede detener todo el proyecto?
8. ¿La composición basta no solo para construir, sino también para lanzar y operar la solución si eso forma parte del alcance?
9. ¿Sabemos qué competencias pueden ser periódicas en lugar de permanentes?
10. ¿Hemos definido momentos para volver a evaluar la composición tras cambios de alcance o fase?

El diseño del equipo no debería comenzar con:

"¿cuántas personas suelen necesitar proyectos como este?"

Un orden mejor es:

resultado -> trabajo -> competencias -> dependencias -> riesgo -> capacidad -> personas.

Si una persona cubre realmente todo después de recorrer esta secuencia, una persona puede ser la opción correcta.

Si faltan competencias, tiempo, revisión independiente, continuidad o capacidad de trabajo paralelo, necesitas más personas o acceso fiable a especialistas.

El objetivo no es el equipo más pequeño. El objetivo es la composición más pequeña capaz de entregar de forma realista el resultado requerido con el nivel de riesgo y calidad exigido.

[1] GOV.UK Service Standard - Have a multidisciplinary team
Abrir fuente

[2] GOV.UK Service Manual - Set up a service team at each phase
Abrir fuente

[3] The Scrum Guide, 2020 - Scrum Team
Abrir fuente

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
Abrir fuente

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
Abrir fuente

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
Abrir fuente

[7] Project Management Institute - Solving The Resource Puzzle
Abrir fuente

[8] GOV.UK Service Manual - Running more than one service team
Abrir fuente

Nota metodológica: algunas fuentes tratan de servicios públicos digitales, otras de equipos Scrum, gestión de proyectos o investigación sobre equipos y desarrollo de software. Esta guía utiliza cada fuente solo para los puntos que realmente respalda. El método de siete pasos es una síntesis editorial de esos principios, no una norma formal de las organizaciones citadas.