¡F.A.L.L.A. Rápido!
En este post: descubre tres maneras de “fallar” en el software que desarrollas y en el valor que este entrega para así acelerar tu camino al éxito.🎯
“Fallar”….esa detestable condición que tod@s tratamos de evitar a cualquier precio. 🚫
Fallar en una prueba en la escuela. Fallar en una presentación en el trabajo. Fallar en el software que creíamos que sería exitoso 😔. Fallar en un proyecto personal. Fallar en una inversión económica 📉. Fallar la nota al tocar un instrumento musical 🎸. Fallar en una relación amorosa 💔.
Sin importar el contexto, “Fallar” es inevitable pero aún así nos negamos a aceptarlo. Para evitar llegar a ese momento embarazoso, decidimos incluso no tomar la oportunidad de la idea, proyecto o relación para así extirpar cualquier posibilidad de fracasar.
Refactorizando “FALLAR”
¡Hey, tranquil@!
Como “programadores” de nuestra propia realidad, tenemos la capacidad de refactorizar (re-definir) nuestra percepción de esta realidad y del lenguaje que utilizamos para describirla. Gracias a esta capacidad, permíteme redefinir “FALLAR” de la siguiente manera:
Recuerda: las altas y las bajas forman parte de cualquier aventura pero son estas últimas las que proveen un conocimiento duradero. Por esto, en lugar de vivir con la angustia de no saber cuándo será la siguiente ocasión en la que “fallaremos”, ¿por qué no mejor manufacturar estas situaciones y aprender de ellas lo más rápido posible? O mejor aún, ¿por qué no utilizar tecnología para crear fallas pequeñas y controladas? #micro-fallas
Después de todo, la naturaleza ha estado utilizando la estrategia de Fallar Rápido desde antes de que nosotros (humanos) habitemos el Planeta y, gracias a Charles Darwin, denominamos a esta estrategia como “evolución”. Por millones de años, cada día es una iteración, una nueva oportunidad de fallar, para que alguna especie se adapte satisfactoriamente al ambiente o …bueno, nos deje solamente vestigios de lo que alguna vez fue. 🦖🦕☠️
Veamos ahora como F.A.L.L.A.R para prosperar en nuestros productos:
¿Cómo Fallar (Aprender) Rápido en software?
Analicemos tres maneras de acelerar nuestro aprendizaje en distintas etapas del software:
En la calidad del producto
Productos llenos de errores (bugs🐞) no llegan lejos, especialmente si de estos dependen las operaciones de empresas, hospitales o incluso transporte aéreo. Para comprobar esto, ten en cuenta el caso de los bugs encontrados en el 2013 en el sitio web de HealthCare.gov del gobierno de USA después de su lanzamiento, los cuales humillaron al entonces Presidente Obama en su campaña de salud pública. #lackOfTesting
Para descubrir (aprender sobre) estos errores antes de que lleguen a las manos de los usuarios, es necesario practicar Continuous Testing. La ejecución frecuente de las baterías de Unit Tests, el Análisis estático de código, los Tests de Integración y de Aceptación de Usuario (UAT), son la clave para detectar errores en distintos niveles de los productos de forma temprana.
En la propuesta de valor del producto
La forma más ineficiente de probar que una nueva idea de producto o feature será exitoso es: concebir la idea, diseñarla, codificarla, probarla, enviarla a los usuarios y obtener feedback de estos.
Para evitar dicha situación analicemos las siguientes alternativas:
- Prototipos semi-funcionales
No esperes hasta el anhelado día del lanzamiento para recibir recibir feedback sobre tu aplicación. Actualmente contamos con las herramientas suficientes para crear Prototipos semi-funcionales — bosquejos muy bien pulidos que por lo general no cuentan con un backend, sino que funcionan con datos estáticos y predefinidos. Estos prototipos son presentados a potenciales usuarios de los productos para recolectar sus opiniones y así validar si nuestra idea brinda el valor que esperamos o es necesario realizar ajustes.
Utiliza herramientas de prototipado como InVision o JustInMind. Si prefieres algo un poco más real, entonces desarrolla mock-ups, por ejemplo en Javascript en combinación con Firebase como backend. Y, si todo esto falla, no olvides que aún tienes al buen lápiz y papel para crear bosquejos para transmitir las ideas del producto a tus usuarios.📝
2. Entrega Continua + A/B Tests
La segunda forma de fallar rápido en esta categoría es a través de la combinación de Continuous Delivery (Entrega Continua), el uso de “A/B Tests” y la recolección de métricas sobre esos tests.
Refresquemos la memoria acerca de qué son los A/B Tests. En esencia se trata de crear dos alternativas de un mismo feature — alternativa “A” y alternativa “B” — las cuales son distribuidas a dos grupos similares de usuarios y, mientras ellos juegan con su respectiva versión, nosotros recolectamos información (métricas) acerca del comportamiento de ambos grupos para así determinar cuál de ambas “falló” y cual tiene mejor aceptación.
Bien, ya recordamos cómo funcionan los A/B Tests. ¡Ahora es tiempo de juntarlos con Continuous Delivery!
Si observas en el software que utilizas diariamente, muy probablemente habrás notado que existe funcionalidad “Beta”- features que no están oficialmente completados pero que están disponibles para su uso bajo esa consideración. Esta es una manera elegante para enviar actualizaciones continuas de tu aplicación a los usuarios y en la cual podemos aplicar la táctica de los A/B Tests para así descartar rápidamente features que no tienen el éxito que esperamos.
En el funcionamiento diario de los productos
Actualmente no creamos productos, sino servicios que nuestros usuarios esperan que estén en constante funcionamiento (si no me crees, recuerda como te pusiste la última vez que WhatsApp dejó de funcionar: 😡). Es por este motivo que el continuo funcionamiento de las aplicaciones que creamos tiene que ser maximizado y el downtime minimizado.
En un mundo ideal no existen imprevistos, las operaciones son ininterrumpidas y nuestros productos están disponibles 24/7, pero …¡bienvenido de vuelta a la realidad! 🥊. Las caídas del servicio, la latencia en la red y la lentitud en la respuesta de servidores son algunos ejemplos de factores que lo único que maximizan son el nivel de nuestro estrés.📈😫
Bueno, dejemos de ser víctimas y retomemos el control de la situación. Contraria al sentido común, la recomendación para lograr esto viene de parte de Jez Humble:
“Si duele, hazlo con más frecuencia.” — Continuous Delivery, 2010, Jez Humble
Originalmente, J. Humble se refiere a incrementar la frecuencia de los releases a producción, sin embargo, permíteme extender esto hasta el domino de las operaciones diarias de las aplicaciones:
“Si un incidente en operaciones duele, reprodúcelo con más frecuencia.”
Pero no hablo de “masoquismo tecnológico”, sino más bien de la implementación de una técnica que en toxicología es llamada Hormesis; cuando una pequeña dosis de una sustancia dañina es en realidad beneficiosa para el organismo, actuando así como una medicina.
En software, nosotros conocemos esto como Ingeniería del Caos: inyectar fallos controlados en Producción para descubrir nuestras debilidades en lugar de esperar a que la mala fortuna sea quien las revela. Este tema requiere un artículo por sí mismo, así que por el momento solo puedo apuntar a este breve artículo de explicación (gracias a jgarzas).
Cuando asimilamos el verdadero significado de F.A.L.L.A.R., entonces entendemos claramente el aviso de Thomas, J. Watson, antiguo CEO de IBM:
“Si quieres incrementar tu tasa de éxito, duplica tu tasa de fracasos.” — Thomas J. Watson, IBM.
Recuerda: podemos fallar muchas veces, pero aprender lecciones en cada una de estas ocasiones incrementa las probabilidades de acertar en las pocas ideas necesarias para ser exitos@s.
Antes de despedirme, hace unos días escuché esta entrevista a James Altucher, fundador de 20 compañías (17 fallaron). Espero que te motive tanto como a mí para F.A.L.L.A.R Rápido!
Keep on learning… and Failing Fast!
Como siempre, por favor déjame tu feedback en un comentario en este artículo. ¿Te fue útil?¿Qué aumentarías o quitarías?¿Otras sugerencias? También puedes enviarme un tweet a @jjruescas1 y colocar #DevOps al final para poder encontrarlo.🙂