archivo

Archivos diarios: junio 25, 2011

Una de las consecuencias más directas de la crisis del software es la crisis de confianza de todos los que participan en los proyectos de desarrollo de software.

De esa crisis de confianza la que más nos debería preocupar a los que nos dedicamos a esta profesión es la que tienen los usuarios finales y las organizaciones en las que trabajan.

¿Cuál pensáis que es la visión general que tienen los usuarios y los clientes de nosotros?, sé sincero y no te centres solamente en tus proyectos, sino en tu experiencia en el mercado.

Si queremos mejorar en reconocimiento, en que se valore realmente nuestro trabajo, en que los proyectos valgan realmente lo que valen, es necesario dejar atrás a la crisis del software. No es algo que podamos hacer solos, ya que se trata de toda una industria, pero detrás de esa industria están las personas que nos dedicamos a ella y todos podemos sumar para cambiar esa situación.

De hecho queremos hacerlo, la aparición de las primeras metodologías ágiles, el manifiesto ágil, la tendencia hacia lo artesano, el deseo por hacer las cosas bien, la orientación al cliente…

El camino será largo y difícil, pero no por ello deja de estar al alcance de nuestra mano.

Para tu organización puede ser ganar dinero, para el cliente puede ser informatizar un proceso para mejorar en productividad y eficacia, para tu jefe puede ser subir un par de peldaños más, pero para tu equipo el objetivo debe ser la satisfacción del usuario.

En realidad debería ser el objetivo de todos los que participan en el proyecto.

Con respecto al proveedor, hay que tener claro que quien tiene una empresa quiere beneficios y a ser posible mayores que los que tendría invirtiendo ese dinero en otros negocios, en renta fija, en bolsa, etc… Sin embargo, hay que tener en cuenta que los beneficios de hoy pueden ser las pérdidas de mañana y que las pérdidas de hoy pueden ser los beneficios de mañana.

Centrarse en los resultados de un proyecto concreto por lo que ha ganado o por lo que se ha perdido es un error, es una visión cortoplacista. Es necesario analizar cómo ha transcurrido el proyecto en su conjunto y cuál ha sido el nivel de satisfacción de los usuarios y del cliente.

Si el cliente y/o el usuario ha quedado insatisfechos, puede que los pierdas y ese beneficio que has obtenido en el proyecto, lo mismo mañana no es nada, porque te tocará buscar otro cliente, que lo mismo lo encuentras o no y si lo encuentras lo mismo resulta nefasto.

Si el cliente y/o el usuario quedan contentos, la puerta siempre quedará abierta. Si has tenido pérdidas, analiza los motivos, pero de la manera más objetiva que te sea posible, ¿por qué se han producido pérdidas?, ¿se ha presupuestado mal?, ¿quién ha presupuestado mal?, ¿el proyecto ha sido mal dirigido?, ¿el equipo de trabajo no ha sido productivo?, ¿se han pedido más cosas que las inicialmente previstas?, ¿se ha cambiado la orientación del proyecto a lo largo de su desarrollo?, ¿el problema ha sido la metodología?, etc…

Las causas pueden ser muchas y es necesario conocerlas, obtener un feedback que pueda ser útil para un futuro para la propia organización en sí, para el equipo de proyecto o para el trato con ese cliente o con ese tipo de clientes. Este análisis se debe hacer tanto perdiendo como ganando dinero, sin embargo, casi nunca se hace, lo cual te condena a repetir una y otra vez los mismos errores.

Se ha podido perder dinero, pero si se aprende de los errores, el enfoque para el siguiente proyecto puede y debe ser distinto. Para otro proyecto con el cliente, si parte del problema (sea mucho o poco) ha sido debido a él, es cuestión que se le plantee en el próximo trabajo las mejoras que se entienden que se deben realizar para que todos terminen contentos, este planteamiento debe hacerse con tacto y teniendo en cuenta la relación que se mantenga con el cliente.

Si piensas que el planteamiento es utópico es que tal vez no lo has intentado y si lo has intentado y el cliente o clientes no atienden a razones, es más que posible que no hayas tenido suerte con los que has trabajado, pero ten por seguro que en el mercado sí que hay clientes sensatos porque un modelo de desarrollo de software que tiene más posibilidades de salir bien es aquel en el que todos ganan.

Son términos que pueden dar lugar a confusión, de manera que se piense que más o menos hablan de lo mismo, pero no es así.

En el Cowboy coding, los desarrolladores actúan en cada momento como ellos entienden que deben hacerlo, de manera que no existe un proceso o metodología que los guíe. Es un modelo de funcionamiento de equipos de trabajo totalmente adaptativo, ya que nada hay más flexible que reescribir las reglas cada vez que sea necesario.

Esa flexibilidad en el funcionamiento de los equipos de trabajo y su capacidad de adaptación rápida a los cambios son rasgos comunes con las metodologías ágiles, sin embargo, la principal diferencia es que mientras que en un caso estamos hablando de ausencia de procesos de desarrollo, en el otro sí que los hay, sí que existen unas líneas maestras para desarrollar el software según la metodología elegida.

En las metodologías ágiles se marca un camino y dentro de ese camino existe una cierta flexibilidad o margen de maniobra para conseguir la máxima adaptación posible dentro de ese marco de trabajo a la naturaleza del proyecto a desarrollar. Sin embargo en el Cowboy coding, ese camino se va construyendo a la misma vez que se va realizando el proyecto.