Product Owner

Roles en Scrum

A continuación voy a hablar de los roles que existen dentro del Scrum Team y que funciones y deberes tiene cada uno.

Scrum no tiene un rol llamado «Project Manager».

Scrum Team

Scrum Team

El Scrum Team se compone de 3 perfiles:

  1. Product Owner (1 persona)
  2. Development Team (Varias personas)
  3. Scrum Master (1 persona)

El Scrum Team debe ser auto-organizado y multifuncional. Lo primero para saber elegir cual es la mejor manera de hacer el trabajo, mejor que siendo dirigidos por otros externos. Multifuncionales porque el equipo debe tener las comptencias necesarias para realizar el trabajo sin depender de otras personas que no formen parte del equipo.

El equipo perfecto en Scrum está diseñado para optimizar flexibilidad, creatividad y productividad.

Es decir, debe ser capaz de poder entregar y publicar (si ha sido pasada a Done) esa nueva release lanzada.

No puede depender de otros equipos para subir a producción algo definido como «Done».

El equipo entrega productos cíclica e incrementalmenre, maximizando las oportunidades para obtener feedback. Entregas incrementales de productos con la etiqueta «Done» (Hecho) aseguran potenciales versiones usables del producto están siempre en activo.

Product Owner

El Product Owner , PO es el responsable de maximizar el valor del producto y el trabajo del Development Team (Equipo de desarrollo). Como se realiza esto, puede variar dependiendo de la empresa, los Scrum Teams y los inddividuos.

El Product Owner es la única persona responsable para gestionar el Product Backlog.

Entre las tareas que se realizan en esa gestión se encuentran:

  • Nombrar claramente los ítems del Product Backlog.
  • Ordenar los items en el Product Backlog priorizándolos para lograr los mejores objetivos y resultados.
  • Optimizar el valor del trabajo que realiza el Development Team.
  • Asegurarse de que el  Product Backlog sea visible, transparente y claro para todos, y que muestra en que va a trabajar el Scrum Team.
  • Asegurarse de que el Development Team comprende perfectamente los elementos del Product Backlog.

El PO puede hacer el trabajo anterior o hacer que lo haga el equipo de desarrollo, pero en ambos casos será el Product Owner responsable.

Seguir leyendo «Roles en Scrum»

Aprendiendo Scrum

Scrum es un framework (marco de trabajo) dentro del cual las personas pueden abordar problemas complejos, a la vez que ofrecen productos de manera eficiente y creativa del más alto valor posible.

Scrum

Web de scrum.org

Scrum proviene del trabajo de Ikujiro Nonaka e Hirotaka Takeuchi cuando publicaron «The New New Product Development Game» en Harvard Business Review (HBR) en 1986.

Su forma final proviene de “Scrum Development Process” presentado por Ken Schwaber en OOPSLA 95. Tanto Ken Schwaber como Jeff Sutherland son considerados sus creadores oficiales.

Aunque para Takeuchi y Nonaka, Scrum está relacionado indirectamente con el software. Tiene que tiene más que ver con el liderazgo y el funcionamiento de las principales compañías del mundo, tal y como aparece su artículo en HBR llamado «The Big Idea: The Wise Leader».

En sí mismo, no es un proceso o una técnica, sino que como marco de trabajo, para desarrollar complejos productos de software, pudiendose emplear varias procesos y técnicas. Presenta varios componentes, roles, eventos, artefactos y reglas, que tienen un propósito muy claro y son esenciales para el éxito de Scrum.

Sirve especialmente para ver de forma clara la eficacia relativa de las prácticas de desarrollo y gestión de producto para que se pueda mejorar.

Si de verdad se quiere lograr un cambio en la forma de trabajar, éste debe contar con el apoyo de «los de arriba».

Los stakeholders deben respaldar al Product Owner con conocimientos e información de los productos o servicios a desarrollar y apoyar al Scrum Master para provocar un cambio organizacional que fomente el empirismo, la autoorganización, la inteligencia y el poder decidir de forma inteligente cuando el producto está listo para ser lanzado.

Los 3 pilares de Scrum

Dentro de los principios Agile, vivimos en un mundo de constante cambio e incertidumbre por lo que es imposible predecir a futuro cual va a ser la siguiente innovación.

