MVP, prototipo, iteración.. ¿Cómo lo hacemos?

Existen multitud de nuevas metodologías de trabajo relacionadas con la digitalización, innovación, nuevas tecnologías y nuevos modelos de negocio. Seguro que te suenan el scrum (si, también se utiliza en el rugby), design thinking, lean start up, etc. Cada una con características diferentes que las hacen únicas para cada iniciativa, pero todas ellas basadas en el mismo concepto de idear, construir, testar y mejorar.

No hay empresa que no hable de ser ¨Customer Centric¨, o presentación empresarial (da igual el sector o el tamaño de la misma) en la que no aparezcan referencias. Sin embargo no debemos tomarlo con una forma de promoción de nuestra empresa o equipo (mal entendido como marketing) sino como una forma de gestión. Esta forma de gestión debe de verdad pensar en el cliente, debe ponerlo en el centro de su estrategia y rediseñar sus operaciones en torno a estos conceptos. Para ello hay que realizar cambios, tenemos que repensar nuestros procesos, y proponer alternativas a estos. La gestión del cambio será lo más complicado de todo el proceso, pero indispensable si queremos que haga efecto.

Normalmente cuando nos enfrentamos a este tipo de cambios, y una vez ya metidos en harina, nos encontraremos enfrente de largas listas de cambios, o de cosas que queremos probar. El gran secreto de esta nueva forma de gestión es la priorización. Esta debe establecerse en torno a dos parámetros: impacto de negocio y coste de implementación.

A cualquiera que preguntemos, aunque sea de la empresa más rentable del mundo contará con recursos y presupuestos limitados. Y si pensamos en los casos más habituales en los que solemos trabajar, esa limitación de tiempo y dinero será incluso mayor. Históricamente la métrica más utilizada en este tipo de iniciativas era el ROI (retorno de la inversión). Sin embargo las coyuntura actual nos ha hecho pensar en como cambiar estas métricas por algo que se adecue más a las características del entorno corporativo donde el dinamismo y la agilidad ha impuesto el tiempo de comercialización (time-to-market) como la métrica a utilizar, y el feedback de los usuarios como el combustible para seguir progresando y evolucionando nuestro producto.

Si hablamos de la forma de diseñar o incluso un paso antes, de cómo afrontar la estructura de estas actividades debemos hablar de casos de uso completos, de procesos de principio a fin (obviamente con el cliente en el centro). Parece un mantra lo de evitemos los silos, pero es que la colaboración es lo único que nos salvará de la catastrofre. No creo que sea necesario volver a repetir la importancia de la correcta explotación de los datos, con el objetivo de poder tomar decisiones de forma holística. Pero como siempre, lo perfecto es enemigo de lo bueno.

Se escuchan muchos los conceptos de MVP (producto más viable), prototipo, versión, iteración, fase,.. Pero no tienen nada que ver, y no todas son intercambiables o son conveniente para nuestro objetivo. Además contamos con un problema añadido como es la diferente interpretación del mismo concepto por diferentes personas.

Personalmente yo soy más partidario del concepto de MVP. Se trata de el diseño y construcción de un primer producto, con funcionalidad completa (un mínimo de una funcionalidad es suficiente) y posiblemente básica, que será completado y mejorado en diferentes procesos posteriores. Para ilustrarlo con un ejmplo, pongamos el siguiente caso. Estamos en la industria del transporte y tenemos las siguientes opciones:

  • Construir un patin, luego un patinete, mejorarle las ruedas, convertirlo en bici, en triciclo, en un vehículo ligero, en un coche utilitario y en un deportivo
  • Construir una rueda con llanta de aleación, diseñar unas puertas para un deportivo, conseguir los mejores asientos de cuero del mercado,… Y seguir así hasta conseguir el deportivo completo.

