Por qué los contratos de alcance fijo pueden paralizar tu innovación

(Traducción de “Why fixed scope contracts might freeze your innovation” de Nicolás di Tada)

Lo que te mete en problemas no es lo que no sabés; es lo que creés que sabés, pero no es cierto — Mark Twain

Desarrollar sistemas de software — y, me atrevería a decir, cualquier tipo de sistema — implica dominar las artes de la incertidumbre y la complejidad.

• incertidumbre, porque es imposible saber todo lo que vas a necesitar saber al inicio de un proyecto. Tenemos que tomar decisiones incluso sin tener toda la información necesaria, o cuando la información disponible es ambigua.
• complejidad, porque cualquier proceso no trivial involucra a muchas partes interesadas en flujo constante. Y el contexto de esas partes interesadas no tiene antecedentes idénticos. Tendemos a pensar que, si hay complejidad un proyecto, entonces hay algo mal ahí, y que nuestro trabajo es “simplificarlo”. En realidad, la verdad es bastante lo opuesto: si ignoramos que la complejidad existe y no aprendemos a navegarla, vamos a tomar las decisiones incorrectas. (Por complejidad nos referimos a una situación en la que no hay relaciones obvias de causa-efecto, y donde las partes interactúan de modo tal que no aceptan un enfoque reduccionista)

Un contrato de alcance fijo (uno donde hay una lista prescriptiva de entregables concretos, bien definidos) no permite lidiar con la incertidumbre y la complejidad. Sin embargo, en muchos de los proyectos en que trabajamos, los contratos de alcance fijo y precio fijo suelen ser los preferidos por los clientes. Esto es entendible: “Si sé cuánto voy a pagar, y qué voy a obtener a cambio, entonces no hay riesgo”.

El problema es que las tres cláusulas en esa frase son completamente falsas: no sabés cuánto vas a pagar, no sabés qué vas a conseguir a cambio, y hay riesgo.

Dejame explicarte por qué.

Requerimientos y especificaciones

Un contrato de alcance fijo y precio fijo sólo funciona bien cuando estás comprando una cosa ya hecha o un commodity. Ya sabés qué vas a conseguir, y ya sabés que eso es lo que necesitás. Pero eso no es cierto en un sistema de software.

Para entender por qué, separemos lo que define a un sistema en dos partes: los requerimientos y las especificaciones. Hay una línea fina entre uno y otro, y muchas veces los requerimientos terminan fundiéndose en las especificaciones. Para este análisis, definamos a los requerimientos como la explicación del problema, y las especificaciones como la descripción de la solución al problema.

Veamos un ejemplo

Requerimiento: subir a una plataforma de 10 metros de altura.

Especificación: fabricar una escalera fuerte de 10 metros de altura.

Ahora, para cualquier problema/requerimiento dado, existen múltiples especificaciones/soluciones que pueden funcionar:

Requerimiento: subir a una plataforma de 10 metros de altura.

Especificación: construir un jetpack que pueda volar hasta 10.5 metros hacia arriba.

Y ahí es donde el contrato de alcance fijo y precio fijo entra en problemas: para poder estimar un precio para cierto alcance, estamos forzados a asumir ciertas especificaciones.

Nadie puede estimar un presupuesto preciso únicamente basándose en los requerimientos (a menos que te imagines la solución más complicada posible al problema, y armes tu presupuesto en base a ella). Un problema, no importa cuán bien lo definas, no tiene un esfuerzo asociado: el costo de una escalera es muy diferente del de un jetpack.

Cuando creás una lista detallada de especificaciones de antemano (por ejemplo, la pantalla X debe permitir a la usuaria ingresar este valor y después…), estás escondiendo bajo la alfombra la inevitable realidad de que no sabés qué se necesita. No sabés hasta que no investigues con tus usuari@s, construyas un prototipo, lo pruebes, iteres el concepto, se lo des a tus usuari@s y lo veas funcionar en el mundo real. Crear la ilusión de certidumbre respecto a las especificaciones es muy peligroso.

Como cliente, cuando pedís una propuesta de alcance fijo y precio fijo, estás creando un dilema epistemológico; tu proveedor se ve forzado a elegir entre dos opciones:

• Darte una propuesta con una mentira precisa — es decir, un costo estimado para un alcance detallado;
• Convencerte de lo real que es la incertidumbre — el hecho de que no sabés exactamente qué es lo que van a construir juntos.

