¿Puede la forma de trabajo garantizar el éxito de un producto digital?

Cuando pensamos en hacer un nuevo producto nos ilusiona tener la mejor idea, ponemos mucho cariño en la conceptualización inicial, debatimos intensamente sobre cuál debería ser el MVP con el que enamorar a nuestros usuarios y corremos mucho durante los Sprints para salir a producción lo antes posible.

Hemos aprendido que en el mundo digital tenemos que trabajar de forma más rápida, romper las fases separadas de diseño, desarrollo y testing para trabajar con un equipo multidisciplinar capaz de paralelizar tareas e ir entregando de forma continua. Y, para esto, una de las cosas que necesitamos es acortar las fases iniciales donde esbozamos la visión y adelantamos todo lo necesario para comenzar a trabajar. A esto, nosotros lo llamamos Sprint 0.

Pero este post no va sobre el Sprint 0, va sobre los Sprints de después y cómo trabajamos en ellos. A cómo lo hacemos nosotros, en la industria tiene un nombre: Dual Track, y si buscas en Google hay literatura al respecto y artículos en blogs a favor y en contra. Así que aquí va otro más para posicionarnos a favor del método: en los productos en los que he estado trabajando es lo que mejor nos ha funcionado para poder mantener nuestros principios ágiles y respetar los tiempos que necesitan tanto el equipo de desarrollo como las organizaciones de nuestros clientes.

¿Qué es el Dual Track? ¿En qué consiste?

El Dual Track es establecer dos tracks de trabajo en paralelo:

• Track de descubrimiento: trabajará en el descubrimiento, conceptualización, prototipado y diseño de la funcionalidad.
• Track de implementación: en paralelo, y con un pequeño desfase, el equipo de desarrollo irá construyendo y entregando la funcionalidad definida.

No son dos equipos de trabajo separados. Es uno sólo realizando tareas de distinta índole. Y de esta forma conseguimos hacer más eficiente el trabajo del equipo y que haya una perfecta integración entre diseño y desarrollo.

El cocktail perfecto: Dual Track + Lean Analytics + Hypothesis-driven Development.

Efectivamente esto no lo hemos inventado nosotros, pero lo que sí hemos hecho es completar la misión y tareas de ambos tracks para no caer en el mayor riesgo que tiene todo proyecto: producir de forma ágil funcionalidades que el usuario no quiere y que no aportan valor a la compañía.

Por eso, al Dual Track le hemos sumado técnicas como Lean Analytics y Desarrollo basado en hipótesis para poder tener un método centrado en maximizar el éxito del producto.

Reforzamos el Discovery Track para que, además de la realización de diseños y el refinamiento de las historias de usuario, introduzca:

• Análisis de métricas.
• Actividades de investigación con usuarios.
• Emisión de hipótesis.
• Realización de experimentos.

En el track de implementación se transforma ese software funcional en negocio y se participa, al igual que en el Discovery Track, en el análisis e interpretación de los datos analíticos.

Trabajar con un Dual Track básico (diseño y desarrollo escalonados un Sprint) puede funcionar hasta la primera release, sobre todo si es corta. Sin embargo, es crítico hacerlo a partir de tener el primer lote de funcionalidad en producción. Cuando esto pasa, muchos marcan un check y a otra cosa, otros siguen aquel plan de releases que hicimos hace meses durante la conceptualización inicial. Siento decir, que ambas opciones son un error. Es el momento en el que más importante es ver cómo está funcionando y cuestionar el plan de acción. No una vez, constantemente.

¿Por qué nos parece una buena opción?

• Esta forma de trabajo nos permite mantener investigación con usuario, vigilancia de mercado y test durante todo el ciclo de vida del producto, lo que garantiza mejores resultados del producto y minimiza el riesgo de no tener la acogida esperada.
• La estrategia de producto ya no es algo que se hace en las primeras fases del producto. Ahora la estrategia es continua, se adapta a lo que el mercado y los usuarios demandan y se integra en los equipos ágiles. Los backlogs ahora son dinámicos de verdad, no aquello que se escribe en piedra tras el Sprint 0.
• Las organizaciones de nuestros clientes rara vez están preparadas para definir y sobre todo validar con los implicados lo definido. Por no hablar del poco tiempo (prácticamente inexistente) que dejamos para poder refinar un diseño e incorporar feedback. Esto nos suponía un nivel de presión muy alto en ambas partes, que hemos podido rebajar.
• Además, descubrir y desarrollar la misma funcionalidad en el mismo Sprint nos hacía tener que pensar siempre en cosas pequeñas. De esta forma, además de anticipar y resolver posibles problemas de dependencias o integraciones, podemos aumentar el grado de innovación en el producto.
• Guiarnos por métricas favorece transparentar el porqué de cada funcionalidad, cambio o nuevo requisito, de la misma forma que nos permite ver la acogida por el usuario de cada uno de ellos.
• Involucramos a perfiles técnicos en la estrategia y resultados, por lo que el equipo está mucho más comprometido con el producto, repercutiendo directamente no solo en la calidad del producto sino en la creatividad del equipo.

Nosotros hemos completado aquello que no dicen los métodos ágiles para obtener el mayor rendimiento de un producto digital, poniendo los resultados de negocio al mando de los esfuerzos de desarrollo. La clave es que la medida de progreso del proyecto ya no es únicamente la entrega de software funcional, sino que ese software sea para conseguir resultados, es decir, la entrega constante de resultados de negocio.

Y vosotros, ¿habéis probado a trabajar así? ¿Qué tal os ha resultado?