Si miramos en estos dos ejemplos, ¿cúal será mas caro? ¿qué proceso tardará más en llegar al producto final? Pero más importante ¿qué proceso conseguirá un producto que se ajuste mejor a lo que el cliente busca? Pensemos que con el primer método, se puede ir ajustando en función de lo que el cliente vaya opinando y experimentando, por lo que se puede ir variando (pivotando según la jerga) , pudiendo incluso a llegar a un tractor o a un helicóptero. Sabemos dónde empezamos, pero no donde terminamos. Sin embargo con el segundo método, apostamos desde el principio a que nuestra idea es la correcta, a que los requisitos no cambiarán, y por lo tanto no habrá posibilidad de ajusta las características en función del feedback recibido.

La facilidad de introducir cambios, y por lo tanto mejoras, y ajustes para incorporar o actualizar nuevos requerimientos, está dinamizada por la exposición constante de nuestro producto al público (clientes), que nos irá diciendo como quiere utilizarlo, y que es lo que necesita. Podremos diseñar y construir justo lo que necesiten.

Una de las claves es sacar productos productivos, usables y con funcionalidad completa. Pero por encima de todo, hay que sentar las expectativas correctas, para que el cliente sepa a qué atenderse, y cómo entender el producto.

El desarrollo por fases se puede convertir en algo eterno. Pero como hemos visto en nuestro ejemplo, podemos hacerlo monetizando nuestros esfuerzos a la vez que entendemos qué fallos hemos cometido y ajustamos los mismos con las correcciones proveídas por los clientes. O podemos hacerlo de forma que todos los componentes sean perfectos (o casi), pero el resultado final sea inútil (ya que no es lo que el cliente busca o quiere). Mostar valor de forma rápido nos dará un valor añadido diferencial, y podremos adquirir una posición en el mercado que marque nuestro destino

Somos agile o utilizamos la famosa palabra

QAdTsSj8TOOWzlyLn3Rg_14248396556_aefcd9a926_o

Las necesidades del marcado cambian constantemente, surgen nuevas tecnologías y tendencias, y la importancia de llegar al mercado en el momento adecuado se vuelve crítico para tener el retorno de inversión que vamos buscando. Incluso en algunos casos se habla de que ese “time-to-market” es la nueva divisa en la que deberíamos movernos. La forma de trabajar está cambiando radicalmente. Ya no podemos planificar a largo plazo y ceñirnos únicamente a ese plan, sin mirar alrededor.

Pero en algunos otros casos se confunde agile con falta de estrategia. La estrategia o la visión no debe faltar en ningún caso, sino estaremos navegando a la deriva, y con ello llevaremos al traste todos los esfuerzos de los equipos con los que trabajemos y tendrá un impacto negativo muy visible en la empresa.

Para empezar, y asegurarnos que estamos hablando de lo mismo. ¿En que consiste esto de Agile? Como he comentado en el primer párrafo estamos viviendo una época de cambios constantes, lo que era válido hace unos meses está muy anticuado hoy, y necesitamos incorporar algún factor adicional en nuestras decisiones. Por este motivo, en el mundo del desarrollo del software surgieron las metodologías agile. Estas metodologías descomponen un problema grande en pequeños trozos y van desarrollándolo en pequeños entregables. Por lo tanto, las dos principales características que tienen estas metodologías son:

  • Flexible y dinámico: al partir el gran problema a resolver en pequeños trozos que son desarrollados de forma independiente, es fácil incorporar o cambiar nuevos requerimientos. Esto es fundamental en el ambiente en el que nos movemos, donde la incertidumbre y los cambios constantes guían nuestro trabajo diario. Debemos tener una estrategia general, pero los detalles pueden variar durante el transcurso del tiempo.
  • Llegar al mercado de forma más rápida: Al igual que los cambios pueden producirse de forma mucho más rápida y nuestros requerimientos pueden cambiar de un día para otro, debemos ser capaces de llegar al mercado con nuestro producto (con la calidad esperada) lo antes posible. Por lo tanto no estamos hablando de reducir la calidad, sino la frecuencia con la que sacamos nuevas funcionalidades, mejoras, arreglamos fallos o introducimos soluciones a nuevos requerimientos. Reducir el alcance global en pequeños trozos nos permitirá acelarar el avance y desarrollo del proyecto, dando visibilidad sobre cada pieza con más agilidad.

