archivo

Archivos diarios: agosto 3, 2011

Un defecto aunque también es una virtud que tenemos los que nos dedicamos a esto, si se realiza de forma moderada y en el momento adecuado, es que tenemos cierta esencia de artista.

En los proyectos en los que trabajamos queremos dejar nuestra impronta, nuestro sello. También es cierto que el proceso de desarrollo de software se presta a ello, ya que tenemos todo un campo donde poder cultivar nuestra capacidad creativa.

Lo importante es ser práctico y que el proyecto salga adelante cumpliendo las expectativas del usuario y desarrollando un software de calidad. Mientras se cumpla esa premisa, es compatible aplicar nuestra creatividad al proyecto.

Por otro lado, en el proceso de desarrollo de software, se pierde mucho tiempo en detalles irrelevantes, en ocasiones provocados por el equipo de proyecto y en otras por los usuarios. ¿Cuántas veces se ha tenido que modificar el diseño de una interfaz de usuario en etapa de desarrollo o una vez puesta la aplicación en producción?, ¿cuántas veces se ha pedido cambiar un color por tal otro?, ¿cuántas veces se solicita cambiar un literal por otro?. No entro en si es sencillo o no realizar estos cambios, lo que sí es importante es que mientras se centre la atención en esto no se enfoca el esfuerzo en lo realmente importante y es que el software funcione y sea de calidad.

Hay una cita de H. W. Kenton, un tanto tremendista, pero que ilustra bien a las claras lo importante que resulta centrarse en lo que realmente importa: “Aunque sin duda hay un elemento artístico en la ingeniería, a nadie le importa de qué color era el puente que se derrumbó y mató a cincuenta personas”.

Las mentiras y las falsas expectativas en el desarrollo de software tienen también las patas muy cortas.

Tal vez funcione en un proyecto o en dos, con un cliente o con varios, pero al final los “éxitos” que consigues se convierten en fracasos y por cada puerta que se ha cruzado se han cerrado varias.

Estoy a favor de que se vendan los logros, es más, en determinados contextos es la única forma de que te echen algo de cuenta, pero de igual forma que se hace eso, no hay que ocultar la realidad de lo que está pasando en el proyecto. Muchas veces se huye hacia adelante con el pensamiento de que ya se arreglará el problema, sin embargo, en la mayoría de los casos no solo no se arregla, sino que empeora y lo que es peor, tus jefes se llevan la “sorpresa” de golpe y aumentada, algo que no les hace precisamente felices.

Los proyectos de desarrollo de software, su avance, su estado, deben basarse en los criterios más objetivos posibles, para ello deben basarse en mediciones reales sobre datos reales.

Las percepciones a veces engañan ya que los análisis basados en ellas se pueden adelgazar o engordar a conveniencia.

H. W. Kenton hace una reflexión muy interesante sobre la diferencia entre un político y un ingeniero: “En algún momento tienes que decidir si vas a ser un político o un ingeniero. No puedes ser ambas cosas. Para ser un político la percepción se tiene que imponer a la realidad. Para ser un ingeniero la percepción tiene que estar subordinada a la realidad.”

En las relaciones cliente, proveedor y usuarios en los proyectos de desarrollo de software en muchos casos la acción va muy por delante de la comunicación.

Se entra en la vorágine de ejecutar sin cerrar qué es lo que realmente se quiere y sin obtener un feedback de lo que se está haciendo. Se toman decisiones de manera unilateral, no se homogeinizan percepciones, no se dialoga, no se informa y lo que es peor, no se escucha.

Si el factor crítico de éxito más importante del desarrollo de software son las personas, tal y como manifiestan los principios ágiles, no se puede dejar de lado la comunicación.

Es razonable que exista información que el cliente, proveedor o usuarios no quieran que fluya a los demás, incluso en algunos casos es hasta positivo y saludable que ciertas cosas no se sepan. Sin embargo, quitando eso, no hay razón para que el resto de información que es de interés para el proyecto no fluya entre las partes. De no ser así las posibilidades de malos entendidos, pérdida de confianza, pérdida de impulso y de sinergias crecen considerablemente.

Por otro lado, si existe comunicación y no se escucha estamos ante la misma situación. Si se piensa que siempre se lleva la razón, que lo tenemos todo claro, estaremos perdiendo toda la capacidad de mejorar que nos proporcionan los demás.

No hay nadie en un proyecto de desarrollo de software, salvo que esté trabajando en lo mismo durante mucho tiempo y esté prácticamente integrado con el área usuaria que tenga un control absoluto sobre la técnica, sobre el negocio y sobre lo que realmente esperan los usuarios. Es más, en el caso de que lo tenga, si deja de escuchar, perderá todo lo bueno que le ha proporcionado la experiencia.