Gestión del cambio y expectativas
Expectativa
Del lat. exspectātum ‘mirado, visto’.
1. f. Esperanza de realizar o conseguir algo.
2. f. Posibilidad razonable de que algo suceda.
3. f. Posibilidad de conseguir un derecho, una herencia, un empleo u otra cosa, al ocurrir un suceso que se prevé.
Diccionario de la lengua española. Real Academia Española
Si el otro día comenté el concepto MAYA y el equilibrio entre neofilia y neofobia para que un rediseño (o un diseño) sea calificado como «bueno», hoy quiero reflexionar sobre procesos más intrínsecos del cambio y las expectativas.
Porque siempre que abordamos un rediseño, o un nuevo proyecto, tenemos lo que encontramos en la primera acepción del Diccionario de la RAE: La esperanza de conseguir un objetivo determinado. Por tanto, antes de abordar el proyecto, tenemos que hacer un análisis del objetivo (u objetivos) que queremos conseguir. Sin este análisis, sin una meta clara, no podemos trazar una ruta y tampoco tendremos expectativas. Por tanto estamos equiparando las expectativas al objetivo.
Y el objetivo debe adecuarse al mercado, a nuestro público, al negocio y a la estrategia. Cada uno de estos conceptos maneja sus expectativas, por lo que el producto que diseñamos tiene un roadmap donde confluyen varias expectativas, objetivos. Definir estos objetivos para llegar a un compromiso es básico para ir cumpliendo con cada sprint, o fase, del diseño del producto.
Alinear es la clave
Cuando tenemos equipos muy diferentes, lo normal es que la visión del diseño del producto sea divergente en las expectativas de cada equipo. Y aquí es importantísimo la gestión del cambio, de las expectativas. De la segunda acepción del término expectativas, quiero destacar la palabra «razonable».
La visión de un equipo de UX/UI puede chocar con la de negocio, con la del equipo de desarrollo y viceversa. Por eso en las dinámicas de priorización deben participar todos los equipos, para acordar entre todos un MVP y el MMP
MVP
Mínimo producto viable. Es decir, lo que de manera razonable, tiene que tener nuestro producto. Cuando se prioriza con el método MoSCoW (Must have, Should have, Can have y Won’t have) utilizamos esos Must have para definir el MVP. Pero un MVP puede no ser un producto que sacar al mercado, por eso pasamos a la figura del MMP.
MMP
Producto mínimo marketeable. Nos permitimos la licencia del anglicismo para entender el acrónimo, pero sería el producto mínimo comercializable. O, dicho de otra manera, lo que de manera razonable, tiene que tener un producto para poder lanzarlo al mercado. Y esta definición se hace, igualmente, al principio del diseño de producto, con la participación de todos los equipos involucrados.
De esta manera, definiendo el MVP, el MMP, las historias de usuario, conseguimos alinear las expectativas (lo que razonablemente se puede alcanzar) de todos.
¿Y cuándo las expectativas no están alineadas?
TLDR: No se debería empezar porque el proyecto está abocado al fracaso.
Esta situación la he vivido en la mayoría de los proyectos en los que he estado. Desde estrategia se tiene una idea, negocio la «compra» y pone a marketing a «venderla», mientras se diseña como se puede y llega a desarrollo con los hitos apretadísimos. Esto, así contado, suena exagerado, pero es la realidad de muchas empresas donde o se hace gestión en cascada o metodología Scrum en falso. Con la excusa de «no tenemos tiempo», no se invierte en investigación, en la fase de análisis tan necesaria, no se testea el concepto y, en definitiva, no se alinean las expectativas de los equipos. Y el resultado es malo:
- Los diseñadores no están convencidos con el resultado porque no se ha tenido en cuenta al usuario
- Los desarrolladores se quejan de que no están bien definidas las historias de usuario
- Marketing esperaba otra cosa y cree que se podría haber hecho más
- Negocio ve que no se vende como debería y empieza a buscar cambios con prisas
- Estrategia cree que se podría haber hecho todo un poco mejor y que por eso no se ha vendido bien
- Y el usuario no lo compra porque no se ha hecho pensando en el
La metodología no es la panacea, pero si la adaptas, ayuda
¿Cómo se soluciona? En las metodologías ágiles encontramos respuestas a estos problemas. Pero tampoco hace falta volverse loco. Por eso, hay ceremonias que son la clave para poder crear un producto:
- Sprint inception. Donde se conozca todo el equipo, se presente el producto, a quién va dirigido, un primer journey de usuario, definir el MVP y el MMP y, lo más importante, se haga un test de concepto con un prototipo. Podemos hacer ese test de una aplicación, o producto, completo. O podemos testear las funcionalidades básicas que aportan valor al producto. Los acuerdos de DoD o DoR (Definition of Done, Definition of Ready), construir la primera versión del backlog, decidir los tiempos, priorizar y construir el primer panel.
- Seguimiento. En SCRUM se hacen las famosas dailies, weeklies, terminas cada sprint con una review y, después, la retrospectiva. Aquí es donde mejor puedes adaptar las ceremonias a las necesidades de la empresa o proyecto. En vez de dailies, puedes hacer weeklies… O seguimientos cada 2 días. El sprint review es un cierre del sprint con una entrega, se puede aprovechar un seguimiento para esto sin ser la ceremonia completa. Y la retrospectiva viene bien a nivel equipo, como reflexión de qué funciona y qué no de la metodología. Si no tenemos mucho tiempo, esta reflexión se puede hacer una vez terminado el MVP, por ejemplo.
¿Satisfacción = Percepción – Expectativas?
Esta fórmula de la satisfacción es la utilizada en la metodología ECEL. Según esta metodología, las expectativas son el mayor handicap para que un cliente, o usuario, esté satisfecho con un producto digital. Porque las expectativas que tiene nuestro cliente son las que, restadas a la percepción real de lo que hace el producto, son las que determinan su grado de satisfacción. Si podemos explicar al cliente lo que es razonable, igual rebajamos sus expectativas y así su grado de satisfacción es mayor.
En nuestro caso, las expectativas son las que hemos acordado en equipo. Las hemos materializado en historias de usuario, las hemos priorizado y hemos decidido cuando se consideran terminadas y listas para componer una primera versión del producto.
Por tanto, la gestión de cualquier producto, proyecto, cambio, se puede reducir a la gestión de las expectativas, y lograr con trabajo de definición en equipo y gracias a metodologías ágiles.
