5 reglas que he visto funcionar en los equipos de proyecto que aguantan

Hace más de quince años tuve un PM que llevaba una hoja de Excel con los minutos que cada uno de nosotros pasaba en el baño. No es broma. Una hoja compartida, actualizada a mano, con columnas para fecha, persona, hora de salida, hora de vuelta, duración. La enseñaba en la reunión semanal de estado como comentario al avance del proyecto, como si los minutos lejos del escritorio explicaran algo de los retrasos.

El resultado era previsible. Por la mañana el equipo llegaba en silencio, los pasos en el pasillo se hacían rápidos y furtivos, la gente se escalonaba las visitas al baño para no coincidir con algún compañero. Dos personas dimitieron en seis meses. El proyecto se entregó — salvo que en los meses siguientes la mitad del equipo era rotativa y cada nueva incorporación tenía que formarse desde cero.

No cuento esta historia para moralizar. La cuento porque es útil contrastarla con otra, más reciente. Un PM en un proyecto de consolidación del data warehouse de un banco comercial italiano que, cuando llegaban correos de escalation en cascada desde los pisos altos, los leía él mismo, los traducía en una única pregunta técnica para nosotros y nos ahorraba el torbellino. A fin de año aquel equipo había producido el doble de trabajo con la mitad de reuniones.

Las reglas que voy a recopilar aquí no son mi decálogo como PM iluminado. Son patrones que he visto repetirse en treinta años de proyectos — primero sentado al otro lado de la mesa como consultor, después con el sombrero del responsable. Son cinco, son simples, y cuando están en su sitio marcan la diferencia entre un equipo que aguanta bajo presión y un equipo que se desmorona en la primera curva.

1️⃣ Dale a las personas permiso para decir “no lo sé” #

En un equipo, el silencio casi nunca es concentración. Es miedo a equivocarse. Miedo a que decir “no lo sé” equivalga a declarar que no se está a la altura del rol, del sueldo, de las expectativas. Y así las personas fingen. Aceptan tareas que no saben cómo afrontar, pasan días sin preguntar, y la cuestión aflora cuando ya no queda margen para resolverla.

En un proyecto para un operador telco móvil, hace algunos años, un senior developer llevaba tres semanas bloqueado en el bugfixing de un package PL/SQL complejo — cursores anidados, triggers que llamaban a otros triggers, transacciones autónomas, y alguna llamada a dbms_aq puesta ahí sin un comentario — escrito por un consultor que se había ido meses antes. Reuniones de estado, correos de stakeholders, replanificaciones — y nadie sabía que el bloqueo estaba ahí. Hasta que un nuevo PM, incorporado con el proyecto en marcha, abrió la retro con una pregunta directa: "¿Quién tiene algo en lo que está bloqueado y no consigue desbloquear?". El senior levantó la mano, dijo “este package ya no consigo seguir su flujo, me está volviendo loco”. Un compañero de otro equipo, presente en la sala por casualidad, dijo “ven, un package con la misma estructura lo refactoricé para otro cliente el año pasado, te lo enseño en media hora”. Cuarenta y cinco minutos después el bloqueo estaba resuelto.

Tres semanas frente a cuarenta y cinco minutos. La diferencia no era la competencia técnica: el conocimiento estaba ahí, dentro de la empresa, a dos habitaciones de distancia. La diferencia era la posibilidad de admitir que no se sabía. Cuando falta ese permiso, el equipo paga el precio del farol. Cuando está, la información circula y los bloqueos duran minutos en vez de semanas.

El término técnico es Psychological Safety . No significa un clima blandengue donde nadie critica nunca: significa un clima donde se puede admitir no saber sin consecuencias sobre la valoración profesional. Es el prerrequisito de todo lo demás.

2️⃣ Protege al equipo del ruido #

El PM no tiene que ser un multiplicador de reuniones. Tiene que ser un filtro. En cualquier proyecto de cierta dimensión hay un flujo continuo de peticiones que llegan desde fuera del equipo: stakeholders que piden estado actualizado cada día, directores que quieren “un repaso rápido” cada mañana, vendors que mandan correos de escalation a media empresa, comerciales que piden slides para una reunión “a preparar para mañana”.

Si todo esto llega directamente al equipo, el equipo no trabaja. Trabaja para responder al micromanagement externo, que es el mismo mecanismo del PM que cronometra los minutos de baño, solo delegado en stakeholders variados.

En el proyecto del DWH del banco que he citado al principio, el PM había encontrado un equilibrio casi artesanal: las peticiones de estado sobre los tiempos de carga nocturna, los impactos en el modelo de cada nueva dimensión a añadir, las extracciones ad hoc para el control de gestión — las interceptaba él, las contestaba con un informe semanal en formato A4 que enviaba el lunes por la mañana a todos los interesados, y conseguía bloquear en origen el 90% de las peticiones puntuales. Al equipo le llegaba, filtrada, solo la pregunta técnica que requería realmente una profundización. Resultado: el equipo tenía ocho horas menos de reuniones a la semana. Ocho horas por persona, multiplicadas por siete personas, son más de un mes-persona de trabajo recuperado al mes.

Proteger no significa levantar un muro alrededor del equipo ni hacer el muro de goma. Significa distinguir el ruido de la señal — y la señal se reconoce porque aporta información nueva o decisiones reales, no porque venga etiquetada como “urgente”.

3️⃣ Pon a las personas donde rinden, no donde hacen falta #

El antipatrón es común: “hace falta alguien que haga X, cojo al del equipo que tiene más tiempo en el calendario”. Pero tener tiempo libre no convierte automáticamente a esa persona en la adecuada. Muchas veces alguien que “haría falta” en X es alguien que rendiría mucho más en Y, con X mejor cubierto por otra persona.

En un proyecto para un ente de la Administración Pública italiana, una compañera estaba asignada al soporte de segundo nivel sobre las bases de datos de producción — tickets sobre consultas lentas, lock contention, extracciones ad hoc para resolver directamente con usuarios finales fastidiados al teléfono. Técnicamente buena, preparada, y aun así sufría el contacto directo con quien al teléfono alzaba la voz; volvía a casa por la tarde vaciada. Su output era bueno pero nunca excelente. A los tres meses el responsable dio un paso atrás, miró las competencias reales y los intereses del equipo, y reasignó a aquella compañera a la modelización dimensional del data warehouse que estábamos construyendo en paralelo — donde resultó ser muy fuerte, diseñando fact tables y jerarquías de dimensiones que aguantaron a lo largo de los años sin grandes reestructuraciones. El soporte de segundo nivel lo cubrió un junior DBA que hasta ese momento estaba en los backups nocturnos: ese contacto directo con las consultas problemáticas le formaba, le hacía crecer, le hacía sentirse útil.

Resultado: dos personas que antes rendían al 60% ahora rendían al 100%, y el proyecto se benefició sin haber contratado a nadie. La regla no es “reasigna a todo el mundo”, es más sutil: haz balance cada algunos meses, habla con las personas, observa dónde gastan energía y dónde la ganan. Un buen PM redistribuye en base a la observación, no etiqueta en base al organigrama inicial.

4️⃣ Haz circular el conocimiento, no las personas #

La primera pregunta que un PM debería hacerse es: “Si mañana el equipo perdiera a una persona, ¿cuánto se pararía el proyecto?”. La respuesta — cuantificada en días, no en palabras tranquilizadoras — se llama bus factor . Un bus factor de 1 significa que el conocimiento crítico está en una sola cabeza, y esa cabeza puede enfermar, irse de vacaciones o cambiar de empresa. Un bus factor de 3 significa que el mismo conocimiento está distribuido en al menos tres personas del equipo.

Las herramientas para subir el bus factor son simples y conocidas — documentación mínima y siempre actualizada, pair working sobre las actividades críticas, rotación periódica de las responsabilidades — y las tres requieren que el PM ponga tiempo de calendario, no solo un correo de ánimo.

En un proyecto en un operador postal y logístico nacional con unas 1500 instancias MySQL y PostgreSQL en producción, la presión operativa era altísima: cuando un DBA estaba de vacaciones, el equipo restante sufría porque un trozo de conocimiento específico faltaba. Introdujimos un ritual muy sencillo: cada martes a las 14:30, un knowledge transfer de 30 minutos sobre un tema específico (configuración de un nodo Galera, procedimiento de recovery desde binary log, troubleshooting de un lock wait en PostgreSQL, tuning de shared_buffers tras un cambio de workload), impartido por turnos por un miembro del equipo. Sesiones grabadas, indexadas en un wiki interno, buscables.

Seis meses después, cuando un DBA se fue tres meses de paternidad, el compañero que lo sustituía ya estaba operativo desde el primer día — nunca había tocado personalmente esos sistemas; había asistido o visto grabadas las KT sobre los procedimientos críticos. El ritual no es “de vez en cuando hacemos un poco de formación”. El ritual es media hora bloqueada en agenda, cada semana, que produce un activo del equipo compartido. Es una de las cosas con mejor relación coste-beneficio que he visto aplicar en un proyecto.

5️⃣ Reconoce el trabajo, no solo los resultados #

Los resultados de un proyecto dependen de variables que muchas veces el equipo no controla: decisiones del cliente, cambios de alcance, retrasos de vendors, restricciones normativas que llegan a mitad del recorrido. El trabajo, en cambio, está bajo el control del equipo. El trabajo es lo que se ha puesto en la jornada: horas de análisis, horas de código, horas de discusión, horas de test.

Si un PM reconoce solo los resultados, cuando los resultados se retrasan por causas externas las personas se desmotivan. Han trabajado bien, en algunos casos incluso mucho, y oyen decir “igualmente el go-live se ha caído”. La próxima vez trabajarán menos, porque han aprendido que su esfuerzo no cuenta si el outcome externo no llega. El término técnico es la distinción entre outcome y output : el output es lo que el equipo ha producido, el outcome es el resultado final medido por el negocio.

