Product Owner

Curso de gestión de proyectos con metodologías Ágiles y enfoques Lean

En Twitter vi que Israel Alcazar publicaba que comenzaba de forma gratuita el curso «Gestión de proyectos con metodologías Ágiles y enfoques Lean» en la Fundación Teléfonica Miriadax.

Como estaba buscando información sobre Kanban y había un módulo sobre ello decidí hacerlo durante el ERTE.

La mayor parte del curso hablaba sobre SCRUM, framework que conozco bastante bien, pero no me importaba volver a escuchar ciertos temas y así aprovechaba a conocer a Alcazar como profesor (totalmente recomendable).

Seguir leyendo «Curso de gestión de proyectos con metodologías Ágiles y enfoques Lean»

Diseño del proceso de modificar una reserva

Este febrero se ha puesto en producción una de las automatizaciones más esperadas en la empresa: permitir al usuario la modificación online una reserva.

Gracias a este cambió se redujo en un 50% el trabajo manual de los agentes.

Saraclip

Hasta este momento cuando un cliente quería solicitar una modificación lo que hacía era ir al detalle de la reserva y rellenar un formulario con los cambios que quería.

Posteriormente un agente le informaba y se tramitaba el cambio si era aceptado.

Modificación online

En esta primera versión (según ciertas condiciones de la reserva) el cliente al solicitar «Modificar reserva» aterriza en una nueva página donde:

  • Se muestran los datos principales de la reserva actual
  • Se le explica el proceso de modificación de forma visual
  • Se le permite lanzar la nueva búsqueda
Seguir leyendo «Diseño del proceso de modificar una reserva»

Curso Product Owner

La semana pasada tuve la suerte de ser elegida para realizar el curso oficial de Scrum Manager de Product Owner en el Centro de Tecnologías Avanzadas de Zaragoza.

Nos presentamos más de 100 personas a la prueba, eligiendo sólo a 40 para la realización de los cursos mañana y tarde, osea que fue una sorpresa que me llamaran ya que el nivel era alto.

Javier Morillo de Estratecno fue el profesor, el cual me gustó mucho. La clase era de nivel, y creo que todos nos esperábamos algo más de nivel en el contenido del curso, pero supongo que habrá cursos avanzados.

Desde que conocí el manifiesto Agile, no he creído en otra forma de trabajar. Es decir, leerlo fue sentirme identificada con la forma de trabajar en el desarrollo de productos digitales que realizaba en mi día a día. Cuando a finales del año 2016 tuve la suerte de entrar como product owner a Flywire de la mano de Xavi, aprendí muchísimo sobre este rol, básico en el framework Scrum.

Dentro de los roles del Scrum, el product owner, aparte de sus funciones básicas de administración del product backlog, debe tener conocimientos de captura y gestión de las necesidades de los stakeholders y usuarios, profundizando en ellas para obtener el valor real y trasladarlas al equipo.

Es por ello que mi background como UX, tanto por las técnicas y conocimientos adquiridos como por las softskills que se necesitan, lo veo como algo que complementa a la perfección el rol de product owner.

User Story Mapping de un producto de reservas de restaurantes

Lo que más me gustó del curso fuero las dinámicas que realizamos en equipo, como el User Story Mapping para captar el mayor número de funcionalidades de un producto, o el Poker planning estimando el peso de animalejos.

Seguir leyendo «Curso Product Owner»

Proceso de diseño centrado en los datos

Estos pasados meses hemos estado investigando los eventos que realizan los usuarios durante el proceso de búsqueda obteniendo información para detectar errores y orientar los nuevos diseños.

Esta forma de trabajar #DATADRIVENDESIGN o DDD es la ideal. Requiere tiempo para obtener los datos, analizarlos y ver qué hacer, pero es la única manera de tomar decisiones totalmente objetivas.

En este post os quiero comentar algunos de los datos que se han encontrado, las conclusiones obtenidas y las acciones realizadas.

Búsqueda por alojamiento

Casi un 60% de la gente busca por alojamiento. Lo cual quiere decir que ya han hecho el proceso de investigación antes y tienen muy claro a lo que van: a ver precio.

A raíz de esto,  vimos que esa búsqueda por hotel no daba disponibilidad. Por ello, aparte de investigar si hay algún problema, se pueden pensar en mejoras para ofrecer al usuario vías alternativas.

