El Manifiesto Ágil – Productos funcionando

Interrogante¿Cómo medimos la productividad de un equipo de desarrollo?¿Cómo evaluamos el desempeño?¿En que unidades podemos medir esto?¿tareas? ¿lineas de código? ¿horas? ¿niveles de Serotonina, Adrenalina, Noradrenalina o Dopamina en sangre? ¿tasas de café consumidas? ¿Qué criterios de éxito es posible establecer? ¿porcentaje de avance? ¿grado de completitud? ¿tareas completadas? ¿número de reclamos y re-trabajos? ¿horas planificadas vs horas utilizadas?¿Cómo medimos la satisfacción del cliente? ¿le preguntamos si esta feliz? ¿le mandamos un formulario? ¿número de quejas?

Algunas de estas interrogantes son las que atormentan a los directores de proyectos de software y en general a casi todo el que gestiona proyectos o grupos de personas que realizan un trabajo mayoritariamente intelectual. Y es una tarea verdaderamente engorrosa intentar responder estas interrogantes. Esto me recuerda la película “Jerry Maguire” lo que el cliente quería era un nuevo contrato, un buen contrato, justamente porque no estaba viendo resultados es que le dice a su agente lo siguiente: “Show me the money”. El cliente no quiere que le expliques como van las cosas, el trabajo que haz estado haciendo, quiere que le muestres algo concreto, aquello que va ha resolver sus necesidades.

Esta idea constituye uno de los valores fundamentales del ágilismo. La idea de que más importante que todo lo que se pueda decir sobre un producto o un servicio lo más importante es el producto o servicio en si mismo. Esto no significa que la documentación, los manuales, las estadísticas y todo lo demás que nos permite gestionar los proyectos y especificar el producto no sea importante. Lo que si nos dice es que no debemos desviar la vista del objetivo fundamental, que es proveer a los clientes un producto que satisfaga sus necesidades y al mismo tiempo llene sus expectativas.

Proyecto mal definido

Proyecto mal definido

Hasta aquí no parece haber nada nuevo, “darle al cliente lo que necesita” no es un concepto novedoso. Los problemas aparecen cuando el cliente no tiene ni la menor idea de lo que necesita o bien lo que quiere no se corresponde con lo que necesita. Si nos embarcamos en un proyecto en esas condiciones lo más probable es terminemos como Colón, quien zarpo planeando llegar a un lugar, llego a un lugar que no era el que planea y vivió en la ignorancia de este hecho. Es en estos casos cuando terminamos como expone la documentación clásica los proyectos fallidos.

La solución planteada al problema donde la incertidumbre inicial es alta es el desarrollo iterativo basado en prototipos. Esto tampoco es algo nuevo, en RUP vimos ya este planteamiento, el acierto de las metodologías ágiles se encuentra en la entrega continua de productos al cliente, que le provee retro-alimentación constantemente y le permite reducir la incertidumbre desde etapas tempranas.

El centrarse en entregar un producto funcional por más burdo que sea se diferencia mucho de la descomposición en componentes. Al entregar prototipos de productos completos en lugar partes independientes del producto se acelera el flujo de información clave para dar con soluciones más efectivas. Esto permite que tanto cliente como proveedor puedan evaluar de forma integral el producto, alineando las expectativas del cliente a la realidad y los objetivos de proyecto a las expectativas del cliente.

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 )

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