Desarrollo de software. Agilidad, orientación al producto y orientación al proyecto

Como he indicado en el primer artículo de la serie dedicada a la contratación ágil, uno de los principales obstáculos que nos encontramos para aplicar metodologías ágiles es que los clientes difícilmente se van a aventurar a aceptar proyectos sin un presupuesto y sin unos plazos concretos, lo que obliga a hacer uso de determinadas estrategias para que estos proyectos queden encuadrados dentro de un marco presupuestario y de plazos, sin que eso tenga afectar la metodología o sin que tenga que significar que tras un primer contrato vengan otros que terminen de completar el producto.

En otro artículo justifiqué como la aplicación de enfoques iterativos e incrementales encajaban dentro del concepto clásico de proyecto.

Pese a que la compatibilidad metodología ágil/proyectos existe, es más que evidente que la aplicación de los principios ágiles y su instrumentación en diversas metodologías están fundamentalmente orientados al producto ya que por encima de todo se encuentra conseguir que el mismo satisfaga las expectativas del cliente/usuario y para ello antepone principios basados en el producto que principios basados en la propia gestión de los proyectos (no los anula, simplemente da un mayor peso a unos frente a otros).

El desarrollo de un producto la mayoría de las veces está por encima de los límites fijados por el proyecto, salvo que el presupuesto fijado sea muy holgado, algo que en raras ocasiones ocurre. Precisamente querer reducir los límites del desarrollo del producto al proyecto, hace daño sobre todo al producto, pero también al proyecto.

Al producto porque la propia naturaleza del desarrollo de software con presupuestos y alcance inicial, lo que hará que para cuadrar en los números iniciales sea necesario reducir el alcance además de la calidad del producto, pudiéndose quedar fuera funcionalidades consideradas esenciales.

Al proyecto porque si el producto no cumple con las expectativas, no se habrá conseguido alcanzar el fin último por el que se ha ejecutado.

Es necesario que el cliente comprenda que es posible que el producto obtenido como consecuencia del proyecto necesite seguir siendo trabajado hasta conseguir los resultados esperados y esto hará necesario nuevas contrataciones.

Soy consciente de que resulta muy complicado transmitir esto al cliente, sobre todo si deseas que sea tu cliente. Siempre habrá competencia que dirá que ellos lo pueden hacer de una sola vez y por supuesto, con menos dinero.

Hacer un proyecto siguiendo un enfoque iterativo incremental ante un cliente con mentalidad abierta (no todos son iguales) y que entienda las clausulas del contrato (para ello lo firmó) puede ser suficiente pedagogía para darse cuenta de que una vez que el proyecto llegue a su fin, puede ser necesario otro para conseguir que el producto alcance sus expectativas.

About these ads

Deja un comentario

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 )

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 )

Google+ photo

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

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.215 seguidores

%d personas les gusta esto: