Desarrollo de software y cómo sacar partido a las desviaciones

Equivocar nos equivocamos todos y supone una oportunidad para adquirir conocimientos.

Para aprender de los errores tenemos que darnos cuenta de que hemos fallado (no siempre es fácil, entre otras cosas porque generalmente prescindimos de la autocrítica) y realizar un análisis de los motivos. Sin razonar las causas, probablemente estemos abriendo las puertas para volver a equivocarnos en lo mismo y así sucesivamente hasta que no sea amortizable tanto error (los errores y fracasos nos abren la puerta del éxito, pero no podemos estar equivocándonos indefinidamente).

En el desarrollo de software se puede fallar en muchos de sus aspectos pero tal vez uno de los puntos críticos sean las desviaciones tanto en tiempo como en coste (generalmente las primeras llevan a las segundas).

Cuanto antes se detecte una desviación, se analice y se le intente dar una solución, menor será su impacto en el proyecto. Si se detecta pero no se hace nada, pensando que el problema se va a arreglar solo o no se le da importancia, estaríamos ante el mismo caso que no detectarla. Por regla general las desviaciones tenderán a empeorar si no se hace nada para corregirlas (a veces no es así, pero solo en contadas ocasiones).

Ya que muchos proyectos van a sufrir desviaciones, ¿cómo podemos sacarle partido? Pues analizando las causas que han llevado al proyecto a esa situación y llevando un registro de las mismas.

Es importante desglosar las características del proyecto: presupuesto, tiempo de ejecución, hitos, tecnología, nuevo desarrollo o mantenimiento, complejidad, tamaño, sistemas con los que interopera, tipo de cliente, nombre del cliente, equipo de trabajo que ha participado, acciones que se han llevado a cabo para corregir las posibles desviaciones, qué desviaciones se han producido al final y así hasta el nivel de detalle que se quiera.

Con ese registro tan simple (y que sería interesante hacerlo en todos los proyectos, incluso en los que han ido bien) y una vez que se tenga un histórico lo suficientemente elaborado, podremos evaluar a priori el nivel de riesgo de un proyecto en función de una serie de variables, así como poder consultar qué resultado han dado determinadas decisiones en el mismo.

Es lo que siempre digo, hay que tomar métricas, hay que medir, es algo necesario. Está muy bien tener experiencia, intuición y/o capacidad de análisis, pero será mucho mejor cuando haya valores objetivos que respalden a esas cualidades.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: