¡Nuevo episodio de Scrum Manager Podcast! También disponible en Spotify e iVoox.
Aunque ya hablamos de contratos ágiles en este blog, queremos concretar el tema de contratos y agilidad. Hoy nos centramos en cómo firmar acuerdos de forma que los cambios sean bienvenidos y no algo a evitar.
Recordad que las transcripciones de todos los episodios estarán disponibles en el blog, e iremos subiendo a ritmo de sprint: cada par de semanas. ¡No dudéis en sugerirnos temas sobre los que os gustaría profundizar en los comentarios!
Transcripción
¡Hola y bienvenidos! Hoy vamos a hablar sobre contratos ágiles, y cómo negociar este tipo de acuerdo con un cliente que nunca ha trabajado con agilidad.
Como ocurre con la gestión de proyectos, los contratos ágiles tratan de encajar en una realidad marcada por modelos tradicionales. Para ello modifican algunos de los elementos típicos a través de principios ágiles, de forma que los cambios sean posibles y ofrezcan oportunidades de mejora, en lugar de generar costes adicionales y rozamiento administrativo.
¿Qué significa que modifican sus elementos a través de principios ágiles? Significa que aplican la filosofía del Manifiesto Ágil. Por ejemplo: dan importancia a la flexibilidad, a la colaboración directa, la comunicación frecuente y la confianza. Pero lo hacen sin perder de vista los intereses de proveedor y cliente, y que un contrato debe servir para protegerlos. Podría decirse que todos estos contratos son híbridos, ya que mantienen elementos de los contratos tradicionales, pero los combinan con soluciones que dan respuesta a las necesidades de la gestión ágil.
¿Cómo se elabora un contrato ágil?
Eso dependerá del proyecto y las condiciones en las que éste se desarrolle. Es decir, que no existe EL contrato ágil. No hay un modelo único, que sirva para cualquier proyecto. Lo que sí hay son algunos modelos y cláusulas que pueden usarse como base o inspiración. Cada contrato depende de factores como el tipo de cliente, su presupuesto, el tamaño y la complejidad del proyecto, la situación de la empresa, la relación entre cliente y proveedor…
Por ejemplo, para un proyecto sencillo y de corta duración se puede emplear un modelo de contrato por sprint o por sprints. Pero si estamos hablando de una colaboración a muy largo plazo, pueden interesar otros modelos.
Aunque no hay una plantilla o fórmula mágica, hay modelos de contratos ágiles y cláusulas que pueden ayudarnos a diseñar el nuestro. Por ejemplo, el contrato por sprints. Hay otros como el contrato ágil de precio fijo, y cláusulas como Money for nothing y Changes for free. En cualquier caso, siempre es recomendable que un experto jurídico nos asesore y revise el contrato para garantizar que el contenido es legalmente coherente.
¿Cómo negociar con un cliente que no está familiarizado con metodologías ágiles?
El mayor desafío al que quizá nos enfrentemos durante el proceso de negociación es la incertidumbre. Si el cliente no está familiarizado con las metodologías ágiles, la idea de un alcance variable, por ejemplo, puede generar desconfianza. Puede mostrarse más reticente a la hora de firmar con nosotros en lugar de con otro proveedor con un enfoque más tradicional.
Pero existen estrategias y herramientas diseñadas para informar al cliente, hacerle entender los beneficios que puede aportar a su negocio trabajar con metodologías ágiles, y establecer unos objetivos claros entre las partes implicadas en el contrato.
Entonces, ¿qué hacemos si el cliente no ha trabajado nunca con agilidad, pero creemos que podemos ser el proveedor adecuado para su proyecto?
Supongamos que una empresa quiere desarrollar una aplicación para amantes del deporte al aire libre y quiere contratarnos. El problema es que nuestro modo de trabajar es ágil, y esta empresa nunca ha trabajado con un proveedor así. Por tanto, nuestro objetivo es conseguir su confianza.
El primer paso es ser claros y proporcionarle información. Debe entender qué significa ser ágil, cómo puede beneficiarle, y cómo puede reflejarse en un contrato.
Contratos y agilidad: ¿cómo dar confianza al cliente?
Flexibilidad
En primer lugar, el proyecto debe ser flexible y permitir cambios, porque se busca poder responder a las necesidades de negocio del cliente en cada momento. Hay que explicar que la agilidad trabaja de forma iterativa e incremental, permitiendo a los equipos entregar valor temprano y continuamente. Que no se fijan todos los requisitos del proyecto desde el principio, porque es normal que durante el desarrollo surjan nuevas ideas y que se descarte parte de la idea inicial. Los cambios no se solicitan siguiendo procesos burocráticos complejos, sino que hay sistemas alternativos más rápidos, que producen menos rozamiento administrativo y reducen costes.
Una forma de asegurar un desarrollo iterativo y abierto a cambios es, por ejemplo, especificar en el contrato que el equipo trabajará en sprints, y que cada cierto tiempo se realizarán reuniones de refinamiento del backlog.
Colaboración directa y frecuente
Pero ésta no es la única reunión que debería contemplarse de forma explícita. La colaboración directa y frecuente es esencial. Así que el contrato incluirá también reuniones de revisión del sprint u otros medios para mantener al cliente informado del avance y permitirle opinar y sugerir cambios en ciclos cortos de tiempo.
En este sentido es importante hablar del rol de product owner: el cliente debería nombrar a un representante que colabore con el equipo, que sirva de enlace. Todo esto puede resumirse en que el cliente debe estar mentalizado para implicarse por completo en el desarrollo, y que se hace así para garantizar que sus objetivos se satisfacen. Podemos explicar las ventajas de la colaboración frecuente y directa frente a los documentos de requisitos, y existen muchas fuentes disponibles para respaldarnos en este sentido.
Pruebas conjuntas con usuarios
Otro aspecto a detallar son las pruebas con usuarios. Los testeos deben ser conjuntos. Si el cliente no está al tanto de cómo está siendo recibido el producto, es difícil decidir si quiere cambios o mejoras. Se dará cuenta más adelante, generando un aumento en los costes, el esfuerzo y el tiempo. Esto puede reflejarse en el contrato con cláusulas donde se especifiquen sesiones dedicadas a probar el producto con la participación del cliente.
Incentivos
Por último, puede ser importante hablar de los incentivos y de qué impacto tienen realmente en el proyecto o presupuesto. En los contratos tradicionales pueden generar un conflicto de intereses entre cliente y proveedor. Por ejemplo, si se paga por tiempo invertido, el proveedor no va a querer terminar antes; mientras que el cliente buscará precisamente una entrega anticipada para ahorrar costes. Se genera así una tensión que afecta a la eficiencia del proyecto de forma negativa. Una alternativa es ofrecer incentivos por puntos de historia o valor comercial, por ejemplo. Cualquiera que sea el consenso, se incluirá también en el contrato.
Otras herramientas para reforzar la confianza
Conversación y debate
Para reforzar la confianza del cliente, podemos ofrecerle referencias de empresas ágiles de su mismo sector, o que han desarrollado un producto similar al que nos ha encargado. O dar referencias de proyectos y empresas con quienes hayamos trabajado en el pasado.
Otra opción es realizar un intercambio de experiencias. Tener una conversación con el cliente durante la que identificar problemas en base a sus experiencias reales. A partir de estos problemas, se presentan soluciones ágiles. A veces no son evidentes y esto puede requerir un taller, si disponemos de tiempo y recursos para ello. La idea es que el cliente vea claramente los beneficios, y él mismo se dé cuenta de cómo el enfoque ágil puede ser ventajoso para su negocio.
Rescisión del contrato
Ahora bien, ¿qué pasa si la colaboración no funciona, o si alguna de las partes incumple lo acordado? Esto también asusta y debe contemplarse, y según el modelo de contrato que elijamos hay incluso sistemas pautados para ello, que protegen a cliente y proveedor. El modelo de contrato ágil de precio fijo incluye un evento llamado «punto de salida» o «no retorno». Se marca un periodo de tiempo durante el cual el cliente puede echarse atrás sin penalizaciones y el precio total del proyecto está estimado pero sigue siendo negociable. A partir del punto de «no retorno» el precio se fija y la rescisión del contrato puede tener penalizaciones si no se avisa con antelación suficiente al proveedor, por ejemplo.
Acordar un periodo de tiempo antes del punto de no retorno con el cliente es otra forma más de darle garantías y seguridad.
No obstante, a veces esto puede ser insuficiente. Es lícito que el cliente no se conforme con nuestra palabra y que necesite pruebas. En este caso, hay distintas alternativas que varían en función del tiempo y recursos de los que disponemos.
Herramientas enfocadas a la práctica
Si el tiempo y los recursos son reducidos podemos saltar directamente a hacer un sprint de prueba con la cooperación del cliente. Así puede ver cómo será el desarrollo de su proyecto, cómo trabajamos y cuáles son los resultados. Es decir, se pueden establecer las expectativas correctas y generar confianza.
En caso de disponer de más tiempo y recursos, podemos organizar talleres o reuniones para resolver dudas.
Una opción es comparar las características de un contrato tradicional y uno ágil para el mismo proyecto con el cliente, y qué beneficios tiene cada uno. También podemos elaborar conjuntamente un borrador de contrato ágil, o simular situaciones y problemas reales.
En el Body of Knowledge de Scrum Manager encontraréis talleres para ayudar en la negociación, como el feature shoot-out (tiroteo de características) y el workshop on contract setup (taller sobre la configuración del contrato).
Como vemos, los contratos ágiles pueden suponer un desafío a la hora de elaborarlos y de negociarlos, o bien porque los clientes son reacios a trabajar con agilidad o bien porque no se tienen claros los objetivos y se duda a la hora de elegir un tipo de contrato u otro.
Más información: guía completa sobre contratos ágiles
Lo más recomendable, en caso de realizar un contrato ágil por primera vez, es hacerlo lo más sencillo posible. Y siempre pedir ayuda a asesores legales. Puede pasar que nuestro asesor no esté muy familiarizado con este tipo de contratos. Existen muchas fuentes para consultar en Internet. En el blog dejaremos un enlace a la guía sobre contratos ágiles de Scrum Manager, que recopila información sobre los modelos y cláusulas más populares a día de hoy y puede servir como punto de partida.
Volveremos con el próximo episodio en lo que se tarda en hacer un sprint: un par de semanas. Hasta entonces podéis encontrarnos en Twitter, LinkedIn, y en scrummanager.com.
¡Mucha suerte con vuestros proyectos y hasta la próxima!