Tanto el cliente como el proveedor de software al inicio de un proyecto de desarrollo de software saben que hay demasiado en juego para trabajar sólo con un acuerdo verbal. Un contrato es en realidad un conjunto de reglas escritas de juego. Las reglas correctas incrementan la probabilidad de éxito para ambas partes. Las reglas incorrectas hacen que la cooperación sea dificil y entorpecen el progreso. ¿Cuáles son los tipos de contratos que existen, y cuál es el mejor enfoque para un proyecto ágil?
En el artículo anterior vimos el propósito y contenido de un contrato, e identificamos distintos criterios para evaluar contratos para proyectos Scrum y ágiles. Allí sugerimos 4 puntos para comparar las distintas formas de contratos:
- ¿Cómo está estructurado el contrato?
- ¿Cómo se gestionan los cambios en el alcance de los requerimientos?
- ¿Cómo se reparte los Riesgos y las Recomensas entre el cliente y el proveedor?
- ¿Qué modelo de relación con el cliente fomenta: competitividad (ganar-perder), cooperación (ganar-ganar), indiferencia (no me importa si perdés) o dependencia (si sale bien yo gano, sino vos perdés)?
En este artículo veremos varios contratos diferentes, analizando cómo funcionan en proyectos ágiles y Scrum de desarrollo de software.
Contrato de Sprint
Para quienes trabajen con Scrum, la metáfora de "Contrato de Sprint" puede ser útil para comprender (¡y a veces forzar!) la relación entre el Dueño del Producto y el equipo de trabajo.
Estructura: en realidad no es un contrato comercial, sino simplemente un acuerdo entre el Dueño del Producto y el Equipo para un sprint.
Alcance: el Equipo acuerda hacer su mejor esfuerzo para entregar el conjunto de características acordadas (alcance) con un estándar de calidad definida al finalizar el sprint (idealmente entregan todo lo prometido, y quizás un poquito más). El Dueño del Producto acuerda no cambiar sus intrucciones antes de finalizar el sprint.
Riesgo: un proyecto de Scrum puede ser visto como una serie de mini-proyectos con parámetros fijos: Tiempo (duración del sprint), Alcance (Backlog del sprint), Calidad (Definición de Terminado) y Costos (Tamaño del Equipo * Duración del Sprint). Sólo puede cambiar el alcance, y esto se mide en cada sprint.
Consejo: confirmar el Contrato del Sprint por e-mail o pegándolo en el proyecto. Tener una Wiki al principio de cada sprint es una buena idea. Ayuda a construir confianza, más allá de la forma contractual subyacente.
Precio Fijo / Alcance Fijo
Estructura: se acuerdan los entregables, se entregan. Se envia la factura. A los clientes les gusta los proyectos de precio fijo porque les da sensación de seguridad (o al menos, eso piensan).
Cambios de alcance: el nombre del contrato lo dice todo, no? El jueguito de pedido de cambios (correción: proceso de pedido de cambios) está pensado para limitar el alcance de los cambios. Este proceso es costoso, y los cambios en general no se pueden prevenir. Como el cliente casi por definición quiere más alcance, puede resultar dificil terminar el proyecto. El proveedor quiere que el cliente esté contento, por lo que el proveedor suele ceder. La palabra "etcetera" es muy peligrosa para definir especificaciones en un requerimiento de precio fijo.
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 cual el proveedor negocia ingresos adicionales por 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 la propia existencia del proveedor, lo cual también es un problema para el cliente.
Relación: competitiva a indeferente. Los clientes generalmente quieren tener más, y los proveedores hacer menos. El proveedor quiere que el cliente esté contento, por lo cual el proveedor suele ceder.
Consejo: especificar los requerimientos funcionales con historias de usuario.
Tiempo y Materiales
Estructura: trabajar por un mes, luego enviarle al cliente la factura. A los proveedores les gusta, porque el cliente corre el riesgo de cambiar sus ideas.
Alcance: no se fija con prioridad. Tarde o temprano, el cliente no va a querar pagar más, y el proyecto llega a su fin.
Riesgos: los tiene 100% el cliente. Los proveedores tienen poca iniciativa para mantener costos bajos. Puede haber un esfuerzo importante para asegurarse que sólo se facturen esfuerzos y gastos legítimos.
Relación: indiferente. El proveedor está feliz cuando hay más trabajo, porque más trabajo significa más dinero.
Consejo: recomendado para proyectos en donde el cliente puede manejar los riegos mejor que el proveedor. Este contrato se suele combinar con un techo de costos. Qué tan bien funcione depende en cómo se gestione el alcance.
Tiempo y Materiales con Alcance Fijo y Techo de Costos
Estructura: igual a la de Precio Fijo / Alcance Fijo, excepto que si el proveedor termina antes, el proyecto cuesta menos, porque sólo se factura el esfuerzo real.
Alcance: igual al de Precio Fijo / Alcance Fijo
Riesgos: desde el punto de vista del cliente este contrato parece representar lo "mejor de ambos mundos". Si se requiere menos esfuerzo del esperado, el proyecto cuesta menos. Y una vez que se alcanza el techo de costos, se comporta como un proyecto de costo fijo.
Relación: dependiente. Desde el punto de vista del proveedor, el objetivo es alcanzar exactamente el techo de costos. No hay ningún incentivo para que el cliente entregue por debajo del costo máximo presupuestado. El cliente probablemente hubiera tratado al proyecto como costo fijo si fuera interno, por lo que tampoco tiene ningún incentivo para achicar el alcance y ahorrar dinero.
Tiempo y Materiales con Alcance Variable y Techo de Costos
Estructura: igual al de Tiempo y Materiales, excepto que el techo de costos limita el riesgo financiero para el cliente.
Alcance: igual al de Precio Fijo / Alcance Fijo.
Riesgos: el presupuesto expirará sin lograr el valor de negocio necesario para el cliente. El cliente no obtendrá todo lo que pide.
Relación: cooperativa. La combinación de un presupuesto limitado y un alcance variable enfoca al cliente y al proveedor en lograr el valor de negocio requerido dentro del presupuesto disponible.
Consejo: este tipo de contrato funciona bien con Scrum. El cliente tiene el control en cada sprint individual. Una relación constructiva quiere decir que, incluso si surgen problemas, las emociones y el foco son las correctas para llegar a una solución de acuerdo mutuo.
Desarrollo por fases
Estructura: financiear entregas cuatrimestrales, y aprobar fondos adicionales luego de cada entrega exitosa.
Cambios de alcance: no se definen explícitamente en este modelo. Las entregas están pautadas en el tiempo. El saber que va a haber otra entrega el próximo cuatrimestre hace que resulte más facil postponer una característica para lograr la entrega en el tiempo pautado.
Riesgo: el riesgo del cliente se limita al costo de un único cuatrimestre.
Relación: coooperativa. Tanto el cliente como el proveedor tienen un incentivo para que cada entrega sea exitosa, de manera que se aseguren fondos para las próximas entregas.
Consejo: los inversores de riesgo suelen trabajar de esta manera. Es una buena mezcla de Tiempo y Materiales con Alcance Variable y Techo de Costos. En el contrato comercial simplemente se especifica el objetivo de la entrega, los costos por hora y el techo de costo. El cliente provee al Dueño del Producto. Todo el resto se determina en los Contratos de Sprint.
Clausulas de Bonus y Penalidades
Estructura: el proveedor recibe unbonus si el proyecto se termina antes, y paga una penalidad si termina tarde. La cantidad del bonus o la penalidad es en función a la demora.
Cambios de alcance: el cambio es dificil de aceptar, porque un cambio potencialmente puede impactar en la fecha de entrega, lo cual no se quiere.
Riesgo: ¿cuál es el incentivo del cliente para que se termine antes? Hay que tener argumentos de ROI fuertes y transparentes. Sino, el cliente tiene una salida facilista cuando las cosas llevan más tiempo.
Relación: podría ser cooperativa, pero puede degenerarse a indiferente si el cliente no necesita realmente al software para la fecha pactada.
Consejo: este contrato se usa bastante en proyectos de construcción (por ejemplo, rutas, túneles, etc.), en donde funciona bien. El cambio de alcance no es un problema, y hay motivos económicos genuinos para que el cliente llegue a las fechas.
Ganancia Fija
Estructura: cualquier presupuesto de proyecto consiste en costos efectivos y ganancia. Las partes acuerdan la ganancia por adelantado (por ejemplo, $100.000). Sin importar cuándo se termine el proyecto, el proveedor recibe ingresos por los gastos incurridos más la ganancia fija acordada.
Alcance: es fijo.
Riesgo: es compartido. Si el proyecto termina antes, el cliente paga menos, y el proveedor igual tiene 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 objetivo, el proveedor no puede facturar más ganancias, sólo cubrir sus costos.
Relación: cooperativa. Tanto el cliente como el proveedor tienen un incentivo claro para terminar antes. El cliente quiere ahorrar dinero, y el proveedor tener un margen de ganancias mayor.
"Dinero por Nada. Cambios Gratis"
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á terminada o no se empezó. El trabajo es del tipo de Tiempo y Materiales con un objetivo de costo, a menudo con la intenciónde que el proyecto no utilice todo el presupuesto. Luego de que se entrega cierta cantidad de funcionalidad, el cliente puede darse cuenta que ya se entregó una cantidad suficiente de valor de negocio, y que no se necesita más desarrollo, por lo cual puede cancelar el proyecto. Hay un costo de cancelación que es igual a la ganancia restante que faltaba.
Alcance: puede cambiar. Las características planificadas sin implementar puede reemplazarse 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 menores costos, y el proveedor un margen más amplio.
Consejo: si se excede el presupuesto, puede aplicarse las reglas de los contratos de Ganancia Fija o Techo de Costos. El enfoque de Ganancia Fija es más consistente con el objetivo de fomentar una relación cooperativa entre las partes.
Joint Venture
Estructura: dos socios invierten en un producto de interés mutuo. Es raro que se transfiera dinero entre las partes en la fase de desarrollo, pero cada parte tiene que tener un ROI, que surge de compartir ganancias o de beneficios de usar el software.
Alcance: se define para satisfacer las necesidades de la asociación.
Riesgo: dos de cada. Las cadenas de decisión pueden ser largas. Pueden surgir rivalidades entre los equipos. Diferentes modelos para extraer valor del producto pueden llevar a distintas prioridades, afectando la predisposición a invertir.
Consejo: tratar el proyecto como una empresa independiente: un equipo, co-ubicado, con roles de desarrollo, marketing del producto y dueño del producto. Hay que pensar realísticamente en escenarios de separación amistosa y no tan amistosa.
Recomendaciones
Trabajé muy bien durante años con contratos de Desarrollo por Fases. El contrato original tenía alcance fijo con techo de costos, pero a medida que trabajamos juntos y creamos confianza, el texto simplemente se olvidaba. Luego, un contrato por sprints y un compromiso cuatrimestral funcionaban muy bien.
El contrato "Dinero por Nada. Cambios Gratis" convierte las ventajas de Scrum y el desarrollo ágil en una ventaja competitiva.
- Al priorizar y entregar valor de negocio de forma incremental, se reducen dramáticamente las probabilidades de un fracaso total.
- Más aún, es un modelo cooperativo, por lo que incentiva a ambas partes a mantener los costos bajos.
- La cláusula de cancelación temprana recompensa la mayor productividad que logren los equipos de Scrum. Por otro lado, este clausula puede verse como un "paracaidas de oro", que podría resultar políticamente molesta en el clima económico actual.
Este contrato puede funcionar también con un techo de costos, a riesgo de perder de la relación de cooperación.
El contrato prepara el terreno para un proyecto exitoso. Y el Manifiesto Ágil lo dice muy claramente: trabajar con el cliente es más importante que el contrato. Así que, sin importar lo que hagas, hay que mantener una relación positiva con el cliente!