archivo

Archivos diarios: diciembre 14, 2011

Es curioso descubrir la diferencia en los resultados cuando cada uno hace la guerra por su cuenta y cuando todos están enfocados a la consecución de un objetivo común.

Puede parecer sencillo alinear objetivos pero la realidad es que lo más normal es que cada uno interprete los objetivos a su manera, ¿por qué? pues porque la percepción de cada uno sobre un mismo hecho es diferente y porque somos tremendamente egoistas (y quien esté libre de pecado que tire la primera piedra).

Un gestor de equipos de trabajo tiene que tratar de conseguir ese enfoque común en los objetivos, que se entienda la importancia de la colaboración entre todos para alcanzarlos. Un gestor de proyectos tiene que tratar de conseguir lo mismo entre los diferentes stakeholders que intervienen.

Personas, personas, personas, al final todo lleva a lo mismo, cierto es que el contexto en los proyectos influye mucho en los resultados, pero somos nosotros finalmente lo que lo empujamos al éxito o al precipicio.

Tiene una cierta lógica pensar que aquellos desarrolladores y autores que defiendan que el eje sobre el que gira el desarrollo de software sean las personas, no tengan mucho aprecio a los procesos.

Y es posible que incluso, en muchos casos, ese juicio de valor sea acertado, no obstante, por poco que sea el cariño que se tenga a los procesos, la mayoría sabe que son un mal (o un bien) necesario.

Necesario porque es necesario que la organización, formada por diferentes equipos de proyecto, cada uno de los cuales con sus problemas e intereses, tenga un cierto orden, una cierta manera de hacer las cosas, una cultura de empresa que no se quede exclusivamente en aspectos superficiales sino también que alcance al día a día del trabajo.

Ahora bien, como en todo, los excesos no son buenos y los procesos, no podían ser una excepción.

No hay que perder de vista, qué pretendemos con los procesos y que entre sus objetivos no se encuentra vivir bajo su dictadura porque no hay que olvidar que no son un fin, sino un medio y que por encima de todo se encuentra la intención de conseguir que los proyectos terminen con éxito.

Esto implica flexibilidad cuando sea necesario, teniendo en cuenta que necesidad y capricho no son lo mismo.

Sobre la medida en que se deben considerar los procesos, Tom DeMarco y Tim Lister, realizan la siguiente reflexión: “La obsesión por los procesos es el problema. La obsesión por el proceso no es solo una anomalía que ocurre ahora y siempre. Es una epidemia”.

Los procesos proporcionan un camino por dónde ir, pero son las personas las que finalmente consiguen llegar a la meta o perderse.

Los proyectos, en ocasiones, entran en una inercia, una deriva, que resulta complicado cambiar, siendo la dificultad de ese cambio proporcional al grado de ejecución del proyecto, al tamaño del sistema, etc…

El cambio aún siendo complejo, es posible si se dan las circunstancias adecuadas y se es consciente de que los resultados pueden tardar en llegar. Toda semilla necesita tiempo para salir a la superficie.

Si un desarrollo, un mantenimiento o la gestión de un proyecto va en una dirección que no produce los resultados esperados, hay que analizar los motivos y a continuación decidir si realmente conviene o no seguir actuando de una determinada manera. Cambiar por cambiar, sin analizar qué es lo que está pasando, probablemente nos lleve de una situación mala a una situación igual o peor.

Probablemente sea necesario cambiar bastantes cosas y eso lleva tiempo, ahí nos encontramos con otro problema. Sucede que llegado un momento en el proyecto todos son prisas y se quiere que se resuelvan todos los problemas para ya.

Y en el desarrollo de software, sobre todo si queremos hacer las cosas bien, el para ya no suele ofrecer buenos resultados a lo que hay que sumar que no es compatible con el hecho de cambiar la inercia de un proyecto que no va bien.