En el último artículo vimos cómo empezar a organizarse para trabajar en equipo y qué preceptos tenemos que seguir a la hora de trabajar con un grupo compuesto por personas de diversas especialidades. Hoy nos toca hablar de qué técnicas seguir para resolver un problema, es decir, para desarrollar una solución de software.
Siempre que queramos encarar un problema, debemos empezar declarando una suposición y después trabajar con hipótesis.
<<¿What? ¿De qué me estás hablando, Pedro?>>
Vale, dicho así, sin explicación, es un poco difícil de ver. Supongamos que tenemos un problema y queremos resolverlo. No debemos dar por hecho que nuestra definición de problema es real, porque muchas veces comprobaremos que no es así. Así que trabajemos con suposiciones. Vamos a poner un ejemplo, que es la mejor manera de que lo visualicéis.
Primero reunimos al equipo. Es necesario que en el grupo estén representadas todas las disciplinas (diseño, desarrollo, etc), y también que estén los expertos que puedan hablar del problema en sí. Por ejemplo, si nuestro problema parece ser que nuestra web tiene una tasa de rebote demasiado elevada, sería importante que en la reunión estuviera tanto la gente de marketing como la gente que lleva las estadísticas.
Una vez el equipo ubicado y preparado, es necesario hacer pública cierta información que nos ayude a comprender el problema y realizar las suposiciones. Esa información sería:
- Informes analíticos y de usabilidad que nos indiquen cómo se está usando el producto. En el ejemplo de la tasa de rebote, necesitaríamos datos de analítica web que nos indiquen cómo se comportan las personas que visitan nuestra página web.
- Información sobre los intentos pasados de arreglar el problema. Esto sólo vendrá al caso si no es la primera vez que ponemos este problema sobre la mesa.
- Análisis sobre cómo el problema afecta al rendimiento de la compañía.
- Análisis de la competencia que muestre cómo la misma está solventando este problema (si es posible).
Bien, todo esto ayudará, durante el proceso, a que todos los miembros del grupo no sólo entiendan de qué problema estamos hablando, sino que tengan toda la información que rodea al mismo.
Ahora vamos a empezar a trabajar sobre el problema. Para ello, debemos hacer una declaración de problema.
¿Qué ha de contener esta declaración?
- Los objetivos actuales del producto o servicio.
- El problema que se desea solucionar.
- Una petición explícita de mejora que no especifique cuál es la solución.
Muy bien. Pongamos un ejemplo un poco más práctico. Imaginemos que tenemos un SaaS (Software as a Service) que permite a otras empresas el llevar su contabilidad general sin necesidad de contratar con gestor. Y ahora vamos a hacer una declaración de problema:
Primero, los objetivos actuales del servicio:
“Nuestro servicio ha sido diseñado para permitir a empresas de pequeño y mediano tamaño gestionar su contabilidad de forma sencilla a través de una plataforma online que ponemos a su disposición por un 20% de lo que les costaría contratar a un gestor que realizara las mismas labores.”
Segundo, el problema a solucionar.
“La web comercial que se encarga de permitir el alta en nuestro servicio muestra una tasa de rebote muy alta (95%). “
Tercero, petición expresa de una solución.
“Debemos hacer que la tasa de rebote disminuya a un valor razonable (un 40%) y las visitas se queden más tiempo en la página para que, potencialmente, decidan adquirir nuestro producto.”.
Fijaos en que son tres párrafos muy sencillos, pero que permiten al grupo el tener muy claro qué problema hay y, sobretodo, qué se pide que solucionemos. Por supuesto, podría haber más problemas, o este problema podría derivar de otro, pero ahora estamos viendo un caso sencillo. Lo importante aquí es ser capaz de sacar las suposiciones a partir de estos párrafos. Vamos a ver qué suposiciones podemos obtener:
- Una gran parte de los clientes que llegan a nuestra página web no son parte del segmento de clientes al que nos dirigimos.
- Nuestra página web no explica de forma adecuada qué ofrecemos.
- Nuestra página web no está bien implementada desde un punto de vista técnico.
- Llega tan poca gente a nuestra página web que el porcentaje de tasa de rebote no es concluyente.
Podríamos obtener más suposiciones. Cada miembro del equipo daría su opinión y, de seguro, obtendríamos muchas más que estas cuatro, pero para poder explicar cómo trabajar con las hipótesis nos vale de momento.
Ahora que tenemos una lista de suposiciones, es el momento de trabajar con las hipótesis. El problema es que tenemos cuatro suposiciones y ahora podríamos preguntarnos sobre cuáles serían prioritarias. La respuesta sobre el papel es muy sencilla: primero aquellas que impliquen más riesgo para el negocio.
Así que una vez decidida la suposición que supone mayor riesgo para nosotros, vamos a trabajar en su hipótesis. Para este ejemplo, yo voy a elegir la primera suposición: una gran parte de los clientes que llegan a nuestra página web no son parte del segmento de clientes al que nos dirigimos.
Fijaos en que si esa suposición fuera cierta, tendríamos un problema grave, ya que no estaríamos consiguiendo llegar al segmento de clientes deseado. O, peor aún, podríamos descubrir después que sí estamos llegando al segmento que buscábamos pero resulta que no es el adecuado para nuestro producto y no necesita nuestra solución. Pero vayamos por partes. Primero, hay que coger la suposición y transformarla en una hipótesis.
¿Cómo se hace esto? Veamos el formato normal de una hipótesis:
Consideramos que esta declaración es cierta.
+
Sabremos que lo hemos hecho bien/mal cuando contemos con el siguiente feedback del mercado: [lo que corresponda].
Vemos dos partes claramente diferenciadas: declaración sobre algo que consideramos cierto y declaración del resultado que demostrará si tenemos razón (o no).
Ahora vamos a aplicarlo a la primera suposición que hemos hecho: una gran parte de los clientes que llegan a nuestra página web no son parte del segmento de clientes al que nos dirigimos.
La hipótesis podría ser algo así:
“Consideramos que las personas que están llegando a nuestra página web no son nuestro público objetivo”.
“Sabremos que esto es cierto cuando revisemos nuestra estrategia de marketing para dirigirnos al segmento clientelar adecuado y, después, verifiquemos que la tasa de rebote ha disminuido”.
Y la cosa no acaba aquí, pues, en este caso, habrá que revisar y hacer suposiciones e hipótesis nuevas sobre qué ha fallado cuando hemos realizado nuestra campaña de visibilidad hacia los clientes.
Pongamos otro ejemplo. Imaginemos que ahora creamos una hipótesis sobre la suposición siguiente: nuestra página web no explica de forma adecuada qué ofrecemos.
Sería algo así:
“Consideramos que las personas que están llegando a nuestra página web no entienden qué les estamos ofreciendo”.
“Sabremos que esto es cierto cuando cambiemos el contenido de nuestra landing page para hacerlo más claro e intuitivo, para después verificar que la tasa de rebote baja hasta un 40%”.
O también podemos crear más de una hipótesis sobre la misma suposición. Pongamos otra:
“Consideramos que las personas que están llegando a nuestra página web no entienden qué les estamos ofreciendo”.
“Sabremos que esto es cierto cuando hagamos entrevistas a clientes potenciales en las cuáles les mostraremos nuestra landing page y les preguntaremos sobre el contenido de la misma y el valor que le dan”.
Conclusión – Suposiciones e Hipótesis
Estos ejemplos son muy genéricos y sencillos. Para coger la idea son suficiente. En el día a día empresarial las suposiciones e hipótesis suelen ser más complejas. Lo importante es que entender cuál puede ser el problema, qué solución le podemos dar y cómo medimos si la solución ha funcionado o no.
Podríamos hablar de subhipótesis, protopersonajes y otros aspectos relacionados con las creación de suposiciones e hipótesis, pero el artículo de hoy trata de haceros conocer el concepto y que podáis empezar a trabajar con él.
Si no leíste la primera parte de esta serie, te recomiendo que lo hagas para tener una base sólida sobre la que construir. Puedes encontrarla aquí: Cómo trabajar en equipo (1/2).
