Scrum y la incertidumbre

¿Te ha pasado que te enfrentas a un clima dentro de un proyecto en el que el cliente no sabe definir sus necesidades y donde cada nueva reunión parece anular a la anterior y piensas “¡a empezar de nuevo otra vez!”?
Pues  bien, este es un problema que se presenta a menudo con la mayoría de clientes en medio de proyectos que no tienen una metodología establecida, donde lo urgente prima sobre lo importante y donde pocas veces el rumbo es visible para el equipo de proyecto. En este artículo, explico por qué y cómo Scrum puede ayudarte a sopesar esta situación.

Primero, vamos a contextualizar el problema con las características del proyecto:

El cliente, muchas veces, no sabe exactamente lo que quiere: o lo sabe pero no lo define a la primera y en el camino se va formando la idea. Esto pasa con clientes que no son expertos en la materia, o que son muy expertos y vuelan demasiado, y para un Propietario del Producto (P.O), la difícil tarea de poder sacar la “carnecita” al cliente, requiere de experiencia, habilidades analíticas y, ¿por qué no?, habilidades blandas.

En estos casos, el nivel de incertidumbre es muy alto. Esto significa que el equipo de desarrollo se enfrenta a nuevos retos en cada reunión de revisión de requerimientos o de verificación de la funcionalidad del software (si hablamos del método tradicional). La mayoría de empresas con metodologías tradicionales tienden a definir “fases” en el proyecto, lo que tiene mucho que ver con los sprint aunque sin llegar a serlo porque finalmente en una nueva reunión esa fase se convierte en “fase 1 version 2”, “fase 1 versión 3”, etc. Y ahí empiezan los problemas de control de cambios y de calidad.

¿En qué nos ayuda Scrum?

Si el cliente no sabe lo que quiere, debemos hacer que se defina. Esto se logra por medio de la definición de prioridad a través del valor. Uno de los principios de Scrum (y de ágil en general) es ofrecer valor para el cliente en el corto plazo. El propietario del producto, debe poder ayudar al cliente a definir las funcionalidades más importantes. Ojo, no las más deseadas o urgentes, sino las que le generan mayor valor a su negocio. El cliente entenderá que sin esa funcionalidad su negocio no va a generar el retorno de inversión esperado y no tendrá mejor opción que enfocarse en lo que le resulte más rentable.

En ese sentido, las historias de usuario, las que se hacen bien (en otro post comentaré sobre cómo hacer buenas historias de usuario), ayudará al equipo a tener la certeza de lo que se quiere. Estas historias pasarán al Sprint y no podrán ser cambiados durante la ejecución del mismo. Esto significa que, en la presentación del entregable, el cliente solo podrá validar lo que él mismo priorizó y especificó. Obviamente, si durante el tiempo pasado, se le ocurrió alguna otra brillante idea, lo que pasará es que se evaluará el impacto del cambio a nivel de desarrollo y a nivel del valor para el negocio. Pero en todo caso, el equipo del proyecto siempre estará al tanto de lo prioritario y de lo que genera valor para el cliente. El tiempo definido para cada Sprint (cada 3-4 semanas) permite recibir el feedback del cliente en poco tiempo y con la certeza de que estará enfocado en lo que le genera valor.

¿Te diste cuenta que poniendo por encima la palabra “valor para el negocio” todo parece tener mayor sentido?

En resumen, la incertidumbre se reduce a medida que se recibe el feedback por parte del cliente luego de cada sprint y con la certeza de estar construyendo lo correcto, lo que genera valor. Esto reduce el riesgo de que el cliente quede insatisfecho y que finalmente reciba algo que no necesita.

Please follow and like us:
0

Leave a comment

Hey, so you decided to leave a comment! That's great. Just fill in the required fields and hit submit. Note that your comment will need to be reviewed before its published.