¿Es bueno tener equipos estables? (vamos, que no rote constantemente la gente)

Yo creí que esto era un tema tan obvio que no merecía un post, pero no, nada de nada. Así que dediquémosle unas entrañables líneas a la obviedad (que es hasta un patrón) de… “¿Es mejor tener equipos estables?” Y volviendo a las aclaraciones obvias, por “estables”, quien lo pregunta te está preguntando sobre si es malo que en un proyecto entre y salga gente constantemente. Y si te vas al lado oscuro, bueno a la consultoría oscura, puede que la pregunta esconda algo así como… “Voy a sacar perfiles caros, digo seniors, y meter otros más baratos, digo juniors… ¿afectará mucho?”.

Quien dice que no pasa nada por mover gente dentro de un equipo, suele caer en la idea de confundir “personas” con “recursos humanos”. Un “recurso humano” es sólo “pasta” y horas, pero una “persona” es, además, relaciones con otras, conocimiento, motivación, desmotivación, experiencia, etc. Por eso, mejor piensa en “personas” y no en “recursos humanos”.

Si solo ves “recursos humanos” pues, probablemente, y teóricamente, te cuadre lo de cambiar “recursos” de un equipo a otro, por motivos de facturación, crisis, apagar fuegos, etc. Pero si piensas que en los proyectos hay “personas”, empezarás a ver que las siguientes, y casi centenarias, ideas, tienen más sentido del que pensabas:

– Ley de Brooks. O aquello de que “añadir gente a un proyecto software con retraso hace que se retrase más”, algunos detalles y revisiones, ya que añadir más recurso incrementa los canales de comunicación, tiene el coste de la fase de aprendizaje, etc.

– El ciclo de Tuckman, que vimos en ¿Las disputas y discusiones son una constante en tu equipo – entorno de trabajo? No te preocupes, no estás solo y que venía a decir que un equipo necesita un tiempo para ser eficiente, que no es automático, que los equipos nuevos empiezan no muy bien y pasado el tiempo trabajan muy bien.

– Que cuando uno olvida todo esto ve con buenos ojos la multitarea, es decir, tener a personas distribuidas en varios equipos y proyectos, olvidando que trabajar en más de un proyecto a la vez genera pérdidas de tiempo y disminuye la productividad.

Por lo tanto, la próxima vez que alguien te plantee esto, más si vas a “subcontratar” un desarrollo, es que ni te lo plantees: los equipos deben ser estables. Obvia cualquier justificación contraria a esto, si bien hay una justificación hipnotizante sobre la que debes estar más alerta que sobre cualquier otra: “si lo hacemos así el proyecto saldrá más económico”.

Económico, palabra cautivadora. Pero recuerda, lo barato… muchas veces sale caro.

Los miembros de los equipos estables se conocen, conocen su estilo de trabajo, se forman juntos. Por ello, ten en cuenta, que sin equipos estables, raro es que conozcas la capacidad de trabajo del equipo, llámalo velocidad (mírate eso de ¿Qué es la velocidad en un proyecto software (normalmente ágil o Scrum)? Aclaración de dudas frecuentes) si estás siguiendo un proceso ágil, lo que difícil tener previsibilidad sobre cómo y cuándo acabará el proyecto. Y ten en cuenta que puede que se termine el desarrollo, pero que lo que te ahorraste te lo gastes multiplicado en el mantenimiento (supuesto mantenimiento, por no llamarle terminar las cosas).