Dicen que no hay mejor profesor que el error y con el error que tuvimos aprendimos mucho. Pero no nos adelantemos…
¡Hola a todos! Soy Luis Cencillo, ingeniero de software en Mercadona Tech desde hace más de 4 años. Actualmente estoy en el equipo de Supply y estamos desarrollando una aplicación nueva para la gestión del stock en las tiendas.
Vamos a cambiar la app
Esta aplicación nueva nace por necesidad, el dispositivo actual va a dejar de fabricarse y nosotros estamos haciendo una app android que la sustituye. A nosotros nos gusta investigar, hablar con los usuarios, entender cómo usan la app para entender dónde puede haber problemas, y sobre todo medir lo que ocurre. Sólo con datos podemos tener la certeza de que tomamos las mejores decisiones.
Si tenemos en cuenta que ya existe un dispositivo que se encarga de esto desde hace muchísimos años puede parecer un copy-paste fácil pero nada más lejos de la realidad. Hemos tenido varios debates dentro del equipo acerca de cómo afrontar este reto: ¿aprovechamos para mejorar algún proceso o sólo hacemos una app “bonita”?. Pues como todo en la vida depende…En algunas ocasiones hemos rediseñado el proceso físico y en otras ha sido mejor dejarlo como estaba, al menos en una primera iteración.
Nuestras tiendas luchan contra el desperdicio donando productos no aptos para la venta (pero sí para el consumo) a entidades sociales. El objetivo era poder, desde la nueva app, registrar esas donaciones. El proceso es sencillo: hay un borrador donde los usuarios pueden añadir / quitar productos, en el momento de llevar los productos a la entidad social el borrador se confirma y genera un albarán (temas legales).
El dispositivo actual permite:
Consultar qué productos hay en el borrador.
Añadir un producto (indicando cantidad y motivo de la donación).
Editar la información de un producto (cantidad / motivo de donación)
Borrar un producto
Seleccionar a qué comedor social va a ir destinado.
Confirmar e imprimir el albarán que se tiene que entregar junto con los productos.
Tenemos el MVP, ¿o no?
Tras reunirnos varias veces con las personas que conocían el proceso físico y entender bien el contexto, pasamos a la acción. Como somos equipos multidisciplinares y autogestionados solemos juntarnos para proponer ideas entre todos los miembros del equipo. Producto, Diseño, Ingeniería, incluso compañeros sin perfil técnico, como los encargados de los Procesos Físicos. ¡Cualquier punto de vista es enriquecedor!
Elegimos una solución para validarla con los usuarios mediante un prototipo. De esta manera afinamos lo que tenemos que implementar y reducimos el riesgo de un desarrollo inútil. En la solución elegida cubrimos todos los requisitos anteriores (que por cierto, era un flujo muy parecido a otro flujo ya existente en la aplicación) y días más tarde Diseño la validó con los usuarios en la tienda. Todo marchaba.
Cuando planificamos las siguientes semanas, de repente no estábamos tan alineados como pensábamos. Producto apostaba por una primera iteración más ligera que permitía hacer todas las acciones básicas (el famoso MVP).
El usuario podía:
Consultar qué productos hay en el borrador.
Añadir un producto indicando la cantidad (el motivo tendría por defecto el valor más común para estos casos).
Confirmar e imprimir el albarán.
Con esto se garantizaba que el usuario podía completar su proceso y todo lo demás se consideraba “extra”.
Desde Ingeniería (backend y android) analizamos lo que había que hacer y lo desgranamos en muchísimas tareas. Al ver tantas tareas nos empezamos a cuestionar el MVP, nos parecía demasiado grande.
Para nosotros la tarea “Añadir un producto” era más que suficiente. Con ella conseguíamos validar que todo funcionaba y no se rompía nada (los despliegues pequeños son uno de nuestros feedback loops).
Como la app nueva y el dispositivo actual compartían información, todo lo que hiciéramos desde la app nueva lo iban a poder consultar en el dispositivo actual. Era un plan sin fisuras: con hacer una acción era suficiente, el resto se podían seguir haciendo desde el dispositivo actual. Pues resulta que no.
Cuando contamos nuestra decisión al resto del equipo nos dimos cuenta que no estábamos alineados acerca de lo que queríamos que hiciera el usuario en la primera versión.
Desde Ingeniería apostamos por despliegues pequeños. Para nosotros eso ya aportaba valor, confirmar que no se rompe nada y que la integración con backend funciona.
Desde Producto se entendía que para aportar valor el usuario iba a poder hacer el proceso en un sitio o en otro. Hacer parte del proceso en la app y el resto en el dispositivo no era una opción.
Y desde Diseño no se estaba cómodo con darle al usuario una versión más pequeña que la que se había validado. No sabíamos cómo iban a reaccionar los usuarios.
Fallamos en la comunicación, estábamos hablando de cosas distintas. Mientras unos hablaban qué pasos había que dar para el primer despliegue, otros hablaban de iteraciones para el usuario.
Esto derivó en varias reuniones “filosóficas” donde discutimos qué es aportar valor, si es igual de importante el valor que nos aporta algo a nosotros o el valor que aporta al usuario, cuándo queremos aportar ese valor… y sobre todo la frustración del equipo debido a tener que rehacer un trabajo ya hecho.
Conclusiones
Conseguimos desacoplar los objetivos de Ingeniería (salir rápido y con poco a producción) con los de Producto (iteraciones válidas para el usuario) usando feature flags. Así fuimos haciendo despliegues con cada avance del código sin que el usuario viera la funcionalidad. Por ejemplo para “Añadir un producto” pudimos hacer 3 despliegues pero sólo al tener el 100% de esa funcionalidad la activamos para que el usuario la usara.
Nuestras diferencias son las que nos hacen un buen equipo, debemos tener presentes al resto de roles del equipo cuando tomamos una decisión. La comunicación y la empatía son claves. Cuando haya dudas es mejor levantar la mano y aclararlas. Si hubiéramos resuelto las dudas en la primera reunión no habríamos tenido que volver a reunirnos más veces para discutir cosas “que ya estaban claras” y nos hubiéramos evitado la frustración.
Al ser una funcionalidad existente tuvimos la tentación de correr y fallamos al alinearnos en el concepto de MVP. En la reunión donde diseñamos la solución nos enfocamos en cubrir todos los requisitos y no sólo los imprescindibles.
Hay que ser ambiciosos, sí, pero también hay que tomar buenas decisiones, de nada sirve hacer muchas cosas si están mal. Un mal MVP te puede salir muy caro. Aunque por suerte no fue nuestro caso porque nos dimos cuenta antes.
A pesar de ser un fracaso la historia tiene un final feliz. Convertimos un error en una oportunidad de aprendizaje y en las siguientes reuniones para idear soluciones fuimos más críticos y más meticulosos, definiendo pasos pequeños, muchos despliegues y cerrando el feedback loop. Pero sobre todo estuvimos alineados durante todo el proceso.