Aunque estas metodologías nacieron en el mundo del desarrollo del software, cada vez se están adaptando más al negocio, ya que en el fondo estamos hablando de como resolver  misma problemática, y tener un impacto positivo mayor y más rápido en el negocio.

Trocear el problema en pequeños componentes, que podamos resolver de forma unitaria, nos dará la flexibilidad de buscamos a la hora de cambiar, introducir o eliminar requerimientos, y si nos proporcionará la velocidad que necesitamos para salir al mercado (o tener listo ese componente) lo antes posible sin tener que esperar a tener la solución completa totalmente lista. Por supuesto que siempre hay dependencias y nos vamos a encontrar dificultades por el camino. La comunicación entre equipos es un factor decisivo. Los equipos de trabajo deben ser multifuncionales, para poder abordar el problema desde todos los puntos de vista, pero lo suficientemente pequeños para mantener ese dinamismo, agilidad y velocidad que necesitamos. De nada servirá intentar aplicar esta metodología a un equipo de grandes dimensiones, ya que seguiremos teniendo los mismo limitantes que encontrábamos antes (y por lo tanto el resultado será el mismo)

Y no olvidemos que el objetivo principal en desarrollar y entregar trabajo en menor tiempo. No tiene porque ser la solución entera al problema a resolver, pero si los pequeños componentes en los que los hemos subdividido. Ya sea de forma interna o externa seremos capaces de recibir feedback y ajustar lo necesario en el trabajo a desarrollar. Como he repetido en numerosas ocasiones en este blog, tenemos que probar la idea que tenemos en la cabeza (y en la estamos trabajando) lo antes posible.

Muchas veces nos autolimitamos ya que queremos salir al mercado con la solución más completa posible. Muchas veces esto es contraproducente. Por un lado, cuando antes estemos presentes, antes empezaremos ese dialogo con los clientes. Y ellos nos ayudarán a construir el resto del producto. Se ha visto en ciertas ocasiones que salir al mercado con un producto completamente terminado no ha sido la razón del éxito. Bien el cliente no estaba preparado para ello, o no era que o que buscaba. Mejor co-crear y evolucionar de forma iterativa. Pero co-crear no quiere decirse sentarse y esperar instrucciones, sino testar soluciones, ver que puede funcionar y recoger feedback constante del cliente para ver que necesita (todo ello siempre basado en datos)

Como podrás ver se trata de un proceso muy iterativo. Lanzaremos esos componente (lo que se conoce como una release), siempre que haya pasado ciertos criterios de calidad, ya que queremos seguir manteniendo la misma o mayor calidad, pero evolucionaremos esas características en el tiempo para hacerlas mas completas y perfectas. Ir poco a poco nos ayudará a entender mejor en que dirección movernos.

Agile es por lo tanto, un conjunto de metodologías que nos ayuda a entender mejor al cliente, con la que podemos desarrollar proyectos de forma más rápida y que debe entenderse como iterativo. Los equipos deben ser multifuncionales y pequeños para permitir esa agilidad. La eliminación de burocracia es uno de los puntos que debemos conseguir. En teoría el tiempo de eliminación de creación de documentación puede ser utilizado en el desarrollo como tal de la solución y dotarle de más calidad. Aunque esto no siempre es posible, por lo que por lo menos debe limitarse la burocracia al mínimo indispensable para mantenerlo bajo control. Sino estamos dispuestos a hacer estos cambios, dejemos de utilizar la palabra agile, y no queramos obtener resultados diferentes y más rápidos.