archivo

Archivos diarios: enero 8, 2012

Esta antipatrón se puede producir en diferentes circunstancias (o una combinación de las mismas):

– El equipo de desarrollo cree que tiene suficiente experiencia en el negocio o en el desarrollo de sistemas de información similares como para no tener que depender de los usuarios a la hora de obtener una requisitos adecuados o su feedback.

– El equipo de proyecto no se preocupa por la calidad interna del producto pensando en que el cliente nunca descubrirá lo que se esconde bajo la alfombra. Por ese motivo no se tendrán escrúpulos para poner el proyecto en personal que todavía no tiene la suficiente experiencia o cualificación para realizarlo de manera adecuada (esta estrategia es muy utilizada para organizaciones cuya política para hacer negocio es tirar los precios).

– Los gestores del proveedor hacen una migración de costes para cuadrar determinados proyectos afectando sensiblemente a algunos de ellos a espaldas del cliente.

– Se piensa que el cliente por no tener un perfil técnico siempre toma decisiones incorrectas.

Es cierto que los clientes en muchas ocasiones no están a la altura y ciertos stakeholders intentan eludir su responsabilidad siempre que pueden y que eso obliga a tomar ciertas decisiones si a nivel directivo no se consigue reconducir el problema.

No obstante, eso no quiere decir que el problema siempre se encuentre en el cliente, de hecho si lo piensas tienes un serio problema porque te estás poniendo una venda ante los errores de tu organización, de tu equipo de proyecto y los tuyos propios, lo que supondrá un lastre a tu desarrollo profesional porque para corregir errores y conductas lo primero que tienes que hacer es reconocer que hay cosas que no estás haciendo mal.

Pese a todo hay profesionales que siempre echan la culpa al cliente, que piensan que el cliente es el enemigo (cuando realmente la visión que hay que tener es la contraria). Poco futuro les veo a su organización y a ellos pensando de esa forma. Como decía antes, tienen un serio problema.

Es posible que engañes una vez al cliente, tal vez dos, tres… pero llegará un punto donde te pillará, con pruebas o sin pruebas y cuando eso ocurra, adiós confianza y posiblemente adiós cliente.

Blowhard Jamboree se podría traducir como el fanfarrón del Jamboree.

El término Jamboree se utiliza para denominar unos encuentros internacionales de scouts que se celebran periódicamente (su origen parece ser que proviene de una palabra zulú que significa reunión de todas las tribus).

Este antipatrón consiste en tomar como dogma determinadas conclusiones técnicas, metodológicas, de gestión, etc… que son proporcionadas por expertos en una determinada materia y aplicarlas a proyectos concretos sin hacer una mínima reflexión sobre su conveniencia o aplicabilidad en el mismo.

Muchas veces leemos algo, nos enseñan algo en un curso o en un congreso y parece que hemos alcanzado la iluminación. Es posible que aprendamos algo que sea de mucha utilidad pero siempre hay que ser prudente y antes de tomar determinadas decisiones o cambiar ciertos hábitos hay que analizar de manera adecuada si realmente nos encontramos en situación de aplicar nuestros nuevos conocimientos, hay que esperar a una oportunidad mejor o se escogen de los mismos aquellos aspectos que consideramos realmente de interés.

Planificar es una actividad que nos suele gustar a muchos: poner las piezas en el tablero, determinar una estrategia, unas reglas del juego, unos plazos en los que desarrollarse el trabajo, etc…

Además es una actividad que considero necesaria en cualquier proyecto, pero eso sí, en la justa medida de lo que sea necesario.

Cuando la planificación supera lo que el proyecto requiere nos encontraremos de lleno con este antipatrón, ya que invertiremos más esfuerzo (y tiempo) del necesario para establecer un plan que después puede ser destruido por las propias contingencias del proceso de desarrollo.

También se considera que se llega a este antipatrón cuando no se es flexible ante una planificación inicial, conservándose a lo largo del proyecto pese a que se pueda apreciar que resulta absolutamente irreal.

Ante un hecho o un problema lo más normal es que la percepción de cada observador sea diferente. En algunos casos serán solo matices, en otros la divergencia será mucho mayor.

Cuando vamos a desarrollar software lo que hacemos es realizar una abstracción de esa percepción que tenemos del mundo real. Para realizar esa abstracción, además de nuestros sentidos, nuestro conocimiento y nuestra experiencia intervendrán los usuarios y otros componentes del equipo de proyecto.

Mediante la abstracción se busca un consenso entre percepciones diferentes, priorizándose la visión del usuario porque al final serán ellos los que utilicen el sistema de información.

Pero la abstracción no solo se limita a aspectos funcionales, también se centra en aspectos técnicos del propio proceso de desarrollo. La arquitectura de un sistema de información no es más que la definición de un esqueleto que será rellenado con el código fuente de la aplicación o por terceros componentes en los que se delega funcionalidad. En esta abstracción entran en juego otros perfiles, aunque deben tener en cuenta las características del sistema que se abstrae desde el área funcional.

La abstracción puede entrar en todos los detalles que uno quiera pero realmente hasta que no se implementa una solución no se termina de poner forma a sus múltiples esquinas. En ocasiones se acertará a la primera, en la mayoría de los casos serán necesarias varias iteraciones para encontrar una solución que se considere satisfactoria.

La incertidumbre existente en el proceso de desarrollo de software ya de por sí es motivo suficiente para aportar por un enfoque ágil en los proyectos (al menos, en la mayoría de ellos), si a eso le sumamos la propia naturaleza de la transformación de percepciones heterogéneas de la realidad a un conjunto de líneas de código, encontramos otra justificación adicional a dicho enfoque.

Este antipatrón se produce cuando existiendo un conflicto entre gestores de proyectos (o en general entre personas que tienen equipos a su cargo) no se le busca una solución definitiva al mismo.

En las organizaciones es muy frecuente encontrarnos con miniestados, taifas o chiringuitos, en las que un gestor hace o deshace. Es como si nos encontrásemos con departamentos que funcionan de forma autónoma y que compiten por recursos dentro de la organización y no suelen admitir injerencias, por lo menos, entre iguales.

Permitir esto es crear un caldo de cultivo idóneo para el conflicto entre gestores ya que por muy independientes que se consideren siempre habrá elementos comunes que provoquen interacción directa o indirecta entre los mismos.

Para llegar a producirse este antipatrón, no es necesario llegar a la situación descrita, ya que un conflicto se puede producir en cualquier circunstancia y más en un sector en el que hay tanta presión como el nuestro.

Muchos directores deciden no intervenir en estos casos (sobre todo si se tratan de gestores con un cierto peso), ya que para ellos es la postura más cómoda. Es cierto que a veces el sentido común impera y los problemas se terminan solucionando, pero en otros casos, la situación no hace más que empeorar, algo que por otra parte conocen los equipos de trabajo que dependen de cada uno y que será utilizado también como arma arrojadiza por parte de muchos roles intermedios (o en general por cualquier rol) al más mínimo roce con personal que dependa del otro gestor, por lo que las causas de conflicto se multiplican.