No falla, no hay vez en la que participe en una conversación sobre agilidad en una empresa mediana – grande, que quiera dar el salto de proyectos clásicos a ágiles, en la que no salga algo así como… “Y… ¿cómo encajamos un proceso ágil con presupuestos?, nosotros trabajamos con nuestros proveedores en base a modelos de precios cerrados, proyectos a muchos meses”.Este es en mi opinión uno de los mayores obstáculos para que una empresa mediana – grande sea ágil, es decir, para que el sector realmente cambie y se modernice.

Son demasiados años trabajando en base a proyectos cerrados (también demasiados años fracasando), tanto proveedores, como clientes, mesas de compras, etc., se han estructurado así. Demasiada cultura, estructura, costumbres a cambiar. Si bien tengo la esperanza de que años y años tropezando con la misma piedra, haciendo cosas que no funcionan, haga que algunos empiecen a pensar que hay que cambiar, hacer las cosas de otra manera, hay que modernizarse.

Mientras, en el transito, de proyecto cerrado a proyecto ágil, intentando buscar una solución de mínimos, han ido apareciendo diversas estrategias para intentar poner un poco de ambos mundos. En este post que voy a contar dos de esas soluciones, las clausulas “cambios gratis” y “dinero sin hacer nada” (Money for Nothing, para que te recuerde a los Dire Straits). Ambas son de Jeff Sthuerland, co-autor de Scrum (te dejo el post con la Entrevista a Jeff Sutherland), antes de verlas (al final de post, por si quieres ir directamente), charlemos un poco sobre los tipos de contratos.

Los tipos de contratos, en muy pocas palabras

Supongo que sabes de que te hablo, no quiero extenderme aquí, pero por si acaso, cuando hablamos de “precio cerrado”, o “llave en mano” o “contrato cerrado” (fixed-price) estamos hablando de aquel contrato en que el cliente se compromete a pagar al proveedor una cantidad fija, con independencia de el tiempo y coste real que le lleve al proveedor.

Se cierran requisitos en un momento inicial, a muchos meses vista de finalizar el desarrollo, donde muchos de esos requisitos no se necesitan, otros no están u otros están mal especificados, pero contractualmente el cliente no puede cambiarlos más adelante, ya que el proveedor se compromete a hacer el proyecto en un tiempo – precio en base a esos requisitos… ya sabes lo más anti-ágil, anti sentido común del mundo, lo que más fracasos ha producido, etc. Al final el cliente obtiene, y paga, algo que no quería y el proveedor acaba trabajando muchas veces mucho más tiempo – dinero del que pensaba cuando se comprometió, muchos meses atrás, con algo que no era tan fácil hacer.

Sobre este tipo de contrato y sus problemas en el mundo de la tecnología ya hablamos en su momento en aquel popular-polémico post de Contrato cerrado, ¿el peor enemigo del software o mal necesario? (esto te interesa mucho, más que cualquier cosa en la ingeniería software), para ampliar este punto te recomiendo que te lo leas antes de seguir.

En el otro extremo está el contrato conocido como “Bolsa de Horas”, “Pago por Tiempo”, en el mundo anglo más conocido como “Tiempo y Materiales” (Time and Materials), que es, básicamente, aquel tipo de contrato en el que el cliente se compromete a pagar al proveedor en base al trabajo realizado, o por, por ejemplo, por mes de trabajo.

El contrato “Bolsa de Horas” se da más a cambiar requisitos según se detectan necesidades, en más ágil por ello, pero a los clientes no les gusta de nada, pero nada, porque cuando lo mencionas lo primero que te dicen es: “Y cómo sé yo cuanto me va a costar”. O te dicen… “Es que le proveedor me va a engañar y va a alargar los meses de trabajo”, y en ocasiones no les falta razón en pensar así (algún día te contaré unas cuantas sobre esto), y no voy a entrar en el amplio tema de “Si sabes que te pueden engañar… ¿cómo trabajas con ellos?”

Buscando un punto intermedio

Bueno, la idea de la agilidad se estrella con la realidad de que en muchos sitios el contrato por tiempo o bolsa de horas es impensable. Así que muchos han intentado ingeniar ideas intermedias, muchas de ellas suenan menos ágiles que el ideal ágil, pero son mejor que nada y quedarse inmóvil en el modelo de precio cerrado.

De entre varias, dos ideas bastante sensatas son las clausulas de Jeff Sthuerland “cambios gratis” y “dinero sin hacer nada”, aquí abajo te las dejo, y estoy especialmente interesado en tu opinión sobre ellas, espero tus comentarios.

La clausula “Dinero sin hacer nada” (Money for Nothing)

1 – Añade la clausula de “Dinero sin hacer nada”:

– Sólo es operativa sin el cliente sigue las reglas de Scrum.

– Acuerdo mutuo a la hora de estimar requisitos (formalmente items, normalmente historias de usuario).

– De no hacerlo, se anula esta cláusula y el contrato se pasa a “tiempo y materiales” (bolsa de horas, pago por tiempo).

2 – El cliente determina cuándo el desarrollo de un nuevo requisito (o los requisitos restantes) es más costoso que el valor que aportará una vez desarrollado.

3 – El proveedor permite que el cliente rescinda el contrato en cualquier momento obteniendo un 20% del valor de lo que resta de contrato al momento de la rescisión (el cliente deja así de perder un 80% del trabajo que se desarrollaría y que no necesitará).

4 – El proveedor asume el riesgo de entregar tarde trabajos que se han acordado (estimado) mutuamente.

La clausula “Cambios Gratis” (Change for Free)

Su objetivo es incentivar a los clientes a seguir un proceso ágil, se resume así:

1 – Añade la clausula de “Cambios Gratis”

– El cliente debe hacer uso de esta opción trabajando (colaborando, partiipando) con el equipo Scrum en cada Sprint.

– De no hacerlo, se anula esta cláusula y el contrato se pasa a “tiempo y materiales” (bolsa de horas, pago por tiempo).

2 – El Product Owner re-prioritiza la Pila de Producto al final de cada Sprint.

3 – Los cambios están permitidos bajo estas normas:

– Los cambios en las prioridades son gratis sino se cambia la cantidad total de trabajo.

– Nuevos requisitos (formalmente items, normalmente historias de usuario) se pueden añadir de forma gratuita en los límites de Sprint (durante un Sprint, salvo ciertos condicionantes, no se modifica el trabajo a realizar) si esos nuevos requisitos son de igual cantidad de trabajo, normalmente, añadir un nuevo requisito elimina otro de los menos prioritarios.

4 – Requisitos de los clientes:

– Los requisitos (formalmente items, normalmente historias de usuario) son priorizados por valor de negocio y se desarrollan en orden de máximo valor.

– Los usuarios siguen el proyecto de cerca y trabajan con el Product Owner para crear un Product Backlog de calidad.


LEAVE A REPLY