archivo

Archivos Mensuales: febrero 2012

He escuchado lo mismo en muchos proyectos y lo peor de todo es que muchos de los que preguntaban eso habían sido los que pidieron que se hiciera de esa forma o los que habían autorizado y, por tanto, dado validez, a otros que fueron los que realizaron dicha solicitud.

Al final, salvo que se tenga bien atado de dónde procedieron las especificaciones, la cuerda se romperá por el lado más débil, el del desarrollador.

Es importante que el área funcional sepa de su responsabilidad en el proyecto y que las decisiones que tomen impactarán en positivo o en negativo en el balance del mismo tanto a nivel de calidad como a nivel económico.

Por otro lado, el equipo de proyecto debe tener constancia por escrito y a ser posible, firmada, por parte del área usuaria de la petición de trabajo realizada, así como de sus especificaciones.

El producto software que se obtiene finalmente es consecuencia de las directrices que ha indicado el área usuaria. Nos habrá dado unos requisitos, a lo largo del proyecto, habrá cambiado el enfoque de algunos de ellos, otros se desecharán y aparecerán algunos nuevos. Esto es independiente de la metodología utilizada.

Sin embargo el equipo de proyecto no debe ser una serie de ovejitas que van detrás de un partorcito (el usuario), ¿dónde está el valor que aporta el equipo al proyecto? Traducir especificaciones a un lenguaje de programación tiene su complejidad, sobre todo si se hace bien, pero, ¿solo somos traductores?, ¿no somos capaces de proponer alternativas al usuario?, ¿no somos capaces de hacerle vez que tal vez determinadas funcionalidades que solicita en términos coste/beneficio no son ventajosas?, ¿no somos capaces de aportar al cliente toda nuestra experiencia?.

Es muy fácil lavarse las manos y echar toda la culpa al cliente o al usuario (que la tendrán y en algunos proyectos mucha o casi toda) pero, ¿seguro que no somos responsables de nada?.

No es un hecho puntual, he podido comprobarlo en primera persona y como espectador en numerosas ocasiones.

He escuchado a usuarios decir auténticas barbaridades sobre el sistema de información que están utilizando, repasando el árbol genealógico del mismo y de los que lo desarrollaron, presionando hasta el límite para dejar de usarlo y que cuando se les brinda una nueva solución que mejora sustancialmente a la anterior, vuelven a repetir ese mismo ciclo, ensalzando todas las virtudes del sistema antiguo y minimizando sus defectos.

Es cierto que hay veces que se les ha sustituido basura por una basura tecnológicamente más avanzada pero en otras no ha sido así y sin embargo su rechazo sigue siendo frontal.

Por este motivo, es tan importante realizar una gestión del cambio adecuada, ya que no todos los usuarios han podido participar activamente en la concepción y desarrollo del producto y también lo es que determinados usuarios referencia, hayan tenido una implicación importante en la solución construida y en la toma de decisiones.

Todavía hay algo peor que la orientación a la contabilidad y es la orientación a la nada.

A esto se llega cuando ya no solo desprecias al producto y al cliente, sino que desprecias a tu propia organización, no importándote siquiera que su balance sea positivo o negativo.

Las personas que forman parte de este antipatrón, solo tienen una preocupación, mantener su puesto de trabajo mientras les interese mantenerlo pero con el menor esfuerzo posible, aunque eso lleve a cargar sobre otros responsabilidades que le corresponden, a falsear datos o a aparentar la realización de unos esfuerzos que son solo eso, apariencia, como una caja de bombones sin nada dentro.

Cuando nos olvidamos del producto y del cliente y solo se piensa en los beneficios es cuando entramos de lleno en este antipatrón.

De hecho, para muchos, demasiados diría yo, que están en este negocio, el producto y el cliente son solo un mal necesario que hay que pasar para ganar dinero. El daño que le está haciendo este tipo de personas a este sector va a requerir mucho tiempo y muchos esfuerzo para intentar recuperar de nuevo un equilibrio y un prestigio que ha desaparecido.

Cuando se tiene una empresa se quiere ganar dinero con ella, ese no es el problema, sino la forma o el método empleado para conseguirlo, el cual si se aleja del producto y del cliente, salvo que tengas muy buenos contactos, podrá producir unos resultados razonables a corto plazo, tal vez a medio, pero nefastos a largo.

El beneficio debe ser el resultado de creer en el producto en que se desarrolla y en conseguir la satisfacción del cliente, ese beneficio atrae más beneficio. Otro tipo de prácticas, han devaluado nuestro sector, con precios basura que favorece precisamente a quien hace basura, lo que tenemos que preguntarnos es si queremos seguir desarrollando basura o queremos realmente hacer software de calidad y crecer con el mismo.

La orientación a la calidad del producto y a la satisfacción del cliente requiere en primer lugar una creencia firme en que los objetivos se consiguen a partir del cumplimiento sistemático de esa meta y en segundo lugar para romper las barreras de los precios basura hay que competir a través de un gran productividad de los equipos de proyecto (productividad no es igual a echar a más horas, productividad es ser eficiente) cuyo combustible sea personal con talento, implicado con la idea de la empresa, implicado con el producto, implicado con las satisfacción del cliente, motivado y con recursos de proceso, formativos, metodológicos y de arquitectura que permitan hacer más con menos.

Lo más importante en el desarrollo de un producto software es que el cliente se encuentre satisfecho con el mismo y para ello es necesario para empezar que el mismo funcione y cumpla sus expectativas.

Sin embargo, si solo nos quedamos en eso corremos el riesgo de caer en este antipatrón, aquel en el que se piensa que todo lo que está detrás de la interfaz de usuario no importa y que lo fundamental es ejecutar el trabajo, después ya le tocará a otro mantenerlo y a otros sufrir una arquitectura inestable.

No debe ser así, un desarrollo orientado a la contabilidad, a los beneficios tal vez pueda encontrar justificación a actuar de esa manera, pero un desarrollo orientado a la calidad integral del producto y del servicio que proporcionamos a un cliente nunca debería encontrar justificación a entregar un software con esas deficiencias.

Nos encontramos ante un antipatrón que también se suele producir con frecuencia y que provoca retrasos y otro tipo de problemas en los proyectos.

El interbloqueo ya sea directo o indirecto es consecuencia principalmente de una mala comunicación en el proyecto, también lo puede ser de una mala planificación (pero no necesariamente una planificación inadecuada tiene por qué provocar interbloqueos, pudiéndose producir también este tipo de situaciones sin que existan este tipo de problemas).

Eso de que yo no puedo continuar porque estoy esperando a que tú hagas algo, mientras que tú no puedes hacerlo porque estás esperando a que yo haga otra cosa, desgraciadamente está a la orden del día y lo peor de todo es que la solución en la mayoría de los casos, es sencilla: comunicación.

Cuántos problemas se ahorrarían muchísimos proyectos si la comunicación dentro del equipo de proyecto o entre stakeholders fuera fluida.

No es casualidad que el primer principio del manifiesto ágil indique que se valore “a los individuos y su interacción, por encima de los procesos y las herramientas.”

Lo que suele pasar es que cuando en un proyecto empieza a existir desgaste uno de los primeros elementos en resentirse es la comunicación, lo cual generará más problemas y más desgaste, haciendo la bola de nieve cada vez más grande.