archivo

Archivos diarios: junio 29, 2010

No cerrar entregas, no cerrar proyectos, son un peso terrible a soportar tanto por clientes como por proveedores de servicios de desarrollo de software. El problema no está solo en incumplir plazos, que ya de por sí es un problema serio, sino por el hecho de que no terminar de cerrar entregables es una carga adicional que se suma a la carga de las nuevas tareas que surgen, lo que hace que provoca que se tenga que dedicar maś tiempo a llevar dichos trabajos adelante, que por regla general será insuficiente, lo que llevará consigo nuevos retrasos y mermas en la calidad de los mismos, que darán lugar a nuevos flecos que quedarán pendientes, a sumar a muchos de los ya abiertos y a más trabajos nuevos que surjan. En resumidas cuentas un círculo vicioso de muy malas consecuencias.

No se suele prestar desgraciadamente demasiada atención a entregar productos lo más finos posibles, no digo que se entreguen perfectos, porque ni se va a conseguir y además va a obligar a un sobreesfuerzo que tampoco resulta rentable, pero sí que se dedique suficiente atención al proceso de análisis, al impacto que los requisitos funcionales puede tener sobre el producto (en el caso de mantenimientos) y detectar efectos colaterales de dicho desarrollo o dependencias respecto a lo que está hecho que se tienen que tener en cuenta en los nuevos desarrollos.

También es necesario probar adecuadamente lo que se entrega y no sólo a realizar escasas pruebas por encima. La entrega de un producto con problemas, como ya comenté en el párrafo anterior obliga a trabajar el doble, el triple o más y no sólo para el desarrollador, sino también para el cliente, el cual cada vez más disminuirá su nivel de tolerancia, porque generalmente si la interlocución con el cliente es un responsable técnico del proyecto, este será el que dé la cara directamente con los usuarios, los cuales no suelen tener o suelen caracterizarse por su paciencia y evidentemente por mucha capacidad de encaje que se tenga, sentirse como un saco de boxeo no es algo que se pueda aguantar mucho tiempo. A esto hay que sumar que en el cliente además del departamento de desarrollo, hay otros departamentos implicados, como por ejemplo, sistemas, calidad, explotación, etc… que también se ven afectados por estas circunstancias.

Lo peor de todo esto que la diferencia entre hacer las cosas mal o regular a hacerlas bien, no es tanta como se cree y en demasiadas ocasiones, por intentar ir por el camino más corto, no sólo se tarda más, sino que hace que el equipaje para el siguiente viaje sea más pesado, no solo para el desarrollador sino también para todos los que participan en el proyecto de desarrollo de software.