archivo

Archivos diarios: diciembre 2, 2011

La gestión de equipos de trabajo grandes solo puede ser efectiva mediante su división en equipos de trabajo más pequeños, cada uno de ellos coordinado por un responsable que a su vez se coordina con el resto de responsables de equipos de trabajo. Por encima de todos ellos se necesita alguien que a su vez coordine toda la maquinaria. Esta estructura, descrita con tres niveles, podría crecer en función del tamaño del equipo y de la complejidad y especialización de las tareas.

Es importante destacar que no se trata de poner niveles de gestión de manera gratuita. Tan mala es una fórmula plana en equipos de trabajo de estas características como una fórmula excesivamente vertical.

Esa es la base y ese debe ser el objetivo, sin olvidar de que en la realidad las fronteras entre los equipos de trabajo pueden no existir, de manera que una persona puede realizar tareas en varios equipos y otra coordinar diferentes grupos de trabajo.

Ahora bien, una cosa es que las fronteras sean difusas y otra es que las personas estén permutando continuamente dentro de los equipos y no esté repartido el trabajo de manera adecuada. En este caso se entra en una situación de caos y realmente no se divide la gestión entre grupos más pequeños sino que en realidad la gestión es de un solo grupo.

Sobre cómo gestionar este tipo de equipos de trabajo, Sun Tzu realiza la siguiente reflexión: “El control de una gran fuerza sigue el mismo principio que el control de una pequeña fuerza; solo es cuestión de dividirla de manera adecuada para poder controlarla. Luchar con un gran ejército bajo tu mando, no es diferente a luchar con uno más pequeño, se trata de coordinarlo de manera adecuada”.

Considero fundamental, para la gestión de un departamento, de una organización y por supuesto de un proyecto de desarrollo de software que exista una visión global de los objetivos por parte de los stakeholders.

Dentro de las tareas que tienes encomendadas tienes tus propios objetivos pero siempre destinados a satisfacer un objetivo mayor. Cuando se pierde ese enfoque, se pierden las sinergias, la colaboración y cada pieza trata de funcionar, de mantenerse a flote, ande o no ande la máquina en la que se encuentran.

Para conseguir esto se requieren de políticas de comunicación, de coordinación y de dinamización efectivas, con personas decididas y convencidas de que la suma de las partes en conjunto vale más que por separado. Encontrar personas que tengan esa amplitud de miras es muy complicado, ya que además de esa cualidad se requieren habilidades de liderazgo.

En un departamento TIC, por ejemplo, los eternos conflictos entre los departamentos de desarrollo y sistemas vienen provocados precisamente por eso, por no compartir objetivos comunes.

En un proyecto de desarrollo de software, con su complejidad, su incertidumbre, donde las condiciones de partida lo mismo son muy negativas, si los distintos grupos de personas implicados no comparten el mismo objetivo con respecto al sistema, la batalla está perdida.

En la definición de gestión del riesgo que pudimos ver en el artículo anterior, Tim Lister, indica que las actuaciones relacionadas con el riesgo pueden estar orientadas a evitar que se produzca o a tener previstas las actuaciones a realizar en el caso de que aparezca (o una tercera opción, que sería una solución mixta de las anteriores).

Una vez identificado el riesgo y estudiado la probabilidad de que ocurra y su posible impacto se decide, por tanto, si los esfuerzos se centran en evitar que se materialicen y/o a actuar después.

Es importante tener en cuenta que no da igual el tratamiento que se realice de un riesgo, ya que una mala decisión con respecto a los mismos trae consecuencias, por ejemplo, si consideramos que debemos evitar que todo riesgo llegue a producirse, el esfuerzo y en consecuencia, coste económico, que puede tener consigo puede ser excesivo o no asumible, para las características del proyecto en la que se está trabajando. En la cara opuesta tendríamos la opción contrario, actuar de forma reactiva al riesgo, lo cual puede ser igualmente costoso, ya que tocará recoger los pedazos que ha dejado la materialización de los riesgos e intentar encauzar de nuevo el proyecto.

Se han puesto como ejemplo las dos situaciones extremas, con el objeto de que se tenga en cuenta que la gestión del riesgo debe buscar el equilibrio con las características del proyecto que se está desarrollando, la criticidad del sistema de información y el contexto en el que se realizan los trabajos. No se trata, por tanto, de elegir si todos se tratan antes o todos después, sino que cada cual se trate en la forma y momento más adecuado.