Desarrollo de software. Antipatrón. Empire building

Todo gestor quiere contar con el mejor equipo posible para realizar sus proyectos. Cada gestor tiene una idea de equipo ideal, ya que la escala de valores de cada persona suele ser distinta, no obstante, hay “jugadores” que tienen cabida en más de un equipo (cuando no en todos) y ahí es donde se pueden producir conflictos.

Lo más habitual en las organizaciones es que cada gestor tenga un equipo de personas a su cargo más o menos fijo (su personal de confianza) y otro grupo de técnicos que colaboran en proyectos que se estén ejecutando pero que su adscripción al gestor es coyuntural, salvo que de alguna u otra forma destaque en una o más variables valoradas por el gestor y éste decida la inclusión en su equipo (si hay hueco).

Los gestores suelen pelear por mantener a su equipo fijo como sea, para lo cual se requiere la existencia de carga de trabajo. En ocasiones aceptarán compartirlo con otros gestores de manera parcial o total (se marcha a otro proyecto durante un tiempo con compromiso de volver cuando termine o cuando sea posible), con tal de no perderlos definitivamente, pero si no entra trabajo suficiente pasarán a formar parte del equipo de confianza de otro gestor y se perderá la posibilidad de recuperarlo.

Hasta ahí, todo normal en lo que es una empresa de desarrollo de software. El problema viene y de ahí este antipatrón, cuando un gestor impone su fuerza (ya sea por su mayor grado de influencia con la dirección o por tener a su cargo proyectos importantes) para quitarle a otros gestores a técnicos de su equipo, cuando estos los tienen asignados a proyectos. Es decir, se quita capacidad a otros gestores para que tu equipo gane capacidad.

Los desarrolladores no son todos iguales, en productividad, conocimientos, experiencia, adaptación a un entorno, contexto o cliente, etc…, por lo que si a un proyecto le quitan alguno de sus baluartes, indudablemente le afectará (a lo que hay que sumar el tiempo necesario para que un posible sustituto pueda adquirir un nivel productivo aceptable), afectando también a la productividad del equipo de proyecto en su conjunto sobre todo si el mismo estaba bien consolidado.

A eso hay que sumar el deterioro de la relación entre los gestores y el hecho de que concentrar mucho talento en un equipo no necesariamente garantiza nada.

Siempre he defendido que una organización debe intentar asignar a cada proyecto al mejor conjunto posible de personas para poder realizarlo dentro del conjunto de técnicos que puedan estar disponibles (estén o no asignados a proyectos, es decir, se puede estar asignado a un proyecto y por la naturaleza del mismo o su estado, puedan ser sustituido sin mucha pérdida por otras personas).

Ahora bien, también defiendo que si hay equipos que funcionan bien, no hay por qué romperlos, de manera que el mejor conjunto posible de personas que indicaba en el párrafo anterior no lo será si para ello se fractura a un equipo que produce buenos resultados, están contentos y trabajan eficientemente.

1 comentario

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: