Nueva relación entre cliente y proveedor: los contratos ágiles

Estructura: en realidad, no es un contrato comercial, sino simplemente un acuerdo entre el product owner y el equipo para un sprint.

Alcance: el equipo acuerda esforzarse al máximo para entregar el conjunto de características acordadas (alcance) con un estándar de calidad definido al finalizar el sprint. El product owner acuerda no cambiar las instrucciones antes de finalizar el sprint.

Riesgo: un proyecto de Scrum puede ser visto como una serie de miniproyectos con parámetros fijos:

• tiempo (duración del sprint),

• alcance (backlog del sprint),

• calidad (definition of done) y

• gastos (tamaño del equipo × duración del sprint).

Tan solo se puede cambiar el alcance y esto se mide en cada sprint.

Estructura: se acuerdan los entregables, se entregan. Se envía la factura. A los clientes les gustan los proyectos de precio fijado porque les da la sensación de seguridad.

Cambios de alcance: el proceso de solicitud de cambios está pensado para limitar el alcance de los cambios. Este proceso es costoso y los cambios en general no se pueden prever. Como el cliente casi por definición quiere más alcance, resulta difícil acabar el proyecto. El proveedor quiere que el cliente esté contento, por lo que el proveedor suele ceder. La palabra etcétera es muy peligrosa para definir especificaciones en un requerimiento de precio fijado.

Riesgo: obviamente todo el riesgo es para el proveedor. Si la estimación es incorrecta, el proyecto pierde dinero. Otros riesgos menos obvios surgen del juego de petición de cambios, en el que el proveedor negocia ingresos adicionales para cambios en el alcance. Si el proveedor subestima muy mal el esfuerzo adicional, o da un precio irreal muy bajo, las pérdidas pueden llegar a afectar a la propia existencia del proveedor, lo que también es un problema para el cliente.

Relación: competitiva. Los clientes generalmente quieren tener más y los proveedores hacer menos. El proveedor quiere que el cliente esté contento, por lo tanto el proveedor acostumbra a ceder.

Estructura: trabajar un mes, después enviar la factura al cliente.

Alcance: no se fija con prioridad. Tarde o temprano, el cliente no querrá pagar más y el proyecto llegará a su fin.

Riesgos: los riesgos los asume 100% el cliente. Los proveedores tienen poca iniciativa para mantener costes bajos. Puede haber un esfuerzo importante para asegurarse de que solo se facturan esfuerzos y gastos legítimos.

Relación: indiferente. El proveedor es feliz cuando hay más trabajo porque más trabajo significa más dinero.

Estructura: financiar entregas cuatrimestrales y aprobar fondos adicionales después de cada entrega exitosa.

Cambios en el alcance: no se definen explícitamente en este modelo. Las entregas están pautadas en el tiempo. Saber que habrá otra entrega el próximo cuatrimestre hace que resulte más fácil posponer una característica para lograr la entrega en el tiempo pautado.

Riesgo: el riesgo del cliente se limita al coste de un único cuatrimestre.

Relación: cooperativa. Tanto el cliente como el proveedor tienen un incentivo para que cada entrega sea exitosa, de forma que se aseguren fondos para las próximas entregas.

Estructura: cualquier presupuesto de proyecto consiste en costes efectivos y ganancia. Las partes acuerdan la ganancia por adelantado (por ejemplo, 100.000 €). Sin importar cuándo se acaba el proyecto, el proveedor recibe ingresos por el gasto incurrido más la ganancia fija acordada.

Alcance: es fijo.

Riesgo: es compartido. Si el proyecto acaba antes, el cliente paga menos y el proveedor obtiene igualmente su ganancia. Si el proyecto se excede de presupuesto, el cliente paga más y el proveedor no tiene ganancia adicional. Después de la fecha de entrega objetiva, el proveedor no puede facturar más ganancias, solo cubrir los costes.

Relación: cooperativa. Tanto el cliente como el proveedor tienen un incentivo claro para acabar antes. El cliente quiere ahorrar dinero y el proveedor tener un margen de ganancia mayor.

Estructura: este contrato funciona con los proyectos de software ágiles porque casi no hay trabajo en progreso. Al final de cada sprint, la funcionalidad está acabada o no se empezó. El trabajo es del tipo time & materials con un objetivo de coste, a menudo con la intención de que el proyecto no use todo el presupuesto. Una vez se entrega cierta cantidad de funcionalidad, el cliente puede darse cuenta de que ya se ha entregado una cantidad suficiente de valor de negocio y que no se necesita más desarrollo, por lo que puede cancelar el proyecto. Hay un gasto de cancelación que es igual a la ganancia restante que faltaba.

Alcance: puede cambiar. Las características planificadas sin implementar se pueden reemplazar por otras historias del mismo tamaño. Las características adicionales cuestan más.

Riesgo: compartido. Ambas partes están interesadas en completar antes el proyecto. El cliente obtiene costes inferiores y el proveedor, un margen más amplio.