CONTRATOS CON SCRUM

Acordando la realización de proyectos cerrados con Scrum 

Sergio Fernández (@artabricus)

“La parte contratante de la primera parte, será considerada
como la parte contratante de la primera parte”

Un día en la ópera (1935)

 

Como responsable de proyectos siempre me ha parecido que la parte más complicada del ciclo de vida de un proyecto es establecer un contrato entre un cliente que quiere un producto o una solución y la empresa de desarrollo. En innumerables ocasiones he tenido que alcanzar compromisos sobre entregables, funcionalidades, niveles de rendimiento o de falta de errores que “tendrán” que suceder muchos, muchos, MUCHOS meses después de la escritura del contrato. Esto, que ya en si mismo me pone los pelos de punta, se ve empeorado por la reiterada experiencia que esas expectativas (o requerimientos) del proyecto cambiarán múltiples veces a lo largo de la vida del proyecto, dado que “solo” te piden cambiar un par de líneas en un papel... trivial, ¿no?. Mi conclusión: los proyectos rara vez cumplen lo acordado en el contrato, obligando al equipo a sobreesfuerzos no entendidos y obteniendo a cambio gran insatisfacción por parte de los clientes porque sus expectativas funcionales y temporales no se ven satisfechas.

El desarrollo de software es un proceso de carácter puramente humano. Esto es, definido e implementado por personas, lo cual le convierte en un proceso donde la incertidumbre es inevitable. Históricamente esta incertidumbre se ha "cubierto" a través de una protección de los recursos principales, normalmente esta protección conlleva a cambio un "buffer" asociado a estos recursos (equipo, tiempo, budget, scope) o lo que es lo mismo a una sobredimensión de los mismos. Una sobredimensión típicamente mal digerida en una relación entre proveedor y suministrador. 

La adopción de filosofía ágil para afrontar de forma global cualquier tipo de proyecto ha cambiado drásticamente esta perspectiva. Aunque esto no quiere decir que el contrato desaparezca, pero si se reduce su importancia a cambio de un mayor compromiso, transparencia y colaboración con nuestros clientes. El contrato se creará, obviamente, con unos requisitos, un presupuesto y una duración determinada. Además, y en la medida de lo posible, será el equipo de desarrollo el que "pesara" las funcionalidades y requisitos que aparecerán en dicho contrato, de la misma manera que lo harán con las entradas del Backlog durante la ejecución del proyecto. En el caso de que el equipo de desarrollo no esté disponible, o aun no haya sido decidido en este momento del proyecto, la revisión conjunta de esta lista ponderada de requisitos será una de las primeras actividades a realizar.

Eso si, al comenzar el desarrollo ágil, la implicación del cliente permitirá que estos requisitos iniciales no tendrán que ser inmutables y, de hecho, se espera que no lo sean (y así lo que antes era un problema casi insalvable, ahora se convierte en un beneficio) pudiendo cambiarse por otros de un “peso” equivalente. Siempre de forma transparente y colaborativa. Con todo esto se rompe el paradigma del triángulo de hierro abriendo el vértice del Scope.

Personalmente, y una vez aclarado el planteamiento de los requisitos definidos dentro del contrato, soy muy partidario de incorporar un "buffer" de seguridad al scope inicialmente especificado en el contrato. Si bien, esto que, históricamente ha constituido un problema, con la aproximación ágil no lo es. El cliente se garantiza con esta aproximación que el producto obtenido al final del proceso será aquel con el mayor valor de negocio posible (según sus propios criterios) por lo que el "buffer" negociado siempre será aprovechado en aras de proporcionar el máximo valor posible del producto.

Por otro lado, algunos clientes (¡y muchos jefes de proyecto!) tienden a comúnmente a confundir este cambio de paradigma con trabajar en unas bases de “time and materials”. Nada más alejado de la realidad, los compromisos con nuestros clientes son constantes, antes y después de cada iteración, y mucho más férreos al ser más realistas y tener la implicación de todas las partes. Se podría ver como la sustitución de un contrato a largo plazo, por múltiples contratos reflejados, por un lado, en el BackLog y por otro lado en las reuniones de Sprint, tanto para su planificación como para su revisión.

 

A modo de resumen, se podría decir que el paradigma de un contrato ágil se sustenta en cambios como los siguientes:

 

Requisitos fijos -> Requisitos iniciales intercambiables.

Hitos -> Incremento constante de valor.

Análisis de riesgos -> Evaluación continua del producto. ¡¡Kaizen!!

Contrato -> Colaboración y transparencia.

 

Estos cambios en el paradigma nos están llevando poco a poco a proveedores y clientes a alcanzar una manera diferente de definir y afrontar los proyectos anteponiendo la colaboración a los contratos y poniendo el foco en el valor de los resultados.

 

 

Deja tus comentarios

Enviar un comentario como invitado

0
  • No se han encontrado comentarios