Scrum se basa en la teoría empírica de control de procesos. El empirismo afirma que el conocimiento proviene de la experiencia y toma decisiones basadas en lo que se conoce.

Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad del mundo en el que vivimos y controlar el riesgo.

Tres pilares sostienen la implementación del control del proceso empírico:

Seguir leyendo «Aprendiendo Scrum»

Mejorando la experiencia de usuario gracias a Soporte (II)

Seguimos con el resumen de la genial charla de Inés Luna (@cuquiesp) en la Tarugoconf 2016 sobre lo aprendido al montar un equipo de soporte desde cero en una startup. (Leer antes la primera parte)

2º Fase: Escala o muere

Vas creciendo y tienes un volumen de clientes más grandes, es un caos contestarles por email, has tenido problemas con los equipos porque no sabes que hacer cuando alguien reporta un bug, los bugs no se arreglan…

Luna comenta que cuando el equipo crece busca personas que no necesariamnete tengan experiencia en soporte, sino que sean grandes comunicadores y que tengan una gran capacidad empática con los clientes, pero que tengan «huevos grandes» para tomar decisiones porque muchas veces hay que decirles que no a los clientes, pelerse con ventas que han mentido a los clientes, con producto…

Inés nos cuenta que la clave es formar un equipo fuerte y solidario. No solamente personas alineadas con la cultura de la organización sino q esten alineadas con el resto del equipo para crear un equipo muy unido ya que atención al cliente puede ser muy ingrato. ¿Cómo?:

  • Hacerles participe en el proceso de nuevas incorporaciones
  • Que el equipo cree documentos de onboarding para ayudar a los nuevos miembros
  • Poner un mentor a la persona nueva para ayudarle y que aprendan entre ellos

Segmentar a los usuarios

Cuando creces y tienes muchos clientes, seguramente ya has cabredo a más de uno (y parece que se acabe el mundo! Pero no). Si, como en su caso, eres un producto freemium, tienes que empezar a tomar decisiones,y segmentar a tus usuarios, ya que no es el mismo soporte el que le das a una persona que no paga, a una que paga poquito o a una que paga mucho.

Tienes que empezar a segmentar a los usuarios y empezar a entender:

  • Cómo de rápido puedes contestar a la gente
  • Qué tipo de incidencias equieren atención urgente
  • Cual es el canal más adecuado para cada segmento, no es lo mismo una gran corporación que tiene el pooducto instalado a medida, que una persona que lo usa gratis una vez al mes…

Zendesk

Es el momento de empezar a pensar a usar una herramienta de Customer Service profesional como ZenDesk y empezar a trabajar en los procesos, como las automatizaciones, el workflow de los tickets… ya que vas a ser mucho más eficiente en lo que haces.

Gestión de indidencias

Tambien en esta etapa debes empezar a coordinarte mucho más con el resto de los equipos, como en el caso de las incidencias técnicas o bugs, trabajando con QA, desarrollo, producto… para definir que algo es una incidencia versus que el cliente no entiende cómo usar el producto, como reproducir esa incidencia, acordar entre todos cual es el criterio para poner una prioridad, quien es el responsable de asignar esa prioridad, si esa prioridad puede variar en función del número de tickets que dispongas…

Sino hay un acuerdo entre todos, el proceso puede ser muy doloroso.

Medición y analítica

Implementas procesos con ventas, con facturción…. y ya usas una herramienta específica para atención al cliente y tienes q empezar a medir lo que estás haciendo. Y con herramientas como Zendesk puedes hacer reporting de cualquier cosa. Inés nos recomienda que nos centremos en cosas básicas en su caso por ejemplo, en el tiempo que tardaban en atender a un cliente.

Se dieron cuenta de que atendían antes a los usuarios que no pagaban, ya que preguntaban cosas más sencillas, haciendo esperar más tiempo a los que pagaban por la herramienta.

Darse cuenta de eso hizo que tuvieran que reorganizar el workflow para poner la prioridad en los clientes que más aportan.

El tiempo de resolución de un ticket es otra historia, porque si tienes incidencias que tienes que escalar a otro equipo ya no depende de tu trabajo, y ver cual es el proceso para escalar, cuanto tardan en resolverlas, cada cuanto haces una release, cada cuanto se arreglan los bugs, la proporción de tiempo entre trabajar en roadmap y hacer la plataforma más estable y arreglar bugs… Esas métricas ya no depende sólo de ti.

Satisfacción de tus usuarios

