¿Cómo construimos un MVP?
MVP: Minimum Viable Product
Este año tenemos un par de grandes retos por delante, comenzaremos operaciones de Resuelve Tu Deuda en Argentina y estaremos construyendo un core bancario para el producto de captación (ahorro de dinero) de Resuelve Tu Deuda en México, Colombia y Argentina*. Como es de esperarse el tiempo para entregar un MVP de ambos productos es tan poco que no podemos desperdiciar nuestro valioso tiempo desarrollando componentes que no se utilizarán.
Un MVP debe de cubrir el flujo completo de la vida de un cliente, no se trata de cubrir sólo la venta, o sólo operaciones. Tenemos que cumplir lo mínimo indispensable para asegurar que un lead pueda convertirse en cliente y completar el programa sin fricciones en ningún paso.
El flujo de RTD (Resuelve Tu Deuda)
El flujo de RTD comienza en un lead (cliente potencial) que contactaremos vía telefónica generalmente. Cuando el cliente expresa un interés real en el programa de RTD y cumple con los requisitos decimos que ese lead está calificado y entonces se convierte en una oportunidad. Ahora es momento de recopilar la documentación requerida del cliente como pueden ser contratos, identificaciones, etc.
Cuando tenemos toda la documentación completa, la oportunidad se convierte en cliente y ya es parte del programa de RTD. En este momento se termina el proceso de ventas pero seguiremos en comunicación con el cliente por medio del área de servicio al cliente. Finalmente cuando el cliente termina de liquidar sus deudas es cuando se gradúa del programa de RTD.
Para poder lograr hacer un MVP de RTD identificamos los siguientes hitos por los cuales pasa un cliente para poder graduarse del programa:
Lead |> Oportunidad |> Cliente |> Servicio al cliente |> Graduación
El MVP que construiremos debe cubrir todos los hitos, que la información fluya de manera natural entre ellos y que la fricción sea mínima.
Happy Path
Como cualquier producto o servicio, hay muchas maneras de llegar al resultado final — en este caso la graduación del programa RTD — pero no todos los clientes son iguales y no todos tienen las mismas condiciones. Sin embargo, debemos de dar prioridad al camino que será transitado por la mayor cantidad de clientes, el Happy Path. Sabemos que no será el único camino pero es el que la mayoría de los clientes caminarán y debemos estar seguros que este camino se puede caminar con la menor fricción posible.
No resuelvas problemas que no tienes
Es evidente que el Happy Path no será el camino de todos los clientes y que muchos de ellos tendrán un camino mucho más complicado o para nada lineal, aún así debemos resistir la tentación de solucionar problemas o excepciones que no tenemos todavía. Esto no nos traerá más que un nuevo conjunto de problemas que describo adelante.
Si comenzamos a considerar excepciones que aún no tenemos nos veremos obligados a construir caminos alternativos del Happy Path. Cuando acabemos de programar la excepción, el camino ya no será lineal por lo que dejaremos un hueco que debemos de cubrir con un parche, sí un parche al Happy Path!
Primero tienes que romper el Happy Path y hacer hueco para la excepción (o problema).
Luego programas la excepción que te acabas de inventar.
Una vez que acabes de programar la solución de la excepción intentarás regresar al punto donde rompiste el Happy Path, no será fácil, pues la visión general del MVP ya aumentó en complejidad gracias a esta nueva excepción. Será muy difícil que logres regresar al punto exacto donde hiciste rompiste el Happy Path, por lo que ahora deberás construir y aplicar el primer parche de tu MVP, así es, todavía no terminas el primer MVP y ya tenemos el primer parche :(
Y esto es asumiendo que durante el desarrollo de la solución a la excepción no se te ocurrió otra excepción que complicó todo aún más.
Por último, debes regresar al camino original y terminar de programar el Happy Path que habías comenzado, pero ahora en vez de tener un camino lineal tendremos que hacer nuestro segundo parche para poder seguir adelante.
Felicidades tienes dos parches en un sistema que todavía no comienza a operar!
Entonces ¿Qué hacer con las excepciones?
Tratarlas como tal, es decir, no son parte del Happy Path y antes de solucionarlas tenemos que encontrar los patrones que nos permitirán automatizar la solución para cada excepción. Es posible que la solución sea mucho más fácil una vez que tengas claro cuál es el problema en realidad.
Hay patrones que se encuentran a simple vista, pero habrá otros que se esconden como el bug más obscuro que hayas resuelto jamás; Para encontrar estos patrones obscuros será importante documentar lo más posible todas las excepciones según se vayan presentando. En un inicio las soluciones a las excepciones se darán de forma manual e individual, irlas documentando nos ayudará a poder encontrar patrones y soluciones más fácilmente; tenerlas documentadas ayudará a que alguna otra persona también pueda comprender la excepción y posiblemente darte la solución que has estado buscando.
Será mucho más fácil solucionar excepciones y/o problemas una vez que los tengas claros y que sepas que realmente se están presentando.
Finalmente recuerda que no hay software más caro que el que no se usa.
*En Colombia y Argentina la captación la hacemos por medio de nuestro socio Allianz.
