Este mes pasado andamos el primer paso de un nuevo proyecto con nuestro cliente y compañero Grupo Ubesol.
Como en todos los proyectos, nuestro primer paso como equipo técnico es entender cuáles son las necesidades y expectativas del usuario que va a utilizar nuestro producto. Para estos menesteres, cada maestrillo suele tener su librillo, aquello que le ha funcionado con anterioridad, su experiencia con otros proyectos, etc.
Nosotros decidimos romper un poco con nuestra experiencia pasada y aplicar un modelo muy adoptado por las metodologías ágiles: el lean inception (con algunas adaptaciones). ¿Por qué lean inception y no una reunión tradicional con los jefes de cada área (o no solo con ellos)? Porque pone en el centro de la toma de requisitos al conocimiento del usuario, de sus expectativas, sus necesidades, sus habilidades. Porqué permite al usuario del producto decidir sobre cómo quiere priorizar y organizar las entregas. Porqué nos da la tranquilidad de ser un proceso transparente, en el que la comunicación es continúa y en el que las entregas se pactan con las conclusiones.
Para nosotros, el éxito del proyecto reside en que el usuario final sea feliz con nuestro producto, y le aporte el máximo de información con el mínimo de intrusión en su día a día. Y sin conocer al detalle quién es quién en el proyecto, y que hace cada uno, creemos que este resultado, como mínimo es complicado de conseguir.
¿Como funciona esto del lean inception?
A través de unas prácticas o talleres se pretende llegar al máximo de conocimiento compartido entre equipo técnico y usuario final de las necesidades que se deben resolver con el proyecto.
Empezamos nuestro viaje con un cuadrante en el que determinamos conjuntamente equipo técnico y usuarios qué es, qué hace, qué no es y qué no hace el producto que vamos a preparar. De esta forma sentamos las bases claras para entender el alcance del proyecto. Junto con esta actividad, definimos los objetivos del proyecto y analizamos cuestiones como qué esperan conseguir con la implantación del nuevo producto, dejando claro para ambas partes qué necesidades se deben satisfacer.
Nuestra siguiente actividad fue definir los perfiles de los usuarios que iban a intervenir en el proyecto, sus expectativas, sus objetivos, sus habilidades y un punto muy importante: cuáles son las responsabilidades de cada perfil. Esto nos permitió entender quién va a utilizar nuestro sistema y pensar en cómo lo va a utilizar.
Una vez tuvimos claros los objetivos y quiénes iban a utilizar el sistema, empezamos a construir el castillo de acuerdo con qué funcionalidades queremos que tenga nuestro sistema. Carta blanca para pedir lo que sea… Solo una premisa, las funcionalidades se debían definir aplicando el patrón:
“Dado un escenario…
Cuando suceda un evento…
Entonces se obtendrá un resultado…
Para cumplir con el objetivo…”
Es un sistema heredado del Behaviour Driven Design que nos obliga a todos a pensar y a definir los criterios de aceptación junto con la funcionalidad.
La implementación de las funcionalidades
La siguiente actividad fue la de “pintar” como queríamos que se implementaran estas funcionalidades, el sketching. Pizarrita y rotulador, y definimos la experiencia de usuario (UX) junto con el usuario: qué campos, qué hipervínculos… todo lo necesario para que sea lo más útil posible.
La última etapa del proceso fue de las más interesantes y creo que de las más duras para el cliente. Debíamos ordenar y priorizar todas las funcionalidades que se definieron. Utilizamos el patrón MoSCoW para la priorización (Must, Should, Could, Wouldn’t, o debe, debería, podría y podría no estar). Obligamos a cada perfil a marcar como mínimo una funcionalidad con cada categoría, lo que les obligó a pensar si realmente lo que habían pedido era o no realmente necesario.
A partir de estos datos recogidos, estamos desarrollando un documento funcional y vamos a organizar bloques de entregas en iteraciones. Desde la primera entrega, estaremos aportando funcionalidades listas para entorno productivo, aportando valor al cliente desde el minuto 1.
Se nos quedaron muchas de las actividades propuestas por el modelo en el tintero (el dimensionamiento, los viajes de usuario, el canvas mvp, …), pero a pesar de eso, fueron unas jornadas en las que tanto el Grupo Ubesol, como Sothis pusimos mucho conocimiento en común, y marcamos unos objetivos coherentes, sin falsas expectativas, con absoluta transparencia…
Para más información:
- The Agile Samurai : How Agile Masters Deliver Great Software
- https://www.caroli.org/es/
- Lean Inception: Creando conversaciones hacia un producto exitoso