Por ejemplo hace poco, se puso un enlace rápido en el mensaje de no disponibilidad al calendario para cambiar las fechas.

Enlace nueva búsqueda

O mostrar otros alojamientos similares, o cuándo hay fechas disponibles en el alojamiento buscado.

Uso de los mapas

Una de las cosas que más ha sorprendido es lo poco que usan los usuarios la funcionalidad de ver el mapa con todos los alojamientos.

Mapa en el listado

Este uso es incluso menor si la búsqueda es por un alojamiento en concreto, un alto porcentaje como ya se ha indicado antes.

Es decir, el enlace para ver la ubicación que tenemos en cada alojamiento si que es usado (no hay que olvidar que este enlace también muestra la ubicación del resto). Pero el general, el del dibujo del mapa que se encuentra en la parte superior no.

Como en móviles ocupa mucho espacio, aparte de recargar el diseño de la interfaz, se ha decidido eliminarlo y hacer un rediseño simple de esa parte. A futuro esperamos hacer más cambios.

Acciones en el listado

Los acciones más realizadas por los usuarios en el listado (aparte de pasar a la ficha son):

Filtrar (16,39% ) > Modificar búsqueda > Galería > Ordenar > Paginar

Y en menor medida:

Ver el Mapa individual > Ver Mapa todos

Estos datos cambian si la búsqueda es por alojamiento, con menor uso de los filtros, el ordenar…

¡Está claro que el usuario busca algo en concreto!

Barra fija

En móviles, tanto en la ficha como en el listado al hacer scroll se mostraba al usuario una barra inferior con opciones.

barra-abajo-listado

Del listado, la única opción usada por un 10% de los usuarios era Ordenar. El resto: Filtrar, Ver mapa (todos), Buscar y Subir arriba, no. Esto nos dejo completamente asombrados ya que pensábamos que era tremendamente útil.

Gracias a los datos vimos lo que interesaba a los usuarios de verdad

En la ficha en móviles solo utilizaban y muy poco, la funcionalidad de «Volver al listado». El resto, nada.

Interacciones en la ficha

Aparte algunos navegadores sacan su barra de navegación propia también ahí abajo, lo que causaba problemas. Por ello se ha decidido eliminarla y reubicar las opciones más usadas en otro lugar.

Seguir leyendo «Proceso de diseño centrado en los datos»

Cambiando la tecnología el proceso de reserva

Llevamos unos meses en www.centraldereservas.com migrando el proceso de reserva a otra tecnología con la idea de separar y abstraer toda la parte de presentación del motor de reservas (integración con mayoristas, algoritmo de precios, cobros…)

Eso nos permitirá trabajar ambas partes del sistema de una forma más flexible e independiente, con diferentes tecnologías, y más posibilidades de testeo y personalización.

La comunicación se realiza a través de un API XML la cual también se ha ido adaptando y mejorando al ver la información que se necesitaba.

Como podréis imaginar el proceso no ha sido todo lo simple que parecía al inicio ;P

Por ello a modo de retro me gustaría contaros la experiencia 🙂

El equipo era multi-distribuido, con personas trabajando en remoto y que no habían trabajado nunca juntas.

Esto en sí, no tiene que ser un problema si se sabe gestionar bien, y de hecho se ha creado un equipo del cual me siento orgullosa de formar parte, totalmente unido y con ownership del proyecto.

Otro de los puntos a tener en cuenta es que la tecnología era totalmente nueva. Era el primer proyecto que se iba a realizar de esa forma y sólo una persona del equipo era experta.

Pero el principal punto importante a mi modo de ver que retrasó el asunto fue que al principio la persona que más conocía del antiguo sistema no participaba. Además parte del equipo era nuevo en la empresa, es decir, con cero conocimiento del producto y de las decisiones técnicas y comerciales tomadas en el pasado.

Eso si es un proyecto sencillo, se conoce el negocio y se tiene buena documentación aun puede salir bien. Pero no se cumplían todas estas condiciones, siendo muy complejo, con muchas variables e historia detrás.

Lo bueno es que el tema se solucionó justo cuando yo volvía a la empresa y entraba al proyecto, añadiendo así 2 personas más al equipo, ambas con conocimiento del negocio. Top!