La buena noticia es que hay mejores opciones, dependiendo de tu situación.

Situación #1: tenés un presupuesto fijo

En esta situación, el mejor curso de acción es compartir cuál es ese presupuesto. La reticencia a esto generalmente viene de que “si digo cuál es mi presupuesto máximo, van a estirar la propuesta hasta alcanzar exactamente esa cantidad”. Pero es exactamente así como deberías encarar este problema internamente: ¿cuál es la mejor solución que puedo conseguir a mi problema teniendo este presupuesto?

Si te preocupa que existan formas más económicas de solucionar el problema, entonces podés pedir dos alternativas: ¿qué podemos hacer para solucionar este problema con $20, y qué con $40? Compará ambas opciones y decidí si la más barata sigue siendo suficiente.

Situación #2: tenés que conseguir fondos

En otras situaciones, puede que no tengas los fondos disponibles para el proyecto, y tengas que salir a conseguirlos. En ese caso, la mejor manera es tener un primer pequeño acuerdo inicial para explorar el problema y exponer algunas potenciales soluciones. Si lo estructurás correctamente, vas a tener dos resultados útiles para tu recolección de fondos:

• Un mejor entendimiento del espacio del problema con el que estás lidiando, lo que redunda en una mejor estimación del esfuerzo requerido
• Algún tipo de prototipo, maqueta o material visual para comunicar mejor el problema que estás atacando, y los razonamientos que guiaron las distintas posibles soluciones

Situación #3: tenés una fuente de financiación contínua

Algunos modelos de negocio pueden implicar que tenés a tu disposición cierto presupuesto que podés invertir en tu problema. Este es un excelente escenario para un contrato ágil: definís el tamaño del esfuerzo mensual que podés pagar, y construís tu sistema iterativamente hasta que estés satisfecho con él. La crítica más común a esto es “¡Pero nunca voy a saber cuándo terminé!”. Eso no es cierto: ni bien veas el resultado de la primer iteración (y eso debería ser pronto, a menos de un mes de trabajar con una buena organización ágil), deberías estar en condiciones de extrapolar con bastante facilidad cuántos de esos ciclos vas a necesitar hasta tener el sistema que querés.

Algunas buenas prácticas

Sin importar por qué ruta vayas, o incluso si no tenés alternativas más que hacer un contrato fijo, estas son algunas prácticas que encontramos útiles.

Aceptá la incertidumbre

Tu entendimiento de la realidad es y será siempre difuso. Podés trabajar para mejorar la definición de los límites que te son relevantes, pero si intentás tener certezas de todo, lo estás haciendo mal.

Aproximadamente bien, no precisamente mal

Entendé la diferencia entre precisión y exactitud: en la incertidumbre, más preciso suele implicar menos exacto.

La estimación de la duración de un proyecto puede ser muy exacta si se le permite ser imprecisa: “esto nos va a llevar entre 2 y 5 meses”. Comparalo contra un estimado preciso pero inexacto: “esto nos va a llevar 2.5 meses”. Si el proyecto terminara durando 4 meses, ¿cuál estimación hubieras preferido en retrospectiva? Si para ciertos hitos del proyecto necesitás números más precisos para tomar una decisión, invertí esfuerzo en reducir la incertidumbre asociada.

Estimá en la incertidumbre

Aprendé a estimar con incertidumbre: todo puede ser estimado en cualquier etapa de conocimiento, asumiendo que aceptes cierta falta de precisión.

Entendé tus supuestos

Para cada cosa que creés que va a funcionar, siempre hay una lista de supuestos que estás dando por hecho: listalos. Frená recién cuando llegues a “las leyes de la física van a seguir aplicando”; esa es bastante segura.

Desafiá tus supuestos

Pensá maneras de verificar que tus supuestos sean ciertos. Si el terreno no va a soportarlo, es mucho mejor cambiar el diseño de un edificio en la pizarra que esperar a que se caiga durante la construcción.

Abrazá la ambigüedad

Retrasá las decisiones hasta el último momento responsable. Este es un arte delicado: no querés frenar el avance por demorar una decisión. Pero si esa decisión no está en el camino crítico, entonces es mejor esperar hasta tener un mejor entendimiento de la superficie del problema.

Espero que esto aporte algunas ideas para que proveedores y clientes encuentren mejores maneras de contratar en sistemas complejos. Me encantaría leer otras ideas — ¡dejá tu comentario!