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).
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
De acuerdo con todo lo comentado en la entrada, pero creo que habría que hacer un post (si no lo has hecho ya) de lo que conlleva llevar esto al extremo, que es el aparcar a alguien de por vida en un «proyecto» sin ningún tipo de atención hacia él (formación, nuevos entornos, no acomodarse, renovarse, motivarse con nuevos «retos», …), con la excusa de tener un equipo o servicio estable. En nuestro profesión, para mucha es un problema su estancamiento. Creo que hay que encontrar un equilibrio entre equipos estables y personal rotando y cambiando de equipos y entornos, que es muy enriquecedor
Totalmente de acuerdo con David, es necesario un equilibrio. Es sano para la persona moverse, algunas veces dentro de la misma organización si es posible o bien a otras nuevas. De hecho, no todas las personas son iguales y tienen los mismos gustos, algunos de nosotros nos puede gustar mas tener un conocimiento completo de nuestro sistema y ser un experto y a otros nos gusta estar en constante movimiento, productos o tecnologías.
Si consigues encontrar un equipo donde ese equilibrio viene definido por las propias personas, algunos que quieren la estabilidad y la seguridad de conocer los sistemas donde trabaja y otros con savia nueva cuestionando lo que ven a su paso para mejorar, ese equipo será muy productivo, igual no el que más pero lo suficiente y con un proceso en constante evaluación.
En ecología hay una hipótesis denominada ‘de la perturbación intermedia’, que hace referencia al hecho de que la máxima biodiversidad no se alcanza en un sistema maduro y totalmente desarrollado, sino que se da en sistemas maduros que sufren cierto grado de ‘perturbación’. Piensa en un bosque totalmente desarrollado y estable, sólo crecen árboles y el poco sotobosque adaptado a vivir con esos árboles, si, por ejemplo, se clarea (con un pequeño incendio, que también los hay naturales) en ese claro surgen otras especies que no podrían vivir con el bosque maduro. Una alta biodiversidad hace que ese ecosistema sea más adaptable/resistente a los cambios, a costa de no estar en su máximo de productividad.
Cuento todo esto porque un equipo ya consolidado y ‘maduro’, corre el riesgo de perder capacidad de adaptación (a nuevos requisitos, a mantener o adoptar tecnologías punteras…). Un cierto nivel de rotación, ‘sangre fresca’ de vez en cuando, enriquece los equipos y fuerza a tener que explicar los sistemas a otra gente, lo cual siempre es bueno. Y los nuevos, al no conocer el sistema, seguramente propongan soluciones, erróneas muchas veces, pero ‘diferentes’ que pueden hacer que el sistema evolucione más que si la solución la desarrolla alguien que ya sabe cómo funciona todo y hará ‘lo de siempre’ (lo cual no tiene por qué ser malo).
El truco está, como todo, en buscar un punto de equilibrio. Ni es bueno una rotación elevada, ni es bueno en un proyecto tener siempre a los mismos durante mucho tiempo. Obviamente también depende de los proyectos y los objetivos que se quieran alcanzar.
Bonita metáfora
Comparto los comentarios anteriormente expuestos por los compañeros.
Pensando en las «personas» (y su crecimiento vertical u horizontal) y en la salud del «equipo» (pensamiento paralelo) es necesario que exista un cierto nivel de rotación controlado y adecuado en cada situación.
También se nota que estamos en una profesión «relativamente joven», pero no nos olvidemos que la vida laboral de una persona tiene fecha de caducidad (antes o después y dependiendo de muchos factores…) y eso es/será inevitable hasta para el mejor y más eficiente equipo del mundo.
Un saludo!!