Formulario

La idea inicial era clonar en diseño al sistema antiguo con algunas pequeñas mejoras para ir más rápido y así poder comparar los datos en los 2 sistemas.

También se decidió salir antes con una de las partes (la que se pensaba más sencilla), que podía además ser usada por el antiguo sistema y por otras líneas de negocio. El diseño, basado en el actual era más limpio y constante, con una mejor usabilidad, tanto a la hora de seleccionar opciones, ver la información o la gestión de errores en los formularios.

Aunque fueron unas semanas divertidas y duras de encontrar bugs, testear con todos los dispositivos posibles las mil combinaciones, subir mejoras… la recompensa mereció la pena, aumentando la conversión del viejo sistema.

Seguir leyendo «Cambiando la tecnología el proceso de reserva»

3 consejos para escalar equipos técnicos por Jorge Gómez Sancha

Hola,
os recomemiendo mucho escuchar los PodKast de KFund ya que tratan muchos temas variados con gente super interesante. En concreto este de Jorge Gómez Sancha (@jorgesancha), actualmemnte trabajando en Carto como, hablando sobre «Escalando equipos técnicos», un tema que siempre me ha parecido super interesante ya que creo que uno de los mayores problemas de las empresas es la gestión del talento y del trabajo cuando comienzan a crecer.

Escalando equipos

Imagen extraída de la web de blog.kfund.vc

Como no, mucho mejor escucharlo en directo. Pero me he quedado con 3 consejos que da al final y que me gustaría resumir:

  1. Tener claro a quién reporta cada uno. Al crecer lo que funcionaba hacer 3 meses ya no funciona por lo que hay que ir definiendo la forma de trabajo continuamente.
  2. Un único sitio en el que saber que tiene que hacer cada persona. Que cualquiera de la empresa pueda mirar y sepa lo que esta haciendo y su siguiente prioridad. Parece fácil pero al crecer no lo es. Lo primero que hizo al entrar en Carto fie estandarizar el Kanban, con una única forma de gestionarlo. Luego cuando lo dominen que ya evolucionen (si te gusta esto te puede interesar este resumen sobre Equipos de alto rendimiento, de la genial charla de Israel Alcazar (@ialcazar) en la CAS 2017 ).
  3. Comunicar mucho más de lo que crees que tienes que comunicar. Por qué estamos haciendo las cosas «estamos haciendo esto porque la estrategia era uno, dos y tres», repetir las cosas mil veces… Nunca hay tiempo, nunca es prioritario pero hay que hacerlo.

Y es que como comenta Jorge, muchas veces en una empresa se asciende a alguien interno que está haciendo un buen trabajo y se le convierte en Manager o CTO, o VP…

Pero eso no quiere decir que se le de bien gestionar, saber tratar a la gente y todo lo que implica el trabajo además de que seguramente va emplear muchas más horas de lo que cree. Sobre todo en startups donde el perfil puede ser más joven, Sancha recomienda dedicar tiempo a darles pautas: tienes que hacer “One to one”, checkings….

Yo he estado en empresas que he visto como ponían a gestionar a magníficos desarrolladores, pero que no servían para nada sabiendo motivar al equipo, controlando el avance el trabajo en base al road map planteado, reportando al CEO o a Inversores las nuevas mejoras o los problemas encontrados, no sabiendo pedir ayuda al ver que todo se le escapaba de las manos…

Lo malo es que cuando el puesto es alto, aunque los de abajo vean lo que ocurre, desde arriba aun se puede tardar varios quarters en ver lo que pasa. Y eso es mucho dinero. ¿Y una vez detectado? Posibles soluciones: ponerle un coach que le enseñe, cambiarlo de posición al puesto que antes hacía tan bien, poner a otra persona a hacer la parte que menos controla…

Lo dicho, espero que os guste el podKast, a mi me ha parecido genial!

La intuición no aplica en Ontruck

Seguimos con los post de la masterclass de @nachogil (diseñador de producto en Ontruck) en Factorystartup tocando ahora el tema de cómo realizan el proceso de diseño de producto.

Nacho nos cuenta el proceso de 8 pasos que siguen con cada nuevo desarrollo o proyecto basado en las características del producto de Ontruck.

