archivo

Archivo de la etiqueta: director usuario

Una de las labores más complicadas de un gestor de proyectos en aquellos casos en los que existen múltiples equipos de trabajo que pueden pertenecer incluso a proveedores diferentes (tampoco resulta sencillo hasta en aquellos casos en los que existe un solo equipo formado por pocos desarrolladores) es que todos comprendan cuáles son los objetivos y las restricciones que existen para alcanzarlos.

Resulta especialmente complicado sobre todo en aquellos equipos que están desarrollando funcionalidades o herramientas complementarias al núcleo el sistema, en primer lugar porque la atención del gestor estará más orientada a la línea principal de desarrollo del producto así como a eliminar o paliar las posibles resistencias que puedan existir en cualquiera de las distintas líneas y en segundo lugar porque, por el mismo motivo, se encontrarán a distancia del product owner y de los directores usuarios y contemplarán desde más lejos sus expectativas y su presión.

Hay proyectos donde el trabajo de estos equipos secundarios es igualmente secundario pero en otros casos el resultado de su trabajo puede ser esencial para el funcionamiento y/o para la puesta en marcha del sistema. Tanto en un caso como en otro (aunque por supuesto mucho más en el segundo) es necesario que esos equipos mantengan el enfoque y la tensión en el proyecto, de la misma forma que lo hacen aquellos equipos que están peleando con las partes más críticas del sistema.

Como decía, esto no es fácil, ya que resultaría fundamental que el product owner y los directores usuarios les expresasen directamente y de forma constante (continua) sus expectativas y eso es algo que resulta complicado en proyectos con una cierta envergadura. Ahora bien, si no es posible llegar a eso cualquier aproximación ya supone un avance. Si el equipo no termina de asimilar la situación, el gestor de proyectos debe actuar y en estos casos es mejor un falso positivo (pensar que el equipo no es consciente de la situación e insistir) que creer que se ha asimilado y no actuar.

Cuantas más personas se suban al barco más posibilidades hay de sacar el proyecto adelante, sin olvidar que hay que procurar que quien suba no vuelva a bajar (de ahí la importancia de las actividades necesarias para que los equipos y los desarrolladores mantengan el enfoque en el proyecto).

Los gestores del proyecto, los directores usuarios, etc… tienen en muchas ocasiones ideas equivocadas de cómo va el proyecto, ya sea porque no se han preocupado por el estado real del mismo, porque han analizado mal la situación o porque le han vendido la moto (ver antipatrón “Humo y espejos“).

En cualquiera de los tres casos se tiene un miedo exacerbado a contarles la realidad del proyecto (en el caso de no haberles contado exactamente la realidad puede ser comprensible, pero ten en cuenta que si no lo haces al final será peor) y eso alimenta una falsa expectativa del mismo o lo que es lo mismo se pone al proyecto un listón tan alto que difícilmente podremos superar.

Una mala gestión de expectativas al final se termina volviendo en contra de quien no ha sabido transmitir de manera adecuada la situación del proyecto o de quien no ha corregido a tiempo una impresión equivocada del mismo porque te terminarán exigiendo lo que no vas a poder dar con el agravante de que ya lo daban por hecho y pensaban, por tanto, que lo tenían en la mano (si hay algo peor a no tener algo es creer que lo vas a tener y al final no conseguirlo) y lo que es peor, es posible que ellos mismos a otros departamentos de la organización o a sus superiores trasladasen unas expectativas que no se van a ver cumplidas (en este caso, no lo dudes, el tortazo será inversamente proporcional a tu posición en la jerarquía de la organización).

Recomiendo también leer el artículo: “Desarrollo de software. Barry Boehm. Ciclo de vida en cascada y la incertidumbre del producto final“.

Los equipos de proyecto y, en general, los equipos de trabajo, hasta cierto punto deben funcionar de forma autónoma, utilizando como patrón de funcionamiento los procesos implantados en la organización, la metodología de desarrollo y cualquier acuerdo específico alcanzado para la realización del proyecto.

Ahora bien, existen determinadas decisiones que deben recaer sobre aquellas personas en las que se le ha delegado una determinada competencia y que no se deben diluir por inacción en el equipo de proyecto porque al final esto se volverá en contra de dicho equipo.

También existen determinadas circunstancias donde el responsable máximo del proyecto o el responsable de un equipo de trabajo tiene que intervenir, ya sea para poner un poco de orden, cuando éste se pierde, para reconducir situaciones no beneficiosas para el proyecto, etc…

El antipatrón lo tenemos cuando dichos responsables no aparecen en el proyecto o no aparecen en momentos clave, es decir, cuando se les necesita casi nunca están. Esta circunstancia hace mucho daño al proyecto, ya que su principal misión es mantener el frágil y complicado equilibrio entre todos los stakeholders y entre las personas que conforman un determinado equipo de trabajo.

Cuanto más grande sea la grieta creada por su ausencia, más complicado será reconducir el proyecto a una situación de equilibrio y si se consigue será a costa de un desgaste y/o un esfuerzo innecesario, si el responsable hubiera hecho lo que tenía que hacer.

El área usuaria condiciona en gran medida el éxito o el fracaso de un proyecto de desarrollo de software. Su actitud es fundamental, si ellos no quieren el proyecto probablemente fracasará y si quieren, existirá un mayor número de posibilidades de que termine con éxito.

Es muy importante, como he comentado ya en infinidad de artículos, que al director usuario, si es el que finalmente sufraga la inversión del proyecto, hay que dejarle muy claro lo que el proyecto necesita a nivel de medios y también dejarle muy claro cuál va a ser la metodología de trabajo y lo necesario que resulta que todos los stakeholders estén implicados en el proyecto, buscando un mismo fin, que no es otro que el producto final satisfaga las expectativas planteadas.

Y todo eso debe recogerse documentalmente y a ser posible, además con una aceptación de dicho documento por parte del director usuario.

De esta forma, sirva para más o sirva para menos, tenemos una primera barrera de protección, porque no olvidemos que cuando un proyecto empieza a ir mal, las miradas siempre van dirigidas a los mismos.

Después, cuando se trabaje ya de manera efectiva en el proyecto, independientemente de la metodología que se utilice, todo acuerdo en materia de requisitos funcionales y no funcionales entre el equipo de desarrollo y el área usuaria, así como cualquier modificación de los mismos, debe ser recogido documentalmente y ser aceptado por el director usuario o por la persona o personas en quien haya delegado determinadas decisiones.

Esto no es burocracia, solo se trata de dar un carácter más formal a nuestra forma de aceptar trabajos, ya que estas serán nuestras siguientes barreras de defensa.

Sin lo anterior, estamos a expensas de ser sometidos a la tiranía del área usuaria, donde todo, según ellos, se puede realizar de manera fácil y rápida, donde todo debe estar prácticamente perfecto y donde se pueden permitir cambiar las decisiones tomadas en cualquier momento y en muchos casos achacar al equipo de proyecto que no han recogido de manera adecuada lo que ellos querían.

Es necesario el feedback del área usuaria para poder acercar el proyecto cada vez más a sus objetivos, sin embargo, el feedback debe estar controlado por una metodología de trabajo y por la necesidad de asumir todas aquellas decisiones que se hayan tomado previamente.

Se habla mucho de la gestión de riesgos en los proyectos de desarrollo de software y con razón, ya que es fundamental desde incluso antes de que comiencen y es necesario continuar con ella hasta el final, actualizándose con las circunstancias actuales del proyecto y su contexto.

Pero no tiene menos importancia la gestión de expectativas y sin embargo no es algo que esté tan presente y personalmente no lo entiendo, ya que una incorrecta gestión de expectativas te puede hundir el proyecto, tanto si no interpretas bien cuál es el umbral de aceptación del usuario, del director usuario o del responsable técnico, como si no modulas esas expectativas con la realidad del proyecto y no las vas actualizando con información veraz de su ejecución.

A veces, uno puede escapar de una mala gestión de expectativas ya que lo mismo la otra parte se da cuenta de todo demasiado tarde, es decir, podrás sobrevivir al proyecto pero no a la pérdida de confianza del cliente.

Sistema desarrollado. En producción. Usuarios que no les gusta el resultado final o que no les parece adecuado el resultado que se obtiene como consecuencia de las directrices funcionales que dieron otros antes. Sistema de gran tamaño. Capacidad muy limitada a nivel presupuestario para poder ejecutar varias líneas de trabajo en paralelo. Usuarios que no quieren utilizar el sistema.

¿Os suena? Es el resultado típico de un proyecto desarrollado en cascada. Admito, ya lo he hecho en otros artículos, que estoy generalizando y que cada cual cuenta la historia tal como la ha vivido y/o puede observar en su entorno. Esta es mi visión sobre este tipo de desarrollo y no es teoría, os lo puedo asegurar.

Ante la situación descrita anteriormente hay dos alternativas posibles: renunciar al sistema de información (tirarlo a la basura) o que todas las partes (área usuaria, dirección usuaria y área informática) asuman lo desarrollado como propio y que tiren hacia adelante, teniendo en cuenta y muy presente, que lo que viene a continuación es una larga travesía en el desierto, donde habrá personas bastante descontentas y donde el uso del sistema será incómodo.

Asumir eso no es fácil, pero es lo que queda si se quiere salvar el sistema de información, ya que no se tendrá el mismo dinero para mantener que para desarrollar y el mantenimiento es sobre el conjunto del sistema (salvo que haya módulos que se prioricen sobre otros).

Es así de sencillo salvo que haya instrucciones de muy arriba que obliguen al uso del sistema de información (si ya se ha desarrollado o adquirido) o que impliquen a los mismos en la definición y desarrollo del sistema y se les pida cuentas por los resultados obtenidos.

Si los directores usuarios no quieren controlar el desempeño del área usuaria en el proyecto, la utilización o desarrollo del sistema seguirá la deriva que quieran los usuarios (que será la que decida la corriente mayoritaria o con más poder) y esto es muy peligroso, sobre todo si los usuarios no sienten la necesidad de que les implanten/impongan un sistemas, algo que ocurre en la mayoría de los casos, ya que tienen medios artesanales y efectivos para llevar el día a día de su trabajo (herramientas ofimáticas, organización de ficheros en carpetas, etc…).

¿A que todos conocemos sistemas de información que se han ido al traste por este motivo?, ¿a que todos conocemos sistemas de información que no terminan nunca de ponerse en marcha porque siempre surge un “defecto” que es imprescindible de corregir antes?.

Y lo más importante de todo, llegado un punto, el equipo de proyecto debe parar, ya que los desarrolladores no podemos ni debemos estar tras los usuarios para que hagan uso del sistema (lo podemos hacer pero hasta cierto punto, ya que a todos nos gusta que nuestro trabajo sirva para algo, pero una vez que nos demos cuenta que el obstáculo es difícilmente salvable, es mejor no malgastar más energías y que sea la dirección usuaria o los propios usuarios los que, si quieren, sean los que se dirijan a nosotros).