Puede que te preguntes… ¿Para qué quiero saber yo eso si mi producto funciona perfectamente y mis usuarios lo utilizan? Bueno, tranquilo, la próxima vez que te vayas a comprar una casa, puedes ir construyéndola tú sobre la marcha y ahorrarte los planos, total, si los ladrillos van a funcionar!

Esto es lo mismo, si de verdad quieres que tu producto sea escalable, sostenible y que puedas definir los puntos en los que medir, necesitas como mínimo una máquina de estados.

Tendrás que definir unos estados en los que tu producto podría estar, unas transiciones que provocarán que pase de un estado a otro, unos eventos que serán los que den lugar a esas transiciones y unos actores que activarán esos eventos.

Tranquilo, no te asustes. Voy a intentar explicártelo de una forma sencilla a través de algunas historias (Los más puristas no os cabreéis si veis alguna burrada).

Estados y transiciones, historias.

Historia 1: «Siempre a las 22h00 voy al cuarto y enciendo la bombilla.»

 

En este caso estamos representando dos estados y una transición:

Estado 1: Bombilla apagada

Estado 2: Bombilla encendida

Transición: Encender la bombilla

Pero… ¿Está completamente representada la historia? «Siempre a las 22h00 voy al cuarto y enciendo la bombilla.» cómo te habrás dado cuenta, no, no está completa, falta la primera parte… así que vamos a ello:

Ahora tendríamos:

Estado 0: Estado inicial

Estado 1: Bombilla apagada

Estado 2: Bombilla encendida

Transición (0–>1): Ir a las cuarto a las 22h00

Transición (1–>2): Encender la bombilla

Parece que ahora sí que tenemos todo ¿No? Pues la verdad es que no… Ya que podría ocurrir lo siguiente:

Aunque podríamos seguir con algún estado más, creo que de momento habéis captado la esencia, vamos a añadir otra historia

Historia 2: «Cuando una bombilla se me funde, al día siguiente voy a comprar una que funcione.»

Hemos añadido una condición nueva , dos estados nuevos y dos transiciones nuevas.

Estado 3: Bombilla fundida

Estado 4: Bombilla no fundida

Transición (3–>4): Renovar la bombilla

Transición (4–>1): Poner la bombilla

Hay que tener en cuenta que la condición nueva, provoca que la Transición(1–>2) se bifurque en Transición(1–>2) y Transición (1–>3).

Se ha omitido otras posibles causas por la que la bombilla no pudiera iluminar.

La Máquina de Estados

Ahora toca… Ver la máquina de estados! 😀

Una máquina de estados puede visualizarse de dos formas:

• Destacando los estados de los objetos y sus transiciones (Diagramas de Estados).
• Destacando el flujo de control entre actividades (Diagramas de Actividades).

Vamos a ver un Diagrama de Estados simple, cuyo objeto es la bombilla.

Teniendo esto muy claro, documentado y sabiendo cuales son los eventos que provocan los cambios de estados, es decir aquellas acciones que provocan una transición, podrías medir el tiempo en cada estado, cada cuanto ocurre el mismo evento… podrías medir todo lo que quisieras.

Por ejemplo: He comprado dos bombillas, una de la Marca Rana y otra de la Marca Sapo. Y quiero saber cual dura más. Si tengo muy claro cuales son mis estados y mis transiciones, solo me tengo que preocupar de recoger los eventos que provocan ciertas transiciones.

En el caso anterior de las dos historias, solo me tengo que preocupar de saber las fechas y horas de las transiciones:

• Transición (3–>4): Renovar la bombilla
• Transición (4–>1): Poner la bombilla

Con esto puedo saber aproximadamente cuánto dura cada bombilla e incluso cuánto tardo en ir a comprar la bombilla (dependiendo de cómo defina los eventos).A

La Máquina de Estados en Productos Digitales

Si has llegado hasta aquí puede que te estés preguntando… ¿Y esto qué tiene que ver con Productos Digitales? Pues mucho… te voy a mostrar una máquina de estados para un producto de compra de bombillas desde casa basándome en los estados antes definidos:

En cualquier producto digital deberías tener definido tus estados, transiciones y eventos. A ser posible «agrupados» en «Procesos» (Lo que antes hemos llamado «historias»). De esta forma podrás medir tiempos, detectar problemas y sabrás donde encaja mejor una nueva funcionalidad y las dependencias que puede provocar.

Un Producto, recordemos que solventa un problema, es un servicio y tiene su proceso, no debemos definir estados en función del objeto como hemos hecho antes, sino en función del proceso, desde el punto de vista de uno de los actores. Una Máquina de Estados más realista sería la siguiente:

¿Cuándo y cómo uso la Máquina de Estados?

¿Cuándo? Desde el primer momento.

¿Cómo? Compartiéndola con tu equipo y que todo el mundo entienda la operativa de vuestro Producto, antes de implementar una funcionalidad busca donde encaja mejor y a que afecta.

Como verás, no hace falta que la notación que utilices sea ningún estándar, ni que hagas unos dibujitos super molones, lo importante de la máquina de estados es que represente la realidad y que tú y tu equipo la entendáis, que creeis un entendimiento común en torno a ella.

Diría que la parte más importante es que represente la realidad, una máquina de estados no se hace al principio del producto y se deja ahí morir… ¡Hay que tenerla actualizada para que sea útil! Así que ya sabes, la próxima épica o historia de usuario que vayas a meter en el sprint, que no se te olvide contrastarla con la máquina de estados y actualizarla si fuera necesario 😉

Teniendo una Máquina de Estados actualizada, entendida y que representa la realidad, el escalado, la sostenibilidad y la medición de tu producto te resultará mucho más fácil.

Y lo más importante, evitarás que tu Producto se convierta en un Frankenstein de un conjunto de funcionalidades sin interrelación entre ellas.

Y… esto es todo, por el momento. Si este concepto te ha parecido interesante, en el curso de Digital Product Manager que se imparte en The Hero Camp podrás aprender cómo hacer un Máquina de Estados con ejemplos de Startups reales, y no solo este concepto sino otros muchos también imprescindible como son los locators, el framework AARRR, Design Sprint, a mover KPIs, estrategias como la de océano azul… entre otras, obtendrás todas las herramientas que un buen Product Manager necesita. ¿Te vas a perder la posibilidad de conseguir una ventaja competitiva respecto a otros candidatos? Yo no lo haría. Reserva tu plaza para la próxima edición aquí.

Por último, espero que los más puristas no se hayan asustado por la gran cantidad de suposiciones y simplificaciones que he realizado para ilustrar el concepto… Para vosotros, puristas, amigos de la exactitud y disciplina, os dejo varios enlaces donde profundizar en el tema desde un punto de vista más ingenieril (No apto si tienes prisa y tampoco son imprescindibles para ser un buen Product Manager).

Hasta la próxima

Enlaces:

• Modelado con Máquinas de Estados
• Comportamiento Dinámico de un Sistema
• Diagramas de Estados y Diagrama de Actividades

Post de: Manuel López