Los 3 productos de Ontruck no son para cualaquier usuario. Es decir, no es un producto genérico tipo Facebook o Gmail. Con lo cual, el equipo de producto no es usuario de su producto, por lo que basan su aprendizaje en ser humildes y escuchar.

Eso les obliga a construir el producto que necesitan nuestros usuarios.

1. Comprender

  • Las ideas o problemas proviene de cualquiera.
  • Lo primero que hay que hacer es entender el problema.
  • No se piden soluciones, se plantean problemas. Las soluciones están sesgadas por la persona que las propone. Por cómo ve el problema, por cómo le afecta.
  • Nos importan los problemas, no las soluciones. Los problemas son más fáciles de compartir y discutir.
  • Observamos a los usuarios para comprender sus necesidades.

Y dijo esta frase que más valdría que muchas personas que cuestionan el coste de la UX y los métodos de research (investigación) deberían tener en cuenta:

Perder 1 día en ver y hablar con varios clientes te evita gastar 1 mes en desarrollo.

Clarito, ¿no?

2. Divergir

Una vez definido el problema, en una sesión de 2 horas, se reune todo el equipo (desarrollo, diseño y producto) e intentan pensar en soluciones obvias. El objetivo es intentar no seguir esas ideas, y generar entre todos la mayor capacidad de innovación.

Crazy Eights

Para ello, para diverger, y generar el mayor número de posibles soluciones, aplican técnicas para divergir y encontrar otras ideas, como Crazy Eights, Mapas mentales, Mapas de empatía,  How Might we…? o simplemente coger post-its y poner ideas y luego clasificarlas…

3. Decidir

En esta etapa el objetico es de las ideas viables que entran en scope clasificarlas y quedarse con una. Para ello:

  • Se decide el alcance del proyecto (scope).
  • Siempre se orientan a reducir el desarrollo. Mínimo desarrollo posible en todo (minimal waste, puro lean!), tanto en diseño como en código. Si puedes falsear la solución con algo manual, comprueba que es la adecuada y ya invierte el tiempo en hacerlo.
  • Se comparte con Tech, QA, Operaciones, Ventas y Mkt.
  • El resultado suele ser un plan para dividir el proyecto en varias fases.

Desarrollo de producto Lean

Ese plan siempre comienza con un MVP (Minimuml Viable Product) que si se puede hacer sin pintar pantallas y sin tirar código mejor.

Seguir leyendo «La intuición no aplica en Ontruck»

Design Thinking

Soy muy partidaria de que cuando diferentes personas participan en la creación de un producto o se centran en la solución de un problema es cuando aparecen las mejores ideas. Ya que es imposible que una sóla persona sepa toda la información hay que aprovechar el conocimiento de todos para crear algo diferente.

Para obtener un resultado creativo y novedoso, tiene que existir cierta cantidad de caos, pero es necesario empezar por un orden.

Pero en el día a día nos olvidamos de esto, y en vez de juntar los cerebros trabajamos de forma individual, desaprovechando esos increibles recursos que son las personas que tenemos a nuestro alrededor.

Design Thinking es un método para la resolución práctica y creativa de problemas.

Ayuda a facilitar el proceso de innovación permitiendo trabajar en grupo de forma dinámica, comunicativa y eficiente hablando el mismo idioma y sin tener en cuenta egos, ni posiciones jerárquicas e involucrando a todo el mundo de la misma forma.

Trabajando de forma dinámica y positiva

Gracias al poder de la escritura y el dibujo todo el mundo tiene oportunidad de aportar sus conocimientos de la misma forma. Logra evitar que siempre hablen los mismos, poniendo al mismo nivel todas las ideas e integrando el conocimiento de todos en el trabajo común.

Cuando alguien habla, solo esa persona tiene el poder en ese momento.

Si en vez de hablar, se escriben las ideas en dibujos o etiquetas, todo el mundo trabaja a la vez, construyendo algo de forma conjunta. Además se evita el bias del poder de la oratoria e influenciar en otras personas aunque sea una mala idea.

Al escribir la idea deja de ser de la persona pasando al grupo.

El hecho de dibujar o escribir dinamiza la actividad, ya que es más entretenido que estar escuchando a una persona. Y es que la capacidad de atención del ser humano es limitada, siendo cada vez menor.

