Desarrollo de software: Esos terribles flecos

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.

2 comentarios
  1. Me ha pasado en algunos proyectos de desarrollo de software, que la única tarea que falta es la entrega del producto, pero el cliente por diferentes razones no saca tiempo o no quiere, etc

    Muchas veces el producto ha sido desarrollado cuidadosamente siguiendo una metodología y cumpliendo con las métricas de calidad pero el cliente o usuario después de haber participado en el proyecto, no acepta el reto de utilizar la herramienta.

    En este caso el proyecto sigue en la lista de proyectos abiertos, o existe un estado intermedio donde se pueda etiquetar estos casos?

    • jummp dijo:

      Hasta que el cliente no recepciona el producto no se puede dar por cerrado el proyecto, incluso si recepcionándolo hay un período de garantía tampoco se debería dar por cerrado salvo que se llegue a un acuerdo con el cliente. Por tanto, el proyecto estará abierto hasta que se recepciona y en abierto o en garantía hasta que se cierra. Es posible que esté abierto y no genere trabajo en meses, pero al estar abierto en cualquier momento corre el riesgo de reactivarse y provocar la necesidad de dedicar tiempo a realizar tareas en el mismo, que además (y verificando la ley de Murphy) sucederá cuando estés hasta arriba de trabajo.

      A todos los que nos dedicamos a esto del desarrollo nos ha pasado como a ti, hemos desarrollado productos, con mucho cariño, bien hechos, pero que no han terminado por implantarse o ha costado mucho ponerlos en marcha y es que si el cliente (o el usuario) no quiere, muy poco podemos hacer. Si entendemos que hemos hecho todo lo que podíamos hacer para que el proyecto salga, no tenemos que darle más vueltas a esto salvo que intentar de alguna manera obtener el compromiso del cliente de cerrar el proyecto.

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: