Ágil para lo que le conviene, o cómo gestionar riesgos colaborativamente

construyendo-juntosMi cliente dice que quiere trabajar ágilmente, pero me pide una fecha y un presupuesto para el proyecto.

Mi proveedor lleva ya 10 semanas trabajando y todavía no terminó la versión inicial del producto, la cual dijo que nos entregaría de forma temprana.

Este es un artículo sobre las relaciones entre proveedores y clientes, las cuales en general están enmarcadas en contratos, los cuales pueden determinar el tipo de relación que tendrán durante el proyecto.

Todo es muy lindo cuando se leen o escuchan los valores y los principios ágiles, pero “en la realidad” la poesía se vuelve algo dramática, si no tenemos en cuenta algunos temas.

Los escenarios, desde los puntos de vista del proveedor y del cliente

El riesgo más habitual del lado del proveedor:
Todos los proveedores conocen y mitigan, sí o sí, un riesgo: “El proyecto que están presupuestando no será rentable“. Nadie quiere trabajar para perder dinero. Entonces, a la estimación, se le suele agregar un colchón, también llamado buffer. Es decir que, casi siempre, se “infla” el precio y el tiempo del proyecto. Y lamentablemente, ese tiempo suele consumirse como parte del proyecto. Todos saben que existe ese colchón, aunque no se explicite en cada oportunidad.

El riesgo más habitual del lado del cliente:
Todos los clientes conocen y mitigan, sí o sí, un riesgo: “El proyecto terminará y no tendremos lo que queríamos”. Nadie quiere empezar un proyecto sabiendo que no resolverá los problemas que tenemos. Entonces, a la hora de iniciarlo, buscaremos que el proveedor nos asegure cuánto nos costará y cuánto tiempo tardará en hacer el trabajo pre-fijado. Es decir que se buscan fijar todas las variables: Costo, Tiempo y Alcance. Y lamentablemente, esas variables no son fijas y suelen alterarse… todas o casi todas.

Algunos mecanismos para co-crear relaciones colaborativas, desde los contratos colaborativos

Si queremos llevar adelante un proyecto exitosamente, debemos pensarlo bien desde el momento en el que acordamos los términos contractuales. Un contrato colaborativo (también llamado “contrato ágil”) establece reglas no nocivas y provee a las dos partes mecanismos de trabajo y de resolución de conflictos.

Si ya sabemos que hay riesgos que nos quitan el sueño (los mencionados u otros que sean más específicos en situaciones particulares), una estrategia que nos permite colaborar durante el proyecto, es explicitarlos al inicio del proyecto para poder pensar de forma conjunta un plan de mitigación.

Que todo el equipo del proyecto conozca bien al cliente, al negocio y a la tecnología puede ayudarnos a mitigar el riesgo de no terminar a tiempo. Que el equipo se conozca trabajando antes del proyecto que arrancaremos, también nos puede ayudar en esa misión. Esto se puede plantear como una parte del proyecto y algunas de las mencionadas, pueden colocarse como actividades a llevar adelante al inicio del proyecto, incluso se pueden colocar en el mismísimo contrato.

Visualizar tanto el trabajo realizado como el que queda pendiente, en cada día y en cada semana del proyecto, puede ayudarnos a mitigar el riesgo de no resolver el problema: nos permitirá ajustar el alcance a tiempo y prever cambios de calendario y presupuestos de forma oportuna. También los anteriores mecanismos que involucran al equipo de trabajo pueden ayudarnos a mitigar este riesgo potencial.

Otra forma es que un experto del negocio esté disponible un ratito de cada día y algunas horas de cada semana, para que pueda re-priorizar dinámicamente las características de la solución. Este requerimiento de disonibilidad se puede colocar en el contrato. No queremos que el problema se quede sin resolver, entonces lo atacaremos a partir de su raíz, aplicando el Principio de Pareto (siempre estar atentos, para identificar cuál es el 20% del trabajo que resolverá el 80% de mi problema).

Algo que ocurre mucho en proyectos pseudo-ágiles, es que los equipos realizan un trabajo que no puede ser validado por el cliente ni el usuario sino hasta muy tarde en el proyecto. Esto hace que la retroalimentación, también llamada feedback, llegue demasiado tarde y el re-trabajo sea muy costoso. Con la anterior cláusula, se mitiga este problema y se aprovecha mejor cada día y cada semana de trabajo del equipo.

La clave es que no hay una sola clave, sigamos aprendiendo juntos

Así como estas recomendaciones, existen muchas otras, las cuales se pueden expresar de forma explícita en el contrato que rige el comportamiento de los proveedores y los clientes durante los proyectos que los unen.

Espero que este artículo pueda serle útil a la comunidad y a la industria, y también espero que compartan conmigo otras técnicas que les hayan sido útiles y qué cláusulas han agregado en sus contratos para lograr relaciones de confianza y proyectos exitosos.


¡Aguardo sus comentarios!

Si te interesó este artículo, también podés leer un artículo relacionado, que escribió Ricardo Colusso, al respecto de tipos de contratos.

Anuncios

Comentarios, Ideas, Críticas constructivas, Feedback?

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