Para conocer si los usuarios estaban contentos, Inés comenta que ella implementó 2 tipos de métricas, una más transaccional que es en base a las interacciones con el equipo de soporte y la otra para conocer la satisfacción general, el NPS.

En la primera mandaba un email después de resolverles la incidencia con una encuesta, donde les preguntaba si están satisfechos o no. Descubrieron que vivían estresados con los tickets pero los usuarios estaban en un 95% sastisfechos con el servicio que tenían en soporte.

Lo segundo que implementaron fue el NPS (Net Promote Score) que no es una métrica de soporte sino que es mucha más amplia, usada en marketing, producto… que consiste en hacerles la pregunta de ¿Cómo de problable es que recomiendes este producto a un compañero de trabajo o un amigo?

Descubrieron que si bien en soporte estaban contentos, había un descontento generalizado de los clientes que no tenía que ver con soporte sino que tenía que ver con funcionalidades que habían quitado en el producto, sobre el proceso de ventas y facturación que era muy engorroso y muy lento para muchos clientes pagar, con el reposicionamiento del producto, de gestiñon de proyectos en comunicación en tiempo real que la gente no entendía porque habíaan hecho ese cambio.

Son métricas muy diferentes que te dan 2 visiones para ver como de contentos están tus usuarios.

Etapa: Todo explota

En 2014 hacen un rebranding y lanzan una visión nueva del producto. Era simplemente un lavado de cara visual, pero a los usuarios no les gustan los cambios. Y eso hace que el equipo de soporte reciba miles de llamadas contestando siempre lo mismo.

¿Qué haces cuando tus clientes no están contentos de ese cambio?

Seguir leyendo «Mejorando la experiencia de usuario gracias a Soporte (II)»

Principios Lean UX para guiar el proceso

Una vez que hemos hablado qué cultura y organización debe existir en la empresa y los equipos, vamos a ver cómo deben trabajar.

Trabaja en bloques pequeños para reducir el riesgo

Otro principio fundamental heredado de Lean Manufacturing es la práctica de dividir el trabajo en pequeñas unidades, en su caso con el objetivo de reducir el inventario y obtener la máxima calidad.

Trasladado a Lean UX significa que sólo la cantidad de trabajo necesario se realizará para poder avanzar hacia delante, validando la hipótesis y continuando el desarrollo en base a lo aprendido. Con ello contribuimos a otro de los principios, el de reducir el desperdicio.

Descubrimiento continuo

Para realizar este proceso debemos involucrar al usuario o cliente en el proceso durante la fase de diseño y desarrollo de las ideas.

Muchas veces (en el caso de que se haga) este contacto, en vez de hacerse de forma regular se realiza al final, con el trabajo ya desarrollado. Por ello se deben definir encuentros seguidos mediante métodos cuantitativos o cualitativos que permitan obtener el feedback para la validación.

Descubrimiento continuo

El objetivo es claro: entender que hacen los usuarios con tus productos y por qué lo están haciendo.

Por ello la investigación debe hacerse de forma regular y con todo el equipo implicado.

Este segundo punto (con todo el equipo implicado) es muy importante ya que normalmente sólo los UX Research hacen esta parte teniendo posteriormente que explicar los resultados al resto del equipo.

Al introducir a todo el equipo en la investigación consigues 3 cosas:

  1. Que desarrollen una mayor empatía por el usuario y sus problemas
  2. Entendimiento compartido de lo que ocurre y por que luego se van a tomar ciertas decisiones.
  3. Reducción de la necesidad de generar documentación que explique los descubrimientos de la investigación

GOOB (Getting out of the building)

Con esta expresión que significa literalmente “salir fuera del edificio”, Steve Blank, profesor de Stanford, quiere conseguir que los equipos salgan fuera de las salas de reuniones con sus interminables divagaciones y suposiciones, y que den a los potenciales usuarios la oportunidad de proveer feedback real tan pronto como sea posible.

Gracias a esta dosis de realidad verás que ideas no funcionan antes de malgastar más recursos en ellas.

Exponer el trabajo

Con este principio, se quiere que las ideas salgan de la cabeza o de las pantallas de las personas y se pongan a la vista de todo el equipo. Esto permite ver el estado del trabajo, creando un flujo de información compartida, de nuevas ideas y sugerencias que surgen en base a lo visto…

Seguir leyendo «Principios Lean UX para guiar el proceso»

Lean UX

Lean UX es un libro escrito por Jeff Gothelf y Josh Seiden donde explican unos principios, unos procesos y un método de gestión basados en el Diseño Centrado en Usuarios (DCU), el Design Thinking y las metodologías de desarrollo ágil de software aplicables en el diseño de experiencia de usuario.

Lean UX

En que se basa Lean UX

Lean UX es la combinación de varias escuelas de pensamiento. Entendiendo de donde viene, ayuda a aplicar y entender como funciona Lean UX:

User Experience Design

Lean UX es en manera de practicar diseño de experiencia de usuario. Psicología, antropología, ergonomía, diseño…  junto con las ideas surgidas en la década de los 50 sobre Human Centered Design (HCD o en sus siglas en españal, DCU, Diseño Centrado en el Usuario)… todo ello hoy se agrupa hoy bajo las siglas User Experience Design o UX, término que se acredita a Don Norman, y se basa en identificar las necesidades de los usuarios.

Design Thinking

En los pasados años hemos visto el aumento de popularidad de este término. Creado entre los años 70-80, fue la firma IDEO quien lo popularizó a principios de los 2000 como forma de aplicar métodos de diseño centrados en el usuario a diferentes problemas.

Si te interesa aquí puedes leer el artículo sobre Design Thinking publicado en la Harvard Business Review en 2008 por Tim Brown.

Agile Software Developement

Los desarrolladores han estado empleando métodos agile para reducir sus ciclos de desarrollo, construyendo en base a un aprendizaje contínuo y entregando valor al cliente de forma contínua. En este artículo te cuento más sobre los 4 principios agile.

Lean Startup

Eric Ries publica en su libro Lean Startup un método que usa el feedback contínuo  (build-measure-learn) para minimizar los riesgos de un proyecto consiguiendo equipos que aprendan y construyan de forma rápida.

Los equipos deben construir en cada iteración el Mínimo Producto Viable (llamado MVP, Minimum Viable Product por su acrónimo en inglés) y probarlo rápidamente para aprender lo antes posible si van por el camino correcto y satisfacen las necesidades del usuario.

La idea es crear de la forma más rápida un prototipo con el cual poder testear en el mercado las suposiciones iniciales y gracias al feedback del cliente evolucionar el producto de forma mucho más rápida, en la dirección adecuada y con el mínimo desperdicio de recursos que usando métodos de desarrollo tradicionales.

En resumen, ¿qué es Lean UX?

Es la práctica de conseguir el producto adecuado de la mejor forma posible, mediante una forma colaborativa y multifuncional, trabajando para construir un entendimiento compartido del cliente, sus necesiades, las soluciones propuestas y la definición de éxito y priorizando aprendizaje sobre entrega tomando decisiones sobre pruebas reales.

Sigue leyendo y conoce los principios en los que se basa Lean UX.

Artículos sobre Lean UX

Trabajando como Product Owner

Recientemente he trabajado como Product Owner, (PO) y me gustaría dejar constancia de como se estaba realizando esa tarea, ya que me parece un approach muy bueno para el desarrollo de un producto.

En este caso la empresa tenía un equipo de Producto que eran los que efectuaban el desarrollo del producto (research, entrevistas con usuarios, Design Sprints…) y cuyos stakeholders trasladaban las insights y nuevas necesidades de los usuarios al Storiesonboard.

Era mi misión dividir esas nuevas ideas en formato de User Story juntándolas en Releases, en base al valor aportado (marcado por los OKRs) al backlog en JIRA.

A continuación muestro una imagen del ciclo de desarrollo de US que empleábamos:

Produc Owner Cycle

Este ciclo no tenía porque hacerse completo. Si mientras ha estado en el backlog, se habían descubierto nuevas ideas, la User Story volvía al descubrimiento y al StoryMap. La cuestión era:

Minimizar la cantidad de trabajo no realizado.

Empleábamos:

  • Artefactos: Storiesonboard, JIRA, Trello y Slack.
  • Ceremonias (siempre con timing): Daily por squad y grupal (diaria, 15´), Syncro (una cada 2 semanas, 30-45´), Retros (cada 3-4 semanas, 60´) y Asamblea (cada 2 meses, 2h).

Story mapping

Para realizar storymapping usabamos Storiesonboard.com, un software (de pago) que actúa como una panel donde puedes ir distribuyendo las User Stories (US en adelante) en releases y features, y que permite organizar el crecimiento atómico del producto.

Story mapping

En los cuadrados azules, estaban los OKR de la compañía, en los amarillos las MMFs (siglas de Minimum Markatable Feature, característica mínima comercializable) necesarias para alcanzar esos OKR, descritas como adjetivos. Por último, en blanco, debajo de la columna de cada feature, las US necesarias para alcanzarlas. A la izquierda, en letra azul, se marca en que Release o MVP (Minimum Viable Product, Producto mínimo viable) están esas US.

Lógicamente las MMF que tenían más valor estaban más a la izquierda, así como las US con más valor estaban más arriba. Para organizarlo es necesario que el PO disponga de conocimientos y experiencia en aspectos de negocio.

El JIRA estaba dividido en 3 paneles, uno para cada tipo de usuario que trabajaba con él, enlazando así el trabajo del equipo de desarrollo a los objetivos de negocio, muy importante para conocer el estado de una feature y seguir su trazabilidad.

MMF Board

El primer panel, es el MMF Board que posee 3 columnas «To Do, In progress y Done». Puede haber varias MMF por release, enlazadas entre ellas por una etiqueta de JIRA que indica el nombre de la release.

Seguir leyendo «Trabajando como Product Owner»

Agile software development

En un mundo de constante cambio e incertidumbre, es imposible predecir a futuro cual va a ser la siguiente innovación. Por ello desde hace años los desarrolladores han estado usando métodos Agile para reducir sus ciclos de desarrollo, basándose en un aprendizaje contínuo y entregar valor al cliente de forma regular.

Agile Manifesto

Imagen de la web de http://agilemanifesto.org/

Fue popularizado por el Agile Manifesto, que define sus valores y principios, habiéndo evolucionado en diferentes métodos de desarrollo, siendo dos de los más utilizados Scrum y Kanban.

En referencia a la experiencia de usuario, te recomiendo que te leas Lean UX, un libro que relaciona el Diseño Centrado en Usuarios (DCU), el Design Thinking y las metodologías de desarrollo ágil de software para desarrollar productos y servicios con la mejor experiencia de usuario.

El Agile Manifesto define 4 principios y 12 valores. Descubrirlos para mi, fue una revelación, el ver puesto en palabras lo que, en mi experiencia, era la base de todo buen desarrollo.

Los 4 principios Agile

  1. Individuos e interacciones sobre procesos y herramientas
  2. Software funcionando sobre documentación extensiva
  3. Colaboración con el cliente sobre negociación contractual
  4. Respuesta ante el cambio sobre seguir un plan

El diferente tamaño de letra se debe a que aunque se valoren los elementos de la derecha, se priorizan más importantes los de la izquierda.

Individuos e interacciones sobre procesos y herramientas

Es más importante el conocimiento de las personas y el valor que puede surgir del conocimiento conjunto que los entregables o los procesos rígidos. La libertad de compartir ideas y realizar aprendizaje y descubrimiento entre todos los miembros del equipo crea un ambiente de innovación lo que conlleva a conseguir mejores soluciones, a la par que un sentimiento de responsabilidad sobre lo creado.

Seguir leyendo «Agile software development»

Product Owning en Flywire

Al dejar Capgemini me surgió la oportunidad de colaborar durante 3 meses como externa en Flywire, una conocida empresa valenciana por su gran equipo de desarrollo.

Flywire

El trabajo en sí consistía en ser Product Owner de uno de sus squads, dentro de la nueva metodología de trabajo que les estaba ayudando a implantar @XaV1uzz, ya que han crecido muy rápidamente, y como sucede en muchas empresas cuando este caso ocurre, el proceso de ajuste y evolución es complejo. No es lo mismo pasar de gestionar 6 personas a 150 en 5 años.

Si acepte el reto (al día siguiente de finalizar en Capgemini) fue porque conocía la empresa gracias a que esponsorizaban los UXAcademy y a gente que trabajaba dentro de ella.

Además creo en los principios Agile y era una manera de aprender como lo estaban aplicando (había estado en otras empresas que se denominan «Agile» y quería ver otro ejemplo), con el añadido extra de que la mitad de la empresa está en Estados Unidos por lo que toda la comunicación es en inglés.

Seguir leyendo «Product Owning en Flywire»

Scroll hacia arriba