Los cambios exponenciales precisan la inspección y adaptación de los contratos tradicionales
La era digital está obligando a las organizaciones a evolucionar la forma en que construyen software, transformando sus organizaciones para adaptarse a esta nueva realidad; no importa el tamaño o el sector de las organizaciones. Todas deberán acometer en menor o en mayor medida un proceso de transformación.
La reducción de costes asociados a la globalización, la feroz competencia entre organizaciones que obligan una rápida puesta en el mercado de sus productos, la permanente puesta en el centro del cliente final (customer-centric), que obliga a adaptar constantemente el producto a sus necesidades, son claros factores que amenazan la forma tradicional de producir software en las empresas: dejan de tener sentido proyectos planificados a medio o largo plazo, en los que de manera predictiva se planifican todas las fases del desarrollo, limitando el alcance, el plazo y el presupuesto para la construcción del producto, asumiendo que pocos cambios serán introducidos en dicho plan y que cuando, irremediablemente se producen, constituyen una de las principales fuentes de conflicto entre el cliente y su proveedor
En esta transformación las empresas deben contar con proveedores que las acompañen durante todo el proceso de cambio, a través de paradigmas ágiles basados en la transparencia, la inspección y la adaptación, que son los pilares del proceso empírico o aprender con la experiencia.
Esto debe aplicar también en la elaboración de los contratos ágiles, donde se establezcan ciclos de inspección y adaptación en los que mejorar y adaptar dichos contratos a la situación cambiante en cada momento.
Contratos ágiles vs contratos tradicionales
El tipo de contratos utilizados hasta ahora (Time & Materials y Fixed Price) evidencian que están lejos de satisfacer enteramente al cliente y al proveedor. En este tipo de contratos basados en el “triángulo de hierro”, cualquier cambio en alguno de sus componentes afecta negativamente al éxito del proyecto, por lo que esos cambios por pequeños que sean, constituyen un punto de dolor en las relaciones proveedor-cliente.
Además, desde la perspectiva “customer-centric” el éxito de un proyecto/producto ya no se mide por acabar las funcionalidades que se acordaron al comienzo del mismo, dentro del presupuesto y en el plazo previsto, sino a partir de la satisfacción del cliente final: el rol que juega la calidad en el producto tiene el papel preponderante que nunca debió abandonar utilizando enfoques tradicionales.
Por tanto, se requiere pasar de un modelo cliente-proveedor a un modelo de Partnership que solo será posible si se construye sobre los pilares de la transparencia y la confianza mutuas, que permita adaptar el producto sobre la marcha a las necesidades cambiantes de los clientes, adaptando tanto el presupuesto como el alcance y los plazos. De esta forma, el triángulo de hierro pierde rigidez y se da un papel preponderante a la calidad del producto construido.
Adaptar los contratos de precio fijo o cerrado (Fixed Price)
El tipo de contrato Time & Materials suele ser el habitualmente preferido por los proveedores, ya que el riesgo lo soporta directamente el cliente en su totalidad: el proveedor no tiene ningún incentivo en terminar antes ni en mantener bajos los costes.
Por otro lado, el tipo de contrato Fixed Price es el que suelen preferir los clientes: una vez pactados el alcance y el coste, el riesgo lo asume el proveedor en su totalidad: si tarda más perderá dinero, ya que su beneficio es mayor si termina antes. Aquí entra en juego la lucha por los cambios no previstos en el alcance: el cliente requiere cambios que el proveedor se niega a incluir en el contrato actual por no estar contemplados inicialmente… se disparan los costes.
Como vemos, ambos enfoques son asimétricos: el riesgo lo soporta una de las partes en cada caso. Esta situación pone en peligro la relación de partnership ideal, y acabamos en la tradicional relación cliente-proveedor, basada en la desconfianza mutuas y en la que la transparencia no existe: reuniones de seguimiento cada vez más frecuentes en las que se revisa el progreso y el coste de desarrollo real incurrido, procesos de gestión de cambios, incurriendo en costes adicionales para las partes, etcétera.
Jeff Sutherland, uno de los creadores de Scrum y que participó en la elaboración del Agile Manifesto, propone añadir un par de cláusulas a los contratos de Fixed Price convirtiéndolos en un híbrido entre Fixed Price y Time & Materials, para balancear los riesgos y permitir cierta flexibilidad a ambas partes.
Cláusula de Jeff Sutherland número 1: Changes for Free
El cliente puede cambiar el alcance sin que suponga un coste adicional. Los nuevos trabajos reemplazarán otros trabajos pendientes contemplados en el alcance original, que aún no hayan sido acometidos y que supongan un esfuerzo similar, de manera que el coste total original no se ve afectado.
Para que la opción de cambiar el alcance por el cliente sin coste adicional pueda ser ejercida, hay que asegurar las siguientes cuestiones:
1) Se utiliza un contrato estándar Fixed Price que incluye un Time & Materials para los cambios.
2) El cliente puede ejecutar esta opción siempre y cuando colabore con el Scrum Team en todas y cada una de las iteraciones.
3) Si se incumple el marco de trabajo de Scrum, esta cláusula se anula y el contrato será de tipo Time & Materials.
4) El Product Owner reprioriza el Product Backlog al finalizar cada iteración.
5) El Usuario colabora estrechamente con el Product Owner para producir un Product Backlog de calidad.
6) Las Features son priorizadas por valor de negocio e implementadas en orden de mayor valor.
7) Cada cambio se indica con una somera ampliación del contrato.
Cláusula de Jeff Sutherland número 2: Money for Nothing (finalización temprana)
El cliente puede terminar el contrato al finalizar cualquier iteración: si el coste de continuar con el desarrollo es mayor que el valor adicional que se obtendrá, el cliente puede decidir no continuar, parar los trabajos y finalizar el contrato antes de la fecha de fin originalmente acordada.
En este caso, ambas partes tienen el incentivo de terminar el proyecto lo antes posible.
Para que esta cláusula pueda ser ejercida, hay que asegurar las siguientes cuestiones:
1) Se utiliza un contrato estándar Fixed Price.
2) El cliente determina el punto de corte de ROI en el que la implementación the las restantes Features cuestan más que el valor que aportan.
3) El cliente sigue las reglas Scrum.
4) Existe un acuerdo en las estimaciones de todos los ítems de trabajo.
5) El proveedor permite la terminación del contrato en cualquier momento con una compensación del 20% del valor de contrato restante.
6) El proveedor asume el riesgo de la entrega tardía el trabajo acordado con el cliente.
7) Como en el caso anterior, si se incumple el marco de trabajo de Scrum, esta cláusula se anula y el contrato será de tipo Time & Materials.
Adaptación de los contratos tradicionales combinando estas cláusulas
Una posibilidad aún mejor que utilizar estas cláusulas por separado, es combinarlas para adaptar el típico contrato Fixed Price que es el que prefieren los clientes, balanceando riesgos entre las partes intentando lograr esa relación de partnership a largo plazo que buscamos.
No podemos establecer una regla general que nos sirva para todos los clientes/proveedores y en todos los casos, por lo que se requiere conocer con mayor profundidad el ámbito o entorno del proyecto, la relación previa entre el cliente y el proveedor y las características del producto o servicio a proporcionar. Solo después de este análisis se podrá enfocar la relación de partnership con la modalidad de contrato más adecuada en cada caso.
No obstante, su aplicación no está exenta de controversia y dificultades: cuestiones acerca de cómo podemos estimar a priori un backlog entero con muy poca información, qué equipo será necesario y cuán maduro es ese equipo, como conocemos el valor de negocio de las Features que queremos desarrollar, qué grado de confianza existe actualmente entre las partes, etcétera, aparecen pronto en el horizonte y deben ser cubiertas para afrontar el reto colaborativo con la mayor confianza posible y mayores garantías de éxito.
Fuente: Agile Contracts: Money for Nothing and Your Change for Free (scruminc.com)
