archivo

Archivos diarios: diciembre 24, 2011

Estamos ante una organización, departamento o equipo de proyecto que tienen perfectamente asumido los procesos que rigen su gestión pero que no muestra flexibilidad en aquellos casos en los que resulta necesario.

Una gestión orientada a procesos es necesaria. Es la única forma de darle un orden a equipos que trabajan en proyectos diferentes, a personas con objetivos diferentes y en general a un sistema heterogéneo que se vuelve más complejo conforme va creciendo.

Ahora bien, una buena gestión orientada a procesos debe ofrecer en algunos de ellos la posibilidad de que existan diferentes alternativas en función de la naturaleza del proyecto en el que se está trabajando o de la situación en la que nos encontremos y si fuera necesario debería contemplar aquellas situaciones en las que un determinado proceso no tiene por qué seguirse tal cual (después tocará ver si se ha tratado de un hecho aislado o si el proceso requiere ser revisado).

El desarrollo de software debe permitir flexibilidad, ser ágil y debe regirse en un contexto orientado a procesos. El equilibrio entre ambos objetivos permitirá marcar la diferencia a nivel organizativo y tendrá consecuencia positiva tanto en la gestión como en los productos obtenidos.

No seré yo el que ponga en tela de juicio procedimientos de gestión y toma de decisiones basados en criterios objetivos. Creo en ellos. Ahora bien, hay algún aspecto que creo que resulta interesante analizar.

Los números reflejan una realidad, pero también pueden esconder muchas cosas, entre ellas una muy importante y es cómo se han llegado a alcanzar esos números.

Un responsable de cuenta puede haber conseguido unos beneficios para la organización de 100.000 euros y sin embargo, haberse cargado por el camino la posible continuidad con determinados clientes, otro presentar unos beneficios de 20.000 euros, pero a cambio de haber reventado a su equipo de trabajo, con el riesgo que supone esto para proyectos futuros y para la continuidad de algunos en la organización y otro presentar unas pérdidas de 10.000 euros, pero con unos clientes satisfechos que probablemente amplíen los contratos ya existentes.

Un responsable de cuenta puede haber conseguido esos resultados en base a su trabajo y el de los demás o solo en base al trabajo de los demás.

Independientemente de lo anterior, en ocasiones los números a veces presentan una afirmación demoledora e incontestable, pero es necesario además, tener muy claro que los resultados obtenidos estén fundados en unos datos de partida reales.

Por tanto, gestión objetiva, siempre que se pueda, pero entendiéndose que en ocasiones será necesario complementarla con otros datos objetivos (o subjetivos) y que se debe tener muy controlado que los datos a partir de los cuales se obtienen las mediciones (así como las propias mediciones) son correctos.

En un proyecto de desarrollo de software participan muchas personas, cada una de las cuales tiene un criterio propio, resultado del rol que desempeñan, su experiencia, conocimientos, percepción del problema. etc…

Y esta situación la tenemos tanto dentro del equipo de proyecto, como con las personas del resto de stakeholders con los que tenemos que trabajar.

Alcanzar un equilibrio entre tantas visiones resulta complicado, como difícil resulta también alinear sus objetivos individuales con un objetivo común y general que no es otro que realizar el proyecto con éxito.

Un proyecto es la suma de muchas decisiones, a veces se acertará, a veces se fallará. Eso es una constante, como también lo será que dentro de tal amalgama de personas, probablemente habrá casi siempre alguien que ante un problema apunte una solución más adecuada que la que se tomó.

A este antipatrón se llega, cuando de manera reiterada el equilibrio entre las personas que trabajan en el proyecto (ya sean del mismo equipo o de diferentes) se rompe, echando en cara que determinadas decisiones fueron erróneas por no escuchar la solución que se proponía.

El equilibrio se rompe porque no se es constructivo en el análisis del proceso de toma de decisiones, tal vez algo esté fallando en él y no se estén teniendo en cuenta, por el motivo que sea, opiniones válidas. En lugar de eso, se procede al ataque personal o a la creación de motines.

Otro antipatrón muy típico en el desarrollo de software.

Se produce cuando ante una contingencia (generalmente, de una cierta importancia) que ocurre en el proyecto y que lo deja bloqueado o ralentiza de manera considerable su ejecución (y que terminará finalmente bloqueado), que requiere de la participación o del consenso entre los directores stakeholders, no se le termina de dar una solución satisfactoria, de manera que todo queda prácticamente igual.

Ante esta situación, el equipo de proyecto y el personal del resto de stakeholders que no ocupan posición directiva, se quedan ante un panorama difícil de resolver, ya que probablemente se habrá llegado a esta situación, por un conflicto entre equipos de trabajo, por desacuerdos contractuales y/o por alguna circunstancia en el proceso de desarrollo que de no repararse, podría poner en peligro el éxito del proyecto.

El problema se produce en el día del proyecto (o es consecuencia de él), se escala (o llega desde arriba), los de arriba no le dan solución al problema, vuelve hacia abajo, pero la situación es peor, se ha perdido más tiempo, se ha sufrido desgaste y nada.

Cuando se llega a esta situación es complicado que se resuelva por sí misma, por lo que la estrategia a aplicar dependerá del estado en el que se encuentre el proyecto.

Si estamos en etapas iniciales, lo mejor es resolver el contrato. Si estamos en etapas intermedias, es necesario escalar el problema tantas veces como sea necesario porque sin acuerdo, por bueno o malo que sea, no se tendrá producto software y todos saldrán perdiendo. Si estamos en etapas finales, es necesario darle cierre al proyecto cuanto antes (resolver el contrato, pero con una serie de hitos a conseguir), aunque requiera de la apertura de un nuevo proyecto para terminar de desarrollar por completo el producto.