¿Para cuándo puede estar mi proyecto?
En todo el tiempo que vengo liderando equipos de tecnología siempre me he topado con la siguiente situación: El cliente necesita desarrollar un producto digital, tiene la idea general de lo que necesita, la comunica y pide tiempos: ¿Para cuándo puede estar?. Esa pregunta viene de la mano con el requerimiento y es comprensible. El cliente necesita saber cuándo podrá contar con su proyecto desplegado.
El modelo tradicional de abordar un desarrollo es el método cascada o secuencial. Y es este modelo el que por naturaleza tenemos en la cabeza; ya que es lo que usamos para planificar cualquier cosa. En “cristiano” consiste en establecer pasos para lograr el objetivo y darle un tiempo a cada paso. Defines una fecha de inicio, calculas el costo y voilá. Esto funciona cuando sabes exactamente qué es lo que tienes que hacer para tener tu producto. Sirve muy bien para procesos de producción recurrente (manufactura), como elaborar una torta en una pastelería. Después de elaborar una, ya se sabe cuánto tardarán en hacer otra igual. ¿Pero qué sucede si viene un cliente con un pedido particular?
Entonces el problema radica en que un producto digital es un producto único, no hay forma 100% exacta de estimar el llamado “triángulo de hierro” de la calidad: alcance, tiempo y costo; ya que nunca se ha hecho algo exactamente igual. Crear el cronograma exacto al inicio solo le da “paz mental” al cliente, tranquilidad de que todo se hará en un tiempo exacto y con el alcance solicitado (con un costo pactado). Pero para que, en el mejor de los casos, esto funcione, el cliente debe recibir el cronograma y esperar hasta la fecha final pactada para ver su producto terminado y desplegado para su uso (con algún ajuste y pruebas también contempladas al final del cronograma por supuesto). Sucede que en más del 80% de los casos, no se cumple con la fecha estimada...
Y esto sucede porque durante el proceso el cliente siempre va a requerir ver avances y surgen nuevas necesidades no contempladas en el requerimiento inicial que no podrían tomarse en cuenta sin afectar a las otras aristas del triángulo (Coste y tiempo). Pero son necesidades válidas al fin y al cabo; el cliente no podría (y no debería) estar ajeno a su proyecto hasta el final con tal de respetar el triángulo (cuyas aristas han sido establecidas en un contrato de desarrollo).
El riesgo más grande que corren los clientes con un proyecto en cascada es comprar algo que luego no les sirve.
Para solucionar este problema se planteó una forma de trabajar pero que implica también una nueva forma de pensar y hacer las cosas; abordando estratégicamente tu proyecto desde el principio, definiendo claramente qué es lo que se espera lograr pero sin querer tenerlo todo de una sola vez. Este modelo es denominado iterativo e incremental y forma parte del desarrollo ágil.
Lo que se hace es lo siguiente:
- Visualizar el proyecto a nivel general sin entrar en detalles específicos.
- Encontrar lo más importante - Y acá hay que resaltar que esta parte es crucial, puesto que tendemos a creer que todo importa igual cuando en realidad no (Ley de Pareto).
- Detallar lo anterior y desarrollarlo.
- Ponerlo a funcionar.
- Repite paso 2.
Este ciclo es iterativo, puesto que se trata de construir un MVP (Producto Mínimo Viable) y ponerlo a funcionar para poder evaluar y refinar para siempre tener un upgrade del producto.
En conclusión, el desarrollo iterativo e incremental le permite al cliente contar con algo tangible en un tiempo menor y con un riesgo pequeño, ya que al estar sujeto a cambios o impedimentos se puede pivotar sin muchos problemas en la siguiente iteración y no al final de todo el proyecto. Eso sí, requiere de un involucramiento del cliente ya que debe dar la visión y feedback continuo sobre el proyecto que desea para conseguir los objetivos que necesita.
Ahora, es muy importante entender bien qué cosa no es un MVP, pero esto lo trataré en un siguiente artículo. Mientras dejo un ejemplo gráfico que no necesita explicación sobre qué es iterativo e incremental y qué no lo es...
Compartir en:
