Un equipo de trabajo con el que colaboré, estaba conformado por 7 personas (6 desarrolladores y 1 líder). El equipo comentaba que estaban muy ocupados y no podían iniciar trabajo con clientes nuevos con rapidez. También, se quejaban de que no les autorizaban contratar más personas, que pudiesen ayudarles a crecer su capacidad de producción. El equipo, en los tres meses que colaboramos, perdió un integrante que se fue a otro empleo y no fue reemplazado.

Muchas organizaciones entrarían en una crisis en ese escenario con los proyectos actuales. Sin embargo, el equipo del que les hablo tuvo un mejor resultado: incrementó su capacidad de atender nuevos clientes en 53% en un año, con 6 personas solamente.

El equipo creció sin aumentar la cantidad de integrantes. Otros equipos, en otras organizaciones, crecen en personal, pero no en capacidad en la misma proporción; incluso, algunos la reducen conforme más personas llegan. Hay varias razones para esto, aquí te expongo algunas.

La ley de Brooks

Fred Brooks escribió en su libro “The Mythical Man Month” (el cual les recomiendo su lectura) que agregar más personas a un proyecto retrasado, solamente lo retrasará más. Esta es conocida como la Ley de Brooks.

Una creencia común en la gestión de proyectos de software (y de otras industrias) es que un número mayor de trabajadores lograrán completar una tarea en un tiempo calendario menor, por lo tanto agregan más personas a un proyecto cuando éste se retrasa con la esperanza de acortar el calendario. En software, siempre se obtiene el efecto contrario y se retrasa aún más.

Brooks señala tres causas: toma tiempo para que un miembro de equipo nuevo sea productivo, la comunicación se vuelve compleja y agrega tiempo y la divisibilidad limitada que tiene el trabajo; en este último aspecto, nos dice, las tareas de software no se pueden dividir entre varias personas por su naturaleza; es como el caso de un embarazo: a una mujer le toma 9 meses el completar uno, pero no puedes esperar que nueve mujeres hagan un bebé en un mes.

Curva de aprendizaje larga y costosa

Varias organizaciones que he conocido tienen como principio no dar capacitación formal a sus nuevos integrantes. Esperan que aprendan sobre la marcha y sean productivos rápidamente por su cuenta. La realidad es que esto resulta ser más costoso, pues el tiempo que le toma a una persona el desarrollar la experiencia suficiente para ser autónoma en el trabajo es largo. Además, pasará la mayor parte del tiempo arreglando defectos, problemas que fueron causados por su proceso de aprendizaje y que suelen tener impacto en el trabajo de sus compañeros.

Estas organizaciones no tienen definido un programa de entrenamiento. Nunca se dieron el tiempo de definir y actualizar los paths de habilidades y conocimientos que deben tener sus integrantes para ser efectivos, ni los medios posibles para entregar la capacitación. Las personas que tienen el conocimiento suficiente y podrían realizar la capacitación, suelen estar asignados 100% al trabajo, por lo que no hay disponibilidad para que entrenen a miembros nuevos. Tampoco definen presupuestos para capacitación externa, o es considerado como gasto y pérdida de tiempo.

Muchos especialistas, pocos generalistas

Un gran número de organizaciones define una estructura interna en la que la gente ocupa un puesto y realiza un tipo de tareas. Esto funciona muy bien para cierto trabajo, pero en software es necesario un conocimiento más general. 

Cuando los integrantes de equipos de software se especializan (en una tecnología, en una tarea o labor), generan cuellos de botella y dependencias (si no se encuentra el especialista, nadie puede realizar la tarea o resolver el problema); esto causa retraso en trabajos o que algunas tareas se detengan.

En un trabajo con las características del software, los integrantes del equipo deben tender a ser especialistas-generalistas; es decir, buscar un equilibrio entre sus habilidades, donde son más capaces en algunas, pero desarrollan todas a un nivel donde son útiles en el contexto del equipo.

¿Qué hacer?

En software, el crecimiento no se trata de aumentar el número de personas, sino la capacidad de trabajo efectivo. El equipo con el que inicié este artículo logró un crecimiento porque cambió su forma de trabajo y su organización interna, aun cuando tenían menos integrantes.

En estos casos, debemos resistir la tentación de basar nuestra forma de trabajo en copiar la de otra organización. Primero, se debe entender las características del trabajo que vamos a hacer y desarrollar una forma adecuada de completarlo. Pero no detenerse en eso, sino que se debe revisar constantemente para adaptarla a las circunstancias cambiantes.

De este modo, nuestra capacidad será mayor sin tener que depender del número de personas.

¡Nos vemos en la siguiente entrega!

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.