Esta es la primera entrega de una serie de tres abordaremos las diferentes alternativas para regular un proceso de desarrollo desde el punto de vista ágil. Comenzaremos viendo los dos contratos más frecuentes: Fixed price y Time and Materials.
Introducción
Un contrato es un acuerdo de voluntades para regular los derechos y obligaciones de las partes que lo suscriben. ¿Y para qué sirven los contratos? Básicamente, para cubrirse las espaldas cuando las cosas no salgan como uno espera.
En el caso del desarrollo de aplicativos informáticos, intervienen dos partes: Un comprador o cliente, que requiere un producto para poner a disposición de sus usuarios, y un vendedor, normalmente consultora o proveedor de servicios que se ofrece a construir tal producto.
El manifiesto ágil establece en sus valores que:
- Preferimos individuos y sus interacciones sobre procesos y herramientas
- Preferimos software funcionando sobre documentación extensiva
- Preferimos colaboración con el cliente antes que negociación de contratos
- Preferimos la adaptación al cambio antes que seguir un plan
Teniendo esto presente, veamos entonces de qué marcos contractuales disponemos para desarrollar productos de software.
Contratos Fixed Price
Se establece un conjunto de requerimientos (scope) y una fecha de entrega, a cambio de un precio. La duración, alcance y precio son fijas. Cualquier funcionalidad adicional o modificación de los requisitos iniciales requerirá un análisis, y afectará tanto al cronograma como al presupuesto. Este proceso de gestión de cambios suele estar diseñado ex profeso para prevenir, limitar y dificultar cualquier cambio de alcance. A pesar de esto, la forma de trabajar se puede pactar como tradicional o pseudo ágil, aunque al final, todo se debe entregar en una fecha determinada.
En los Fixed Price, el cliente fija el alcance, y el proveedor, el coste y el tiempo
En estos contratos, el riesgo recae completamente sobre el proveedor. Este hará un análisis de requerimientos, y en función del esfuerzo estimado, intentará ofrecer una mejor oferta económica que la competencia. Aquí encontramos dos supuestos muy poco probables:
- Que es posible recopilar todos los requerimientos en un momento inicial
- Que es posible predecir el esfuerzo necesario en un momento inicial
Las tres grandes verdades de los proyectos son que es imposible recoger todos los requisitos al principio de un proyecto, que cualquier requisito recogido cambiará y que siempre querremos hacer más de lo que el dinero y el tiempo nos permite. Asimismo, el cono de incertidumbre nos indica que en el momento cero, el esfuerzo real será entre 0.25 y 4 veces el estimado (en mi experiencia nunca he visto valores debajo de 1.25, y esto con mucha suerte).
Variabilidad de la estimación a lo largo del tiempo
Podemos, a primera vista, notar algunos problemas de intereses contradictorios:
- El cliente intentará reducir la oferta del proveedor, ya que asume que este exagera el precio para cubrir sus riesgos.
- El proveedor sabe que habrá muchas ambigüedades en los requerimientos, y cuestiones técnicas oscuras, y por esto, el esfuerzo real será muy superior al estimado inicialmente.
- El comercial que gestiona la oferta, tiene que cumplir unos objetivos de facturación, que pueden ser no realistas, por lo que intentará cerrar la operación de cualquier forma posible (aunque luego no sea factible técnicamente cumplir la propuesta en tiempo o con el presupuesto disponible).
- El asesor técnico del proveedor (técnico de preventa), debe convalidar la propuesta comercial, de lo contrario, será visto como un bloqueo a la venta.
- El cliente desea mantener dentro de su control ciertos aspectos técnicos (por seguridad, criticidad, jerarquías o autoridad). Estos departamentos o silos operan en modo FIFO, con cambios frecuentes de priorización, y afectarán el plan de desarrollo y cronograma propuesto inicialmente.
- Los diferentes sectores interesados del cliente intentarán introducir cambios para su conveniencia, conscientes que el proveedor deberá ceder a la presión para mantener la cuenta.
- El proveedor intentará por cualquier medio entregar un producto que cumpla los requerimientos en la fecha pactada, aunque muchas funcionalidades sean defectuosas o directamente no estén implantadas, ya que luego tendrá un contrato de mantenimiento (BAU o Business as usual), durante el cual podrá, sin presión, solventar estas cuestiones. Es el usuario final quien sufre esta baja calidad.
Una vez transcurrida una parte importante del plazo, y debido a dificultades técnicas emergentes, que no se tuvieron en cuenta al estimar, más los cambios introducidos como “aclaraciones” de requisitos ambiguos, el proveedor aceptará que resulta imposible cumplir la fecha de entrega. Entonces intentará una o varias de las siguientes estrategias:
- Sobre esfuerzos: presionará a los desarrolladores a trabajar más horas diarias e incluso fines de semana, normalmente sin retribución. Esto afectará la motivación y el rendimiento de las personas involucradas.
- Aumentar la capacidad: asignará más personal al proyecto, tanto senior (los “apaga incendios”), como junior (desarrolladores disponibles por estar sin asignación entre proyectos, vistos como costes hundidos). Esto recarga aún más a los miembros del equipo, ya que tendrán que hacer el onboarding técnico de los recién llegados, explicar por qué se han tomado decisiones técnicas, pueden surgir conflictos entre miembros nuevos y originarios, además de complejizar exponencialmente la red de comunicaciones y el esfuerzo de coordinación.
- Negociar una reducción de alcance o un aplazamiento de la fecha. El cliente NO desea recibir menos producto ni recibirlo más tarde, por lo que intentará que las concesiones sean las mínimas. Esto genera un círculo vicioso, ya que con una prórroga de dos semanas, difícilmente se logre encauzar el proyecto y se deberá pedir una nueva prórroga.
Cuando estos contratos se ejecutan en modo Scrum (o pseudo Scrum), es normal que:
- Se produzcan cambios dentro de los Sprint en curso
- Aparezcan bloqueos crónicos originados en dependencias con silos del cliente.
- Haya desfases entre el cronograma planificado y las historias entregadas en los Sprints
- La reunión diaria se convierta en un punto de control, especialmente cuando los retrasos son evidentes
- La reunión diaria se convierta en una discusión sobre cómo solucionar los problemas, y en establecer quienes son los culpables
No es raro que llegado este punto se prescinda de eventos como la retrospectiva y el refinamiento. En casos extremos, se abandona completamente Scrum para intentar cumplir la fecha de cualquier manera posible.
A pesar de estas consideraciones, podemos mencionar casos en los cuales este modelo puede ser muy eficaz:
Desarrollos donde el grado de certeza de los requerimientos es muy alto, y el desarrollo se realizará utilizando una tecnología ampliamente conocida.
Proyectos con un grado de similitud muy alto a casos anteriores, de los cuales se dispone de un histórico de tiempos. Si los técnicos que lo desarrollarán coinciden, las probabilidades de éxito (en tiempo y costes), son aún mayores.
Microdesarrollos o pequeños evolutivos, cuya estimación no supere el umbral de 250 horas. En estos casos, solo se podría ejecutar un Sprint de dos semanas con un equipo de desarrollo mínimo, y un Scrum al uso no sería conveniente (pero sería interesante considerar un contrato de Sprint único para introducir el marco en la organización).
Proyectos que no están relacionados con el negocio de la organización, son inusuales y el aspecto técnico no es familiar. Estos se pueden encuadrar dentro de proyectos llave en mano/fixed price y ser desarrollados por organizaciones especializadas.
Contratos Time and Materials
El cliente define las necesidades de conocimientos y habilidades para ejecutar un proyecto. Luego, comunica este requerimiento a diferentes proveedores, intentando maximizar la relación calidad/precio.
Los proveedores intentan colocar su personal disponible, acentuando los aspectos positivos y minimizando cualquier carencia (herramientas, experiencia, metodología, formación) de los candidatos. En pocas palabras, intentará conseguir el mejor precio por los especialistas menos atractivos para el mercado.
Los proveedores ofrecerán propuestas de uno o más “recursos” por un precio diario u horario. La variabilidad en el desempeño de una persona en diferentes entornos o equipos no es tenido en cuenta.
Una vez cerrado el acuerdo, el interés del cliente es acabar lo antes posible, ya que el coste total es en función de los días incurridos. Por su parte, el proveedor no tiene ningún incentivo en acabar antes, ya que cuanto más se extienda el proyecto, mayor rédito obtendrá.
Estos contratos pueden también desarrollarse de manera tradicional o agile.
En caso de ejecutarse como Scrum, observamos los siguientes puntos:
- No suele haber continuidad de las personas en el equipo. De hecho, suelen ser equipos ad hoc, que se crean y se destruyen para un proyecto en particular. Cualquier mejora en la forma de trabajo o la velocidad se pierde al finalizar.
- El desarrollador no recibe ninguna formación en Scrum (aunque puede haberla adquirido con anterioridad)
- No se tienen en cuenta las aportaciones de los desarrolladores, ya que no son parte de la organización.
- No suelen ser equipos cross funcionales, sino más bien expertos en una función o tecnología.
A pesar de lo expuesto anteriormente, es posible contratar un equipo de desarrollo Scrum, incluso con un Scrum Master. Esto no cambia la ecuación, en el sentido que aún así no tienen incentivos para finalizar antes o en fecha. Dicho esto, también se suelen apreciar las mismas disfuncionalidades organizacionales y de proceso del Fixed Price (dependencias, cambios de alcance, figuras jerárquicas, desfasajes con un planeamiento temprano no realista, y los consiguientes sobre esfuerzos o aumentos de capacidad). La diferencia es que en este caso, es el cliente quien sufre las consecuencias.
Como se puede ver, en esta modalidad, la totalidad del riesgo está del lado del comprador. Adicionalmente, puede encuadrarse judicialmente como “cesión de trabajadores”.
Finalmente, podemos identificar algunos casos en los que un Time and Materials puede resultar perfectamente adecuado:
En áreas de flujo de trabajo constante, se suele requerir aumentos de capacidad en períodos específicos. Los sistemas Pull como Kanban pueden operar de manera secuencial, y cuando se presentan cuellos de botella temporales incorporar personas en modo Time and Materials es una solución eficaz.
Cuando es necesario añadir a un equipo Scrum un especialista para cubrir historias infrecuentes, y que se encuadran dentro de un sprint o release en particular. Cuando el marco temporal es claramente acotado, la curva de aprendizaje es abrupta, y el conocimiento generado no es de valor para la organización, podemos recurrir a este contrato.
En nuestra próxima entrega discutiremos los contratos por Sprints y las cláusulas Money for nothing y Changes for free.
Pincha en este enlace para ver la segunda parte
Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-SinObraDerivada 4.0 Internacional.