Gestión de las personas: equipos, carga, Tuckman y ley de Brooks
El software lo construyen personas. Un plan excelente fracasa si el equipo está saturado, desmotivado, mal compuesto o con miedo a decir que algo va mal. Esta lección trata de cómo gestionar capacidad y relaciones, no sólo asignar tareas.
- Enumerar lo que debe gestionar un responsable de proyecto sobre las personas: capacidad, competencias, coordinación, motivación, comunicación y desarrollo.
- Usar las orientaciones (tarea, interacción, sí mismo) para componer equipos y detectar desequilibrios.
- Calcular la capacidad real de un equipo y elegir un enfoque para gestionar la carga (horas, capacidad por iteración, WIP, carga visible).
- Explicar Tuckman, el bus factor, la ley de Brooks y la seguridad psicológica, y tratar los problemas de personal como riesgos.
Tema 2, diap. 67-78, y Tema 1, diap. 65-66. Objetivo del tema: "entender el papel de las personas en el desarrollo de un proyecto y ser capaz de gestionarlas". Se presta a preguntas de escenario: "el equipo va tarde, ¿añadimos gente?", "una persona sabe todo del módulo X, ¿qué riesgo hay?", "¿qué enfoque de carga usarías?". Ampliación: ley de Brooks (las diapositivas hablan de que "el rendimiento no es la suma" sin nombrarla), Edmondson, Belbin, canales de comunicación.
1. Las personas son la clave del proyecto
Dos afirmaciones fuertes de las diapositivas:Tema 2, diap. 69; Tema 1, diap. 65-66.
- El software lo construyen personas. Incluso los generadores de código (como la IA) siguen controlados por personas, que deciden si aceptan o no el código generado. La responsabilidad sigue siendo humana.
- La planificación puede ser excelente y el proyecto fracasar por problemas de personas, "y esto sucede muchas veces". El Tema 1 lo resume: "el factor humano es el principal determinante del éxito o fracaso", y cierra con: "Gestionar personas no es un soft skill menor, es el verdadero núcleo de la ingeniería de software. La técnica resuelve problemas, pero las personas los crean y los solucionan".
Las limitaciones reales del personal
Puede ser imposible reclutar a las personas ideales: el presupuesto no permite pagar salarios de personal experimentado, las personas con la experiencia necesaria no están disponibles, o la organización prefiere formar a sus empleados. El responsable tiene que trabajar con estas limitaciones, especialmente cuando escasea el personal capacitado.Tema 2, diap. 68. Es decir: los recursos humanos son una restricción (lección 1), y la curva de aprendizaje de quien se forma debe entrar en la estimación.
Qué debe gestionar el responsable
La gestión de personas no es sólo asignar tareas. Son seis dimensiones:Tema 2, diap. 70.
| Dimensión | Pregunta |
|---|---|
| Capacidad | ¿Cuánto trabajo puede asumir cada persona? |
| Competencias | ¿Qué conocimientos necesita cada tarea? |
| Coordinación | ¿Quién necesita colaborar con quién? |
| Motivación | ¿Qué favorece compromiso, autonomía y responsabilidad? |
| Comunicación | ¿Qué información necesita cada persona y cuándo? |
| Desarrollo | ¿Cómo evoluciona el equipo durante el proyecto? |
Y una frase que define el estilo de liderazgo que defiende el temario: la persona responsable del proyecto debe entender que está al servicio del equipo, no al contrario. Es la idea de liderazgo de servicio (servant leadership), que en Scrum encarna el Scrum Master: quitar obstáculos, proteger al equipo, facilitar.
2. Conocer al equipo: orientaciones y perfiles
Conocer al equipo es el primer paso. Las diapositivas usan tres orientaciones (Bass y Dunteman, recogidas por Sommerville):Tema 2, diap. 71-72. Ampliación: Sommerville, 10ª ed., cap. 22 "Project management", apartado "Teamwork".
| Orientación a tareas | Orientación a interacción | Orientación a sí mismo |
|---|---|---|
| Se centra en conseguir resultados | Se centra en las relaciones | Se centra en necesidades y reconocimiento propios |
| Planificación, precisión, resolución de problemas, cumplimiento | Comunicación, coordinación, cohesión, mediación | Autonomía, influencia, reconocimiento, objetivos personales |
No son tipos excluyentes: una misma persona muestra distintos grados de las tres. "Orientación a sí mismo" no es un defecto: alguien motivado por el reconocimiento y la autonomía puede rendir muchísimo si su trabajo le permite destacar.
¿Para qué sirve conocer los perfiles?
- Evitar equipos homogéneos: la diversidad de orientaciones siempre es útil.
- Asignar responsabilidades según las necesidades de la tarea y del equipo (quien está orientado a interacción, para hablar con el ayuntamiento; quien está orientado a tareas, para el módulo crítico con fecha).
- Detectar desequilibrios: mucha orientación a tareas puede descuidar la coordinación; mucha orientación a interacción puede ralentizar decisiones.
- Gestionar expectativas: motivadores diferentes requieren formas diferentes de reconocimiento.
- Observar conductas, no "encasillar" personas.
El Tema 1 menciona también otros modelos: MBTI, DISC, Belbin, con perfiles como analíticos (detalle y calidad), creativos (innovación), ejecutores (cumplimiento y organización) y comunicadores (stakeholders).Tema 1, diap. 66. Ampliación: Belbin, M. (1981), Management Teams; nueve roles de equipo. Úsalos como lenguaje para hablar de diferencias, no como diagnóstico: el MBTI en particular tiene poca validez científica como predictor del rendimiento. La conclusión de las diapositivas vale para todos: la diversidad de perfiles es una fortaleza, pero requiere que cada uno entienda y respete las diferencias del otro.
3. Dinámica de equipos: el modelo de Tuckman
Bruce Tuckman (1965) observó que los grupos pasan por fases; en 1977 añadió la quinta:Tema 1, diap. 65. Tuckman, B. (1965), "Developmental sequence in small groups"; Tuckman y Jensen (1977). Ver Tuckman's stages.
| Fase | Qué pasa | Qué hace el líder |
|---|---|---|
| Formación (forming) | El grupo se conoce; cortesía, dependencia del líder, poca claridad de roles | Dirigir: objetivos claros, roles, normas iniciales |
| Conflicto (storming) | Surgen desacuerdos sobre cómo trabajar, quién decide, prioridades | Facilitar el conflicto (no suprimirlo), mediar sobre hechos |
| Normalización (norming) | Se acuerdan normas, roles y formas de trabajo; aparece la cohesión | Apoyar, delegar más |
| Desempeño (performing) | Equipo autónomo y eficaz; resuelve sus propios problemas | Delegar, proteger, quitar obstáculos |
| Disolución (adjourning) | El proyecto termina; el equipo se separa | Cerrar bien: reconocer, lecciones aprendidas (lección 11) |
Nota sobre las diapositivas: el Tema 1 escribe "formación, inboarding, normalización, desempeño y disolución". La segunda fase del modelo de Tuckman es storming (conflicto, "tormenta"); "inboarding" parece una errata. Para el examen, la secuencia es formación → conflicto → normalización → desempeño → disolución.
Consecuencias para la gestión:
- Un equipo nuevo no rinde al máximo desde el primer día: hay que contarlo en la estimación.
- Cambiar la composición del equipo (entra o sale alguien) puede devolverlo a fases anteriores. Por eso los equipos estables son más productivos, y por eso la "velocidad" pasada no es capacidad futura si el equipo cambia.
- El conflicto de la fase storming es normal y necesario; suprimirlo lo retrasa.
Conflictos
Las diapositivas distinguen:Tema 1, diap. 65.
- Conflictos de visión o de tarea (sobre ideas: ¿Flutter o nativo?): pueden ser creativos si se gestionan bien. Un equipo sin desacuerdos técnicos probablemente no está pensando.
- Conflictos personales o relacionales: destructivos, hay que abordarlos con prontitud.
- El líder actúa como facilitador, no como juez, y aborda los conflictos sobre hechos, necesidades y objetivos del proyecto (no sobre personas).Tema 2, diap. 77.
Y dos ideas más del Tema 1: los equipos cohesionados y con confianza mutua son más productivos que la suma de individualidades, y la diversidad cognitiva mejora la resolución de problemas, pero requiere tiempo de adaptación.
4. Gestionar la carga de trabajo
La regla central: capacidad disponible ≠ horas laborales totales. Hay que descontar reuniones, coordinación, soporte, formación, investigación, incidencias y otras obligaciones. E incluso con eso, hay que evitar asignar el 100 % de la capacidad: hay que dejar margen para imprevistos.Tema 2, diap. 73.
¿Por qué no al 100 %? Además de los imprevistos, hay una razón matemática (teoría de colas, ampliación): cuando un recurso está ocupado cerca del 100 %, los tiempos de espera crecen de forma explosiva. Cualquier tarea nueva o urgente hace cola, y todo lo que dependa de esa persona se para. Un equipo al 100 % no es eficiente: es un atasco.
Además: repartir el trabajo según capacidad, competencias y dependencias, y revisar la carga durante el proyecto, porque la asignación inicial deja de ser válida.
Formas de gestionar y equilibrar la carga
No existe una única técnica: depende del ciclo de vida, del equipo y del tipo de trabajo.Tema 2, diap. 74.
| Enfoque | Cómo funciona | Riesgo / precauciones | Encaja con |
|---|---|---|---|
| Asignación por horas | Distribuir el esfuerzo estimado según capacidad | Las horas estimadas pueden ser inciertas | Predictivo, EDT + Gantt |
| Capacidad por iteración | Seleccionar trabajo hasta la capacidad del equipo | No confundir velocidad con capacidad futura | Scrum |
| WIP limitado | Limitar las tareas simultáneas por persona/equipo | Puede requerir priorizar o esperar | Kanban, soporte, flujo continuo |
| Carga visible | Tablero, calendario o dashboard para detectar saturación | La herramienta no sustituye la conversación | Cualquiera |
El WIP (Work In Progress, trabajo en curso) merece una explicación: tener muchas tareas a la vez parece productivo, pero cada cambio de contexto cuesta, y todo avanza lento a la vez en vez de terminarse. Limitar el WIP obliga a terminar antes de empezar. La ley de Little (ampliación) lo formaliza: tiempo medio de entrega = trabajo en curso / ritmo de salida. Con el mismo ritmo, menos WIP = entregas más rápidas.
5. Problemas habituales: también son riesgos
Los problemas de personal son también riesgos, y deben estar en el registro de riesgos (lecciones 12-13):Tema 2, diap. 75.
- Falta de personas o perfiles críticos.
- Rotación, bajas o pérdida de conocimiento.
- Sobreasignación y multitarea excesiva.
- Dependencia de una única persona ("bus factor" bajo).
- Conflictos, mala comunicación o falta de coordinación.
- Falta de competencias o curva de aprendizaje mayor de la prevista.
- Desmotivación, agotamiento (burnout) o sensación de falta de autonomía.
- Distribución desigual del trabajo o responsabilidades poco claras.
El bus factor
El bus factor (o truck factor) es el número mínimo de personas que tendrían que desaparecer (por un autobús, o, menos dramático, por un cambio de trabajo o una baja) para que el proyecto se bloquee por falta de conocimiento. Bus factor = 1 significa que una sola persona sabe algo crítico. Se sube con lo que las diapositivas llaman compartir conocimiento: revisión de código, pair programming, documentación y rotación.
El papel del responsable
Siete verbos:Tema 2, diap. 76.
- Prever: identificar perfiles críticos, dependencias y riesgos de personal.
- Visualizar: hacer visibles carga, bloqueos, WIP y responsabilidades.
- Priorizar: reducir trabajo simultáneo antes que saturar al equipo.
- Redistribuir: mover tareas, incorporar apoyo o cambiar prioridades.
- Compartir conocimiento: revisión de código, pair programming, documentación y rotación.
- Comunicar pronto: una sobrecarga detectada tarde suele convertirse en retraso.
- Escalar cuando sea necesario: recursos, calendario, alcance o expectativas.
6. La ley de Brooks
"Añadir personal a un proyecto de software retrasado lo retrasa más." Fred Brooks, 1975, tras dirigir el desarrollo del sistema operativo OS/360 de IBM.Ampliación. Brooks, F. (1975), The Mythical Man-Month. Ver Brooks's law. Las diapositivas recogen la idea de fondo: el rendimiento de un equipo no es la suma simple de rendimientos individuales y la composición del equipo importa tanto como el número de personas. Tres razones:
- Incorporación (ramp-up): la persona nueva tarda semanas en ser productiva, y mientras tanto consume tiempo de los veteranos que la forman, justo los que están en el camino crítico.
- Comunicación: los canales crecen como n(n − 1)/2 (lección 11). De 4 a 8 personas, de 6 a 28 canales.
- Divisibilidad: muchas tareas no se pueden repartir. "Nueve mujeres no pueden tener un bebé en un mes."
Matices importantes (Brooks mismo la llamó una "simplificación escandalosa"): añadir gente pronto, a tareas divisibles e independientes y con experiencia en el dominio sí puede ayudar. Lo que no funciona es añadirla tarde, a tareas acopladas, esperando un efecto inmediato. Conecta con el crashing de la lección 9: en software rinde poco. La alternativa preferida suele ser reducir alcance.
7. Motivación, liderazgo y comunicación
Seis claves de las diapositivas:Tema 2, diap. 77.
- Objetivos claros: cada persona sabe qué se espera y por qué.
- Autonomía: asignar responsabilidad sin microgestión (libertad sobre cómo cumplirla). El Tema 1 añade: los equipos autoorganizados y con autonomía toman mejores decisiones técnicas.
- Feedback frecuente: reconocer avances y corregir problemas pronto.
- Seguridad psicológica: poder comunicar errores, dudas y riesgos sin temor.
- Reconocimiento: valorar contribuciones técnicas y de coordinación (no sólo a quien "apaga fuegos").
- Conflictos: abordarlos sobre hechos, necesidades y objetivos del proyecto.
Seguridad psicológica
Concepto de Amy Edmondson (Harvard, 1999): la creencia compartida de que el equipo es un lugar seguro para asumir riesgos interpersonales: preguntar, admitir un error, discrepar, decir "esto no va a llegar".Ampliación. Edmondson, A. (1999), "Psychological Safety and Learning Behavior in Work Teams", Administrative Science Quarterly. Google, Project Aristotle: el factor más importante de la efectividad de sus equipos. En el estudio de Google sobre qué hace eficaces a sus equipos (Project Aristotle), fue el factor más importante, por encima de quién formaba el equipo.
Por qué es un tema de gestión de proyectos y no de "buen rollo": sin seguridad psicológica, los riesgos no se reportan (nadie quiere ser el propietario "culpable", lección 13), los informes salen en verde hasta el final (lección 11), las lecciones aprendidas buscan culpables y la gente oculta errores en vez de corregirlos pronto. Todo el sistema de control depende de que la información mala suba rápido.
Motivación y agotamiento
El Tema 1 insiste: la motivación y el clima laboral afectan directamente a la calidad del código y a la velocidad de entrega, y el agotamiento (burnout) en proyectos complejos es un riesgo real: hay que vigilar las cargas y celebrar logros. Las horas extra sostenidas no aceleran el proyecto: tras pocas semanas, la productividad cae y los defectos suben (más retrabajo). La comunicación debe equilibrar lo síncrono y lo asíncrono para evitar saturación (no todo merece una reunión).
Resumen
Las ideas finales de las diapositivas:Tema 2, diap. 78.
- Gestionar personas es gestionar capacidad y relaciones.
- El rendimiento de un equipo no es la suma simple de rendimientos individuales.
- La composición del equipo importa tanto como el número de personas.
- La carga debe gestionarse continuamente.
- Los problemas de personal deben tratarse como riesgos del proyecto.
- La IA y las herramientas de gestión pueden ayudar, pero no sustituyen experiencia, liderazgo, comunicación ni decisiones humanas.
- "Si vamos tarde, añadimos gente": ley de Brooks; tarde y en tareas acopladas, retrasa más.
- "Capacidad = horas de contrato": hay que descontar reuniones, soporte, incidencias… y dejar margen.
- "Lo eficiente es tener a todo el mundo al 100 %": un sistema al 100 % se atasca.
- "La orientación a sí mismo es negativa": es otra motivación; se gestiona con el reconocimiento adecuado.
- "Todo conflicto es malo": los de tarea pueden ser creativos; los relacionales son los destructivos.
- "El JP manda y el equipo ejecuta": el responsable está al servicio del equipo.
- "El orden de Tuckman es formación, normalización, conflicto…": es formación → conflicto → normalización → desempeño → disolución.
Práctica
Empareja cada comportamiento con la orientación predominante.
- Quiere un plan detallado y se centra en cumplir los plazos
- Media entre dos compañeros y organiza la coordinación con diseño
- Busca proyectos donde pueda destacar y decidir cómo trabajar
- Prefiere resolver los problemas hablando con el equipo
- Le preocupa la precisión de cada entrega por encima de todo
Ordena las fases de Tuckman: ¿qué número ocupa cada una?
- Formación (forming)
- Conflicto (storming)
- Normalización (norming)
- Desempeño (performing)
- Disolución (adjourning)
Sprint de 10 días, 5 personas, jornada de 8 h, todas al 100 % en el proyecto. Se estima que de cada 8 h, 6 son productivas (el resto, reuniones y soporte), y se reserva un 20 % de margen para imprevistos. ¿Cuántas horas se pueden planificar?
TusBus va 3 semanas tarde a 5 semanas de la feria. El concejal propone duplicar el equipo (de 4 a 8 personas) la semana que viene. ¿Qué respondes?
- Que tan tarde probablemente retrase más, y que conviene reducir alcance
- Que sí, porque con el doble de personas se hará el doble de trabajo
- Que sí, pero sólo si las nuevas personas trabajan también horas extra
- Que no, porque los equipos de más de cuatro personas nunca funcionan
Sólo Marta entiende el módulo de ingesta de datos GPS. ¿Qué acción del responsable ataca directamente este riesgo?
- Pedirle a Marta que trabaje más horas para terminar el módulo antes
- Asignar a Marta también el módulo de pagos porque es la más capaz
- Organizar pair programming y revisiones de código en ese módulo
- Esperar a que Marta avise si piensa dejar la empresa o coger una baja
Un equipo de soporte recibe peticiones continuas y cada persona tiene 7 tareas abiertas a la vez; nada se termina. ¿Qué enfoque de carga es el más adecuado?
- Asignación por horas con un Gantt detallado de las peticiones
- Limitar el trabajo en curso (WIP) por persona y por equipo
- Capacidad por iteración con sprints de cuatro semanas fijos
- Añadir más personas al equipo hasta que se terminen las tareas
¿Qué afirmaciones son coherentes con el temario sobre personas?
- Los problemas de personal deben estar en el registro de riesgos
- La IA puede sustituir las decisiones del responsable del equipo
- Una sobrecarga detectada tarde suele convertirse en retraso
- Hay que reducir el trabajo simultáneo antes que saturar al equipo
- Los conflictos sobre ideas técnicas deben evitarse siempre
En las reuniones de TusBus nadie menciona problemas, todos los informes están en verde y, a dos semanas de la entrega, aparecen de golpe tres bloqueos graves. ¿Qué factor de equipo probablemente falla y cómo lo abordarías como responsable?
Repaso espaciado · lecciones 1, 9, 15
Para acortar un proyecto, ¿sobre qué actividades tiene sentido aplicar crashing?
- Sobre las que tienen más holgura
- Sobre las del camino crítico
- Sobre las que son más baratas
- Sobre todas por igual
"¿Estamos construyendo el producto correcto?" es la pregunta de…
- La verificación
- El control de calidad
- La validación
- La planificación de calidad
Para profundizar
Brooks, F. (1975/1995), The Mythical Man-Month, cap. 2 (el ensayo que da nombre al libro; corto y legible). DeMarco y Lister (1987/2013), Peopleware, el clásico sobre personas en proyectos software. Sobre seguridad psicológica: Google re:Work · Understanding team effectiveness.
Aplica la lección a tu grupo de prácticas: ¿en qué fase de Tuckman estáis? ¿cuál es vuestro bus factor? ¿qué orientación predomina? Coméntalo con tus compañeros: es el mejor ejercicio de "sabiduría" para este tema. Si te queda duda sobre la errata "inboarding" de la diapositiva, confírmalo en tutoría.