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 cláusula 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 cláusula de “Cambios Gratis”
– El cliente debe hacer uso de esta opción trabajando (colaborando, participando) 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.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Buenas, en principio me parece interesante, pero no termino de entender los conceptos ¿algún link donde leer sobre ellos?
gracias
http://www.proyectosagiles.org/contrato-agil-scrum
Yo he tenido oportunidad de usar lo que me gusta llamar «gallinas que entran por gallinas que salen», aunque antes d llegar a eso, como cliente, incluyo una cláusula que indica que puedo desviarme hacia arriba de la estimación total del proyecto un 10 o un 15%, teniendo que ser asumido ese coste por el adjudicatario. Naturalmente que en cualquier caso estas desviaciones han de ser argumentadas cuidadosamente (por ejemplo, la detección de una nueva necesidad de vital importancia en mitad del desarrollo, o una modificación en una ley a última hora). De igual manera, si la desviación se debe a una mala estimación del adjudicatario, este también se haría cargo. Al final se traduce en reconocer que existe un riesgo, acotarlo y obligar al adjudicatario a gestionarlo. Éste, normalmente, lo que hará será incluir la gestión del riesgo en la oferta económica (puede que sea un poco más caro, pero en mi caso lo prefiero a que no quieran modificar nada y al final la sensación sea de producto incompleto).
La verdad es que es difícil incorporar mecanismos ágiles a la contratación, y más en la administración pública (en mi caso)… Se admiten más sugerencias!
Me parece un tanto perversa esa clausula, porque por un lado impulsas flexibilidad en el alcance, pero lo más seguro es que la ponderación de la oferta económica sea sobre un 50% lo que obviamente genera una competencia por precios entre los oferentes. Entonces pides más por menos lo cuál es crónica de una muerte anunciada en el resultado del proyecto porqué una de las cosas que hará el proveedor es poner profesionales de bajo costo para tener una oferta competitiva.
Me parece que lo justo es compartir el riesgo y las ganancias y entender que la incertidumbre no tiene porqué afectar el precio, sino que deben existir mecanismos de negociación justos para ambas partes.
Sugerir que un proveedor tenga que aceptar un aumento de hasta el 15% en el alcance (por muy justificado que sea), a mi me parece que evidencia una falta de prolijidad en la definición de los requerimientos. Entonces al final le estas pidiendo al proveedor que aprovisione y traspase al precio el costo de tu ineficiencia.
La clausula que denominas cambios gratis puede dar lugar a controversias si no ha quedado definido perfectamente en el contrato la forma en la que realizará la aceptación de cada entrega. No obstante, es genial que se introduzcan elementos frescos en la contratación que permitan a las empresas decantarse por la metodología ágil.