archivo

Archivos diarios: enero 25, 2012

Este antipatrón puede considerarse una ocurrencia concreta de otros antipatrones, como por ejemplo “morir planificando” o “parálisis del análisis“.

A mi me parecería más apropiado llamarlo “ingeniería orientada a papel”.

Es muy común encontrarlo en metodologías clásicas como el ciclo de vida en cascada en el que el desarrollo está completamente dirigido por la documentación y en el que se invierte una cantidad de tiempo muy importante en generar la misma, la cual queda obsoleta ante el primer cambio que ocurra en los requisitos, algo que sucederá antes o después (y en repetidas ocasiones) a lo largo del proceso de desarrollo.

Con esto no quiero decir que la documentación en un proyecto sea algo malo, lo que es malo realmente son los excesos o los defectos y es complicado determinar a priori, sin entrar a analizar un proyecto concreto y su contexto qué es mucho y qué es poco.

A este antipatrón se llega por el exceso:

– Cuando se trata de llegar a una solución depurada del sistema de información mediante un feedback basado en la documentación.

– Cuando se dedica tiempo a perfeccionar documentos invirtiendo más esfuerzo que el valor que se obtiene de la realización de esa actividad.

– Cuando se rompe el principio ágil de valorar más “El software que funciona, por encima de la documentación exhaustiva”.

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.