© All rights reserved. 

Capítulo 1: UX y el rollito lean en una startup

A partir de un conjunto de posts, quiero hablar sobre mi experiencia en el mundo de una startup (Doctoralia) desde el punto de vista de un UX, trabajando en un entorno ágil, aplicando las técnicas de Scrum. No voy a soltaros una filosofía, creo que hay cracks en nuestro país que os pueden explicar mucho mejor que yo en que consiste todo esto.

Lo que empecé haciendo

Empecé a escuchar hablar de Scrum hace unos 6 años cuando trabajaba en la consultora everis. Teníamos un equipo UX de unas 15 personas en las oficinas de Barcelona. ¿Consultora? ¿Scrum? 🙂 puede ser gracioso pero un día colgamos en una pared post-its donde indicábamos los proyectos en el que estábamos trabajando cada uno de nosotros, con las típicas columnas de «to do», «in progress», «done». Hacíamos dailys cada mañana antes de empezar a trabajar. Pero realmente eso no era un Kanvan ni eso eran dailys. 

El Kanvan lo utilizábamos para ver la carga de trabajo de cada uno de nosotros para distribuirnos los proyectos. Las dailys solo eran para saber que hacían los otros. De poco servía todo eso si trabajábamos con el modelo waterfall… y la mayoría de veces no teníamos ni contacto con los developers o fronts.  (amigos de everis, de eso hace muchos años, seguro que ya no es así).

Lo que hago ahora

Estructura del equipo

Para que podáis entender la estructura de trabajo, voy a explicar por encima como trabajamos. La empresa está estructurada por mini-equipos. Cada equipo se encarga de una parte de la web o de un producto en concreto. Los equipos están formados por un PO (Product Owner), un UX y Developers que realizan tareas de de backend y frontend.

De forma transversal tenemos un equipo de componentes. Este equipo está formado por dos frontends (puros y duros) y dos diseñadores. Más adelante explicaré como trabajamos con el equipo de componentes. Finalmente un copywritter se encarga de tratar de la mejor forma los copys y las traducciones.

group-7

Esta estructura puede variar, dependiendo del número de personas, productos, KPI’s, etc. Personalmente me siento muy cómodo trabajando de esta forma. Anteriormente trabajé con una estructura de «equipos por roles», es decir, un equipo de UX, un equipo de DEV, otro de FRONT…. Cada equipo se va organizando las tareas según prioridades.

 

La forma de trabajar

Como era de esperar trabajamos con sprints. La duración puede variar un poco dependiendo de las tareas o proyectos con los que estamos trabajando, pero si no hay nada nuevo hacemos sprints de 2 semanas.

Los sprints se estructuran de la siguiente forma:

  • Sprint Planning: En esta sesión el PO lista todas las tareas que vamos a realizar en este sprint. Todas la tareas han estado consensuadas anteriormente en una reunión de PO’s, teniendo en cuenta los diferentes KPI’s de los equipos. En estas plannings se organizan las tareas a partir de todas aquellas personas involucradas. Otro día hablaré más en detalle de las plannings. Lo que voy adelantar es que desde el punto de vista de UX, nuestras tareas suelen estar en sprint -1, es decir, las tareas que tendrán que coger los DEV’s, Fronts o cualquier otro miembro, ya estarán trabajadas en el anterior sprint
  • Daily Sprint: Cada día los miembros del equipo se reúnen para comentar como van las tareas, a su vez solucionan dudas y mueven aquellas tareas, ya sea en «in progress», «QA», «Done»… .Aunque no se tenga que hacer, en las primeras dailys siempre es un buen momento decir si alguna cae o no de la planning… a su vez, si alguna crece o no. Lo se… no tendría que ser así pero puede pasar.
  • Demo: Llegó el gran día de la demo, ese día donde cada equipo muestra a otros equipos o compañeros, el trabajo realizado en ese Sprint. A su vez muestra la evolución de otros cambios ya realizados, así como el impacto de los mismos y los KPI’s.
  • Retrospective: Es el momento en el que todos los componentes del equipos nos podemos lanzar flores o tirar los platos por la cabeza. En las retros, se intentan sacar las cosas que han ido bien durante el Sprint, las que podrían ir mejor y  finalmente las que no han ido bien y por lo tanto tendremos que mejorar.

A continuación podéis ver un gráfico que explica de forma más visual la estructura y forma de trabajo.

 

scrum-agiletrick

 

Este es un breve resumen de como nos estructuramos  y como trabajamos en un entorno agile siguiendo el famoso «rollito lean». Realmente es una muy buena forma de trabajar, agilizando los procesos, la comunicación entre componentes del equipo, tener un control de los diferentes proyectos, así como su correcta gestión con otros equipos.

¿Tienes alguna experiencia o quieres explicar tu forma de trabajar?

Leave a comment:

Top