Vamos a realizar reflexiones al respecto de cosas que al parecer son obvias pero que a veces nos abruman con argumentos que terminamos olvidando. 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”. Un “recurso” es sólo “dinero visto a traves de horas de trabajo”, 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”.
Si solo ves “recursos” pues, probablemente, y teóricamente, te cuadre lo de cambiar “recursos” de un equipo a otro, por motivos de costos, 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 costo de la fase de aprendizaje y sincronizacion de equipos.
– El ciclo de Tuckman, que tiene que ver con la formacion de equipos de alto rendimiento.
– 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. Olvida 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)
