archivo

Archivos diarios: diciembre 27, 2012

No sé que es peor, si intentar por todos los medios que el contenido del análisis o del catálogo de requisitos sea inmutable o pensar que lo va a ser.

Si has participado en proyectos de desarrollo de software sabrás que (entre otras muchas cosas):

– Los usuarios van aprendiendo conforme el producto se va desarrollando y como consecuencia de ese aprendizaje te van a pedir cambios.

– Lo que en papel o en un generador de prototipos parece sencillo, a la hora de enfrentarse a su construcción puede ser tan complejo que resulte recomendable aplicar otro tipo de estrategia.

– El negocio y/o las prioridades puede cambiar y como consecuencia algunas de las especificaciones iniciales ya no sirven.

En base a estas situaciones pensar que el análisis es inmutable es dejarse cegar por la teoría y exigirlo es ir en contra del valor del producto final.

A este antipatrón se llega cuando se acumulan suficientes proyectos de manera que siempre existe la posibilidad de tener ocupadas todas las horas de trabajo.

De entrada podrás preguntarte, ¿es esto un antipatrón? Se convierte en antipatrón cuando el objetivo final no son los proyectos en los que estás trabajando sino en tener facturables todas las horas posibles, dicho de otra manera, el objetivo es protegerte y no la calidad final de tu trabajo.

Para ello empezarás a sumar proyectos a los que puedes imputar horas, los cuales potencialmente ocuparán más del 100% del tiempo, lo cual diversifica el riesgo de encontrarte con valles en los que no tener horas que facturar.

El lado opuesto a ello es el transcurso normal del proyecto o los momentos en los que hay picos. En estos casos se acumularán retrasos en los proyectos y los desarrollos, hechos desde el overtime y/o desde las prisas tendrán una mayor tasa de deficiencias.