viernes, marzo 02, 2018

Sobre RFP, ANS o SLA para desarrollos ágiles y otras perversiones


Hola a todos

En el medio, cuando hablamos con otros agilistas sobre la forma que las organizaciones están abordando la contratación de proyectos ágiles nos encontramos con RFP (Request For Proposal - Solicitudes de Propuesta) donde existen cláusulas, penalidades y ANS (acuerdos de niveles de servicio) como:
  • El equipo deberá mejorar un 1% cada sprint su velocidad 
  • Ganará el RFP el proveedor que proponga el menor tamaño de sprint 
  • Ganará el RFP  el proveedor que proponga menos sprints
  • Ganará el RFP el que haga historias de usuario en menos tiempo
Lo cierto es que venimos acostumbrados a penalizaciones y a la desconfianza de cascada, (-obvio nadie salía ganando, el producto no era el esperado, al igual que la fecha y el costo no se cumplían, es un caos por donde se mire -), en donde se generaban clausulas como:
  • deberá reducir el porcentaje de defectos proporcionalmente en sus requerimientos
  • por día de demora en la fecha de entrega deberá pagar $/día (y he visto proyectos donde la suma de la penalidad es tal que el proyecto termina valiendo cero pesos)
  • Por cada error en producción se descontará $xx.xxx.xxx
  • entre muchas otras cosas igual o peor de dolorosas donde el proveedor se acomodaba (cobrando más costoso - en el mejor de los casos-, o más barato) pues le interesaba conservar el cliente.(ver este post ¿Compras / vendes /licitas proyectos problemáticos de software? – Un pequeño deja vu - clic aquí)

Por lo tanto, es probable que quien este al frente de contrataciones de proyectos ágiles
  • Esté mal asesorado
  • No tiene conocimiento o entendimiento de ágil -no tiene que tenerlo, en algún momento yo no lo tuve- y en su buena voluntad cree que poniendo restricciones similares a la de cascada podrá "controlar" el proyecto (cosa que tampoco ocurría en cascada - pero que será artículo de otro post- ).

Lo que se observa en este caso es que se esta tratando de resolver un problema nuevo bajo un paradigma mental anterior y que no aplica para este nuevo contexto, y es allí donde se requiere de buen acompañamiento.

Dado lo anterior, cuales serían mis observaciones al clausulado del principio del artículo.

Clausula o ANS propuestoObservaciones

  • el equipo deberá mejorar un 1% cada sprint su velocidad 
  • Implica que la mejora un año deberá mejorar 48% (y eso que no apliqué la formula del interés compuesto) más de alcance al final del año si consideramos sprints de dos semanas(y en dos años del 96%). esto es insostenible,
  • Lo que va a lograr es que las historias de usuario cada vez le pongan más tamaño. (obtienes lo que mides)
  • O si se le hace auditoría las estimaciones de las historias de usuario (que es lo que menos valor genera, auditar estimaciones) terminará agotando al proveedor y dejará de ser negocio para el proveedor continuar con ese cliente pues no es rentable, ni demostrable ese ritmo sostenido de mejora.

  • Ganará el RFP el proveedor que proponga el menor tamaño de Sprint
  • El tamaño del sprint no implica absolutamente nada, se recomienda 2 semanas, equipos con mucha experiencia tienen sprints de 1 semana, y otros trabajan con kanban, pero es el contexto el que da el tamaño del sprint.
  • Es mu probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas partes que ágil no sirve.

  • Ganará el RFP  el proveedor que proponga menos sprints
  • Es una orientación puramente hacia cascada y creer que se puede definir el alcance a priori en agile (aun en cascada) es falso. 
  • Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve

  • Ganará el RFP el que haga historias de usuario en menos tiempo
  • Las historias de usuario son irregulares, aunque se puede hacer partición de ellas no es posible garantizar un tamaño, y aunque se desarrolle más rápido algunas no es garantía de que todas van a ser así.
  • Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve


¿Cómo resolver esto?

  • Opción 1: Prueba de Concepto

Una posible forma de saber con que proveedor quedarse es darle la oportunidad de ejecutarun proyecto en ágil , que ejecute varios sprints (2, 3, o 4 sprints)y si:

  • tiene buen manejo de la metodología
  • si equipo esta preparado y experimentado
  • tiene gestión de la deuda técnica
  • tiene prácticas técnicas
  • su scrum master es preparado y con experiencia
  • entregan software funcionando cada dos semanas
Continuar con el, sino detenerse y entregarle el proyecto otro proveedor.

¿Pero perdiste como cliente? No, ganaste conocimiento y al menos quedaste con software funcionando (cosa que no quedaba en cascada).

  • Opción 2: Referencias

Otra opción es visitar referencias de clientes de ese proveedor y validar con un experto en ágil las experiencias y aplique las mismas condiciones de la opción 1, sino funciona terminar el contrato.


Lecturas Recomendadas

Recomiendo para la mejor comprensión y ayuda estos dos post

Bienvenido el feedback


Saludos ágiles
Jorge Abad

No hay comentarios.:

Publicar un comentario