Formación escrita en DevOps
¿Cómo mejorar sus hipótesis con DevOps y fortalecer una organización centrada en experimentar y aprender?
En las organizaciones de TI típicas que solía crear, es probable que aún se publiquen varias versiones de productos y funcionalidades sin comprobar si logran los resultados de negocio esperados o si realmente las usa alguien. La forma menos eficiente de probar un modelo de negocio o una idea de producto o funcionalidad es construir un producto y servicio de software completos para ver si existe la demanda prevista y si su idea puede satisfacerla.
Antes de construir un producto y servicio completos, debe preguntarse: «¿Por qué debería construirlo?”, “¿Realmente merece mi tiempo y mis recursos?». Diseñe y ejecute los experimentos más rápidos y económicos posibles para comprobar si sus ideas, productos y funcionalidades logran los resultados de negocio esperados.
Experimentos y mediciones estadísticas de larga duración con distintas suites empresariales indican que solo 1/3 de los cambios realizados mejora notablemente alguna métrica clave, como ingresos, conversiones, pedidos, suscripciones o adquisición de clientes. En otras palabras, 2/3 de los cambios no mejoran la métrica, la mejoran de manera insignificante o la empeoran. Para esos 2/3 de cambios, sería mejor dar vacaciones a todo el equipo que construir funcionalidades que no aportan valor.
Para afrontar este problema, investigue con usuarios mediante pruebas A/B. Pruebe los resultados de las funcionalidades antes de construirlas. Integre los comentarios de los usuarios en el proceso de ingeniería para comprobar que aplica bien DevOps y que construye lo que realmente hace falta. Cuanto más rápido pueda experimentar, aprender e incorporar esos comentarios al ciclo de vida del software, más posibilidades tendrá de superar a sus competidores en su mercado.
Las pruebas A/B se popularizaron con el marketing de respuesta directa por correo postal. Los especialistas en marketing prueban variantes de folletos y postales, cambiando la redacción, los colores, la composición, los titulares y el texto, para descubrir cuáles funcionan y venden más. El Gobierno británico ha utilizado pruebas A/B para determinar qué carta consigue cobrar más impuestos atrasados. Hoy son un método habitual tanto para probar elementos de marketing y comunicación como para identificar qué ideas, productos y funcionalidades funcionan.
Para adoptar las pruebas A/B en su equipo de DevOps, debe poder desplegar con rapidez y facilidad varias versiones de una funcionalidad y mostrarlas a distintos segmentos de usuarios. Utilice la telemetría y las métricas de la capa de negocio para comprobar si la funcionalidad mejora los resultados y, de ser así, qué versión funciona mejor.
Por ejemplo, su organización DevOps quiere publicar un nuevo proceso de compra para una tienda en línea. Antes de convertirse en una tarea importante del equipo, ese proceso es solo una hipótesis para mejorar los resultados del negocio. Una vez investigada y validada la hipótesis, el proceso puede convertirse en un proyecto real que consuma una cantidad importante de tiempo, recursos y energía. La primera tarea del equipo con ese proceso es:
Validar la hipótesis: Creemos que una nueva versión del proceso de compra puede mejorar las tasas de conversión. Tendremos la confianza necesaria para construir y entregar toda la funcionalidad cuando veamos que una de las versiones experimentales, mostrada al 1 % de los visitantes, aumenta las ventas al menos un 5 % durante los próximos 7 días.
CONCLUSIÓN
Además de la intuición y las buenas prácticas que su equipo y usted han aprendido y observado, céntrese en conseguir que personas reales participen en los experimentos en condiciones reales.
Los Product Owners de DevOps deberían tratar sus ideas de productos y funcionalidades como hipótesis que deben validarse. Solo se deben diseñar, construir y probar por completo una vez que se haya demostrado con argumentos que son buenas ideas.