Design Thinking

Workshop de Design Thinking usando Manual Thinking

Además al ordenar las etiquetas o post-its nos movemos, cambiando el equipo de forma constante de posición y postura, tanto de forma mental como física.

Seguir leyendo «Design Thinking»

CAS 2017 (Conferencia Agile Spain)

La semana pasada asistí como voluntaria a la CAS 2017, la Conferencia Agile Spain 2017, como se deonominan ellos, la mayor y más importante conferencia sobre agilismo en España.

Me hacía especial ilusión porque, aunque en Valencia he coordinado los meetups de UX Academy, y he asistido a un montón de eventos (pagando entrada), me apetecía mucho vivir por dentro, desde la parte de la organización, un acontecimiento de tal tamaño.

¿Y el resultado?

3 días de locura nonstop, recortando pegatinas, montando urnas, haciendo chapas, doblando camisetas, montando el welcome pack (750 mochilas con agendas, cuadernos, flyers, macetas, libros, spinners…), gestionando las salas, haciendo de guardarropa de abrigos, maletas y mochilas…

Todo ello rodeada de gente genial, y conociendo a muchas personas relacionadas con el sector.

Os dejo el vídeo resumen realizado por l@s super chic@s de Autentia:


¿Me ves en el vídeo? 😉

2 días completos, 4 tracks paralelas más 2 salas de talleres, y unas 750 personas entre ponentes, asistentes y organizadores. ¿Te apuntas al del año que viene? Yo si puedo si!

Eventos en Scrum II

Seguimos hablando de los eventos en Scrum. En el anterior post hablé sobre el Sprint y el Sprint Planning. A continuación seguiré con Daily, Sprint Review y Sprint Retrospective.

3. Daily Scrum

Es un evento que se celebra cada día, de duración de 15 minutos, en el que el Development Team sincroniza las actividades y crea un plan para las próximas 24 horas. Lo ideal es que se haga siempre a la misma hora y en el mismo lugar para que todo el mundo lo recuerde de forma fácil

La Daily Scrum sirve para inspeccionar el progreso hacia el Sprint Goal y cómo avanza el progreso. Para ello, se inspecciona el trabajo realizado en el último día y se comenta el trabajo que se va a realizar ese día.

¿Cómo se realiza?

Durante la reunión, los miembros del Equipo de Desarrollo explican:

  • ¿Qué hice ayer para ayudar al Developement Team a cumplir el Sprint Goal?
  • ¿Qué voy a hacer hoy para ayudar al Development Team a cumplir con el Sprint Goal?
  • ¿Veo algún impedimento que me impida a mí o al Developement Team a cumplir con el
    Sprint Goal?

La Daily Scrum es una reunión clave para inspeccionar y adaptar.

La Daily Scrum optimiza la probabilidad de que el Development Team cumpla con el Sprint Goal, cumpliendo las siguientes funciones:

  • Ayuda a que la comunicación sea más fluida entre los miembros del Team
  • Se identifiquen impedimentos y se proceda a realizar las acciones necesarias para su eliminación
  • Se detecten antes las desviaciones (si existen)
  • Mejora el nivel de conocimiento de los miembros del equipo de lo que sucede diariamente
  • Promueve la toma de decisiones de forma rápida

El Scrum Master se asegura de que el equipo de desarrollo tenga la reunión, pero es el Development Team el que es responsable de realizar la Daily.

Sprint Review

La Sprint Review (Revisión del Sprint) se lleva a cabo al final del Sprint con el objetivo de inspeccionar el incremento y adaptar el Product Backlog si es necesario. El Sprint Team y los stakeholders revisan lo que se ha hecho en el sprint y en función de eso y de cualquier cambio producido en el Product Backlog, se decide cuales son las siguientes acciones para optimizar el valor.

El objetivo es obtener retroalimentación y fomentar la colaboración.

Es una reunión de 4 horas de duración máxima para Sprint de un mes, asegurándose el Scrum Master de que tiene lugar y que los asistentes entiendan su propósito. Es el Product Owner el que inivita a los stakeholders que cree conveniente a participar.

Seguir leyendo «Eventos en Scrum II»

Scroll hacia arriba