En un proyecto de data warehouse del sector asegurador multi-país, el equipo había completado el desarrollo de un nuevo data mart para el análisis de las comisiones pagadas a los intermediarios — modelización dimensional, procesos ETL de carga nocturna, reconciliación con la contabilidad de grupo — respetando tiempos y calidad esperados. Luego, por decisiones de negocio que afectaban al realineamiento de otra área del data warehouse, el go-live se retrasó tres meses y el nuevo data mart quedó en espera. La responsable de proyecto convocó al equipo en una reunión de quince minutos y dijo con mucha precisión: “Habéis entregado lo que teníais que entregar, en los tiempos y con la calidad que habíamos acordado. El go-live depende de factores que no están en vuestras manos. Gracias por el trabajo.”. Luego enumeró, uno a uno, los trozos de trabajo más difíciles que el equipo había afrontado en los meses anteriores — tres o cuatro frases, específicas, concretas.

Parecerá poco. Fue muchísimo. Aquel equipo mantuvo el ritmo también durante los tres meses de espera, y cuando el go-live arrancó arrancó bien. La regla no es “repartir medallas”. La regla es distinguir lo que el equipo ha hecho bien (output) de lo que el negocio ha decidido (outcome), y reconocer explícitamente lo primero cuando lo segundo no llega.

🧭 El PM como custodio de las condiciones #

Un verano de hace muchos años, en Roma, con uno de esos bochornos que te clavan al asfalto, decidí ir a la oficina en bermudas. Sabía perfectamente que no era la vestimenta más adecuada para un contexto profesional; el calor estaba realmente fuera de escala. Nada más llegar, en el pasillo, me crucé con el manager. Me miró de arriba abajo y, sonriendo, me dijo: "¿Hoy nos vamos a la playa?". Y yo, por instinto, me golpeé el índice en la sien y respondí: "¿Me pagas por cómo visto o por lo que hay aquí dentro?". Soltó una carcajada, me dio una palmada en el hombro, y siguió recto hacia su despacho. Desde aquel día seguimos teniendo una excelente relación profesional, aunque luego los caminos nos han llevado en direcciones distintas.

Aquella palmada en el hombro es una imagen que se me ha quedado pegada. En otro contexto — el de la hoja de Excel de los minutos de baño — la misma escena habría terminado en un aviso formal a RR.HH. y en una anotación en la evaluación anual. El manager que aquella mañana eligió reír había entendido una cosa simple: el valor de una persona en un proyecto no está en las bermudas ni en el traje, está en las ideas que produce y en el trabajo que pone a circular. Esa elección — reír en lugar de sancionar — es exactamente el oficio del custodio de las condiciones.

Estas cinco reglas no son un decálogo de PM que manda. Son observaciones sobre lo que pasa cuando ciertas condiciones están y cuando faltan. Bajo cada una hay un hilo común: el PM no es el general que guía a las tropas, es más bien un custodio de las condiciones. Su trabajo es hacer que cada persona del equipo tenga el permiso, el espacio y las herramientas para hacer bien su trabajo.

El éxito de un proyecto es del equipo que lo ha producido, no del PM. Y la responsabilidad de los fracasos es del PM más que del equipo, porque las condiciones estaban bajo su control. Esta inversión — que a algunos les suena contraintuitiva — es la parte que marca la diferencia. Cuando un equipo siente que quien lo guía asume la responsabilidad por las condiciones y no se atribuye el mérito por los éxitos, aguanta mejor bajo presión, finge menos, se ayuda más.

Cada miembro del equipo contribuye al éxito común con su parte: técnica, relacional, organizativa, de conocimiento del dominio. El PM contribuye con las condiciones. Si faltan las condiciones, la contribución de todos se desmorona; si están, el equipo aguanta. Las cinco reglas de arriba — todas — son formas concretas de poner en pie esas condiciones y mantenerlas en el tiempo.

Y no, no se lleva una hoja de Excel con los minutos de baño. Eso es el opuesto exacto del trabajo de un PM. Es la señal de que no se ha entendido el oficio.

Glosario #

Psychological Safety — Clima de equipo en el que las personas se sienten libres de admitir errores, decir “no lo sé” y plantear problemas sin temer consecuencias sobre la valoración profesional. No significa clima blandengue sin críticas, sino seguridad profesional a la hora de decir la verdad técnica.

Bus Factor — Número de personas del equipo que, si faltaran a la vez, bloquearían el proyecto. Un bus factor de 1 es un riesgo crítico: el conocimiento está concentrado en una sola cabeza. Objetivo: mantener el bus factor ≥ 3 en las competencias críticas.

Micromanagement — Estilo de gestión basado en el control puntual de las actividades diarias del equipo, a menudo acompañado de peticiones continuas de estado y medición del tiempo empleado en operaciones individuales. Genera caída de motivación, turnover y desincentiva la iniciativa.

Outcome vs Output — Distinción entre lo que el equipo produce concretamente (output: código, documentos, deliverable) y el resultado final medido por el negocio (outcome: go-live, facturación, KPI). El output está bajo el control del equipo; el outcome también depende de variables externas.

Knowledge Transfer — Proceso estructurado de transferencia de conocimiento entre personas o equipos, crítico para subir el bus factor y reducir dependencias de personas individuales. Puede ser síncrono (sesiones de pairing) o asíncrono (documentación, vídeos grabados).