• Leonardo Mrak

Sobreviviendo en un entorno no determinista

Actualizado: 14 de may de 2020

Utilizando una Estrategia de Desarrollo Guiada por Hipótesis

Una problemática bastante más común de lo que se cree en ingeniería de software es la falta de capacidad para “reconocer lo que no se conoce”. Existe la creencia de que al entender los errores cometidos en un último periodo podremos evitar cometer errores en el periodo que continua y esto es cierto pero hay que considerar que muchos de los errores cometidos surgieron por situaciones de improviso, es decir que no estaban contempladas, entonces que nos hace pensar que no vuelvan a surgir, recordemos que provienen de una fuente inagotable!


Aferrados a este conocimiento sobre el pasado y a frases que apuntalen el éxito de nuevos proyectos como “esta vez no nos podemos equivocar, recordemos lo que pasó con el producto xxx…”, “no tenemos margen de error, debemos cumplir con las expectativas de nuestros clientes”, intentamos evitar pensar en el fracaso que por más que no nos guste, siempre es una opción.


¿Cómo podemos lidiar con esta situación?


Lo primero ya lo comentamos, hay que reconocer que existen cosas que no conocemos, el fracaso siempre es una opción, por lo que debemos impulsar el descubrimiento y aprendizaje permanente y lo más temprano posible (Dual Track Development)


Anteriormente nuestras estrategias de desarrollo de software estaban basadas en enfoques deterministas (ciclo de vida cascada), que funcionan en entornos donde se puede iniciar con requerimientos bien conocidos y con poco movimiento en el corto plazo y normalmente utilizan modelos estadísticos basados en una gran cantidad de datos históricos (siempre se corre el riesgo sobre la calidad de estos datos pero ese es otro tema) y que cuentan con factores de Fudge reconociendo de esta manera que hay factores desconocidos que se deben ir ajustando.


El conocimiento detallado de requerimientos en etapas tempranas que nos permitan realizar una estimación con cierta certeza y que nos aseguren de que no cambiarán, no es lo que sucede en la mayoría de nuestros proyectos. Los métodos ágiles conscientes de este contexto, se enfocan a entregas tempranas y cortas, dotándonos de flexibilidad para acomodarnos a situaciones que se puedan suscitar, permitiendo que los requerimientos emerjan en el tiempo. De todas formas, si nos ponemos a pensar fríamente, lo que estamos haciendo es disminuir el problema de la falta de conocimiento sobre lo que puede suceder en el tiempo y el impacto que esto tiene dado que nos enfocamos a periodos cortos y por lo tanto entregas pequeñas.


Esto nos ha permitido aprender más rápido, aunque no lo suficientemente rápido debido a que se siguen construyendo en muchos casos, cosas que no agregan valor a nuestros clientes y nos enteramos cuando ya es tarde.

Cambiar a una estrategia de desarrollo guiada por hipótesis


Como se puede ver claramente en Dual Track Development, el trabajo de descubrimiento separado del de desarrollo, debe ser ejecutado permanentemente enfocado en el aprendizaje rápido.


Una forma muy utilizada para materializar la implementación de este enfoque, es lo establecido por las Pruebas de Hipótesis o el Desarrollo Guiado por Hipótesis.


Las pruebas de hipótesis nos permiten desarrollar nuevas ideas, productos o servicios a través de experimentos que avanzan según se confirman o no los resultados buscados.


La información obtenida del resultado nos permite aprender y mientras antes obtengamos este aprendizaje antes sabremos si una idea es o no lo que creemos.


Esta técnica está basada en el método científico cuyos pasos simplificados recordemos son:

Al igual que en el método científico, necesitamos definir nuestra hipótesis y establecer los resultados que esperamos obtener y con los cuales consideraremos que la hipótesis es válida o no. Esto debe establecerse antes de realizar la prueba para no sesgar las interpretaciones de los resultados.


Por lo tanto, la estructura de una historia de negocio que apoye el desarrollo guiado por hipótesis, sería:


Creemos que < esta capacidad >


Al establecer una capacidad del producto o servicio que queremos construir, estamos identificando la hipótesis que queremos comprobar.


Resultará en < este resultado >


Cuál es el resultado que nos indicará si nuestra hipótesis ha probado ser lo que creíamos.


Sabremos que hemos tenido éxito cuando < obtengamos estos indicadores >


Que métricas cualitativas o cuantitativas indicarán que nuestro experimento ha tenido éxito. Es importante especificar en esta última sección el periodo que durará el experimento.


Desde la formulación de hipótesis que fueron comprobadas, una o muchas historias de usuario surgirán, aunque cada historia de usuario no requiere una hipótesis.

Ejemplo:


En una compañía francesa utilizamos esta técnica para asegurar que tanto valor tenia el presentar ciertas funcionalidades de su plataforma web en una app móvil y de esta manera encarar un proyecto con un alcance mas amplio o mas reducido en un primer momento.


Se tomó una muestra de sus clientes basada en ciertos criterios que aseguraban que fuera representativa para el experimento que queríamos hacer, se colocaron componentes de monitoreo en la plataforma y en el prototipo de app móvil (un prototipo muy limitado) y se hicieron las pruebas. El resultado buscado por el experimento era aumentar un 3% la generación de pedidos de cierta línea de productos. 


Creemos que < liberar una app móvil para generar pedidos para la línea de productos xxx >.


Resultará en < un aumento de pedidos relacionados a esta línea de producto solicitados por los clientes de la muestra >.


Sabremos que hemos tenido éxito cuando < para el primer mes después de liberada la app y promocionada con los clientes de la muestra, la cantidad de pedidos generados vs. el mes anterior aumente en un 3% >.


Conclusión


Esta técnica permite validar la visión de los productos y generar MVP’s con ciertos niveles de certezas. Al utilizarla, los volúmenes de desperdicio que se evitan son muy altos, invirtiendo la capacidad de los equipos de desarrollo en construir productos o servicios de valor para nuestros clientes.


El combinar el desarrollo guiado por hipótesis con continuos delivery nos permite mejoras importantes en la velocidad de aprendizaje.



#lean #innovation #designthinking #agile

92 vistas0 comentarios

Entradas Recientes

Ver todo