Product Manager

Equipos de alto rendimiento

Continuamos con el resumen de la charla de Israel Alcazar (@ialcazar) en la CAS 2017 sobre cómo llegar a ser un equipo de alto rendimiento. En el post anterior hemos analizado qué características debe tener un equipo para no ser solo un grupo de trabajo y que tipos de equipos existen en base a la matriz de autoridad.

¿Qué es un equipo de alto rendimiento?

Hay muchas definiciones sobre qué es un equipo de alto rendimiento.

El concepto de alto rendimiento no es un estado, en un proceso.

Puede que no se llegue nunca ahi, pero el camino hasta conseguirlo es lo que realmente importa.

Caracteristicas de los equipos de alto-rendimiento

Lo que importa es ir evolucionando, hasta conseguir cubrir en cierto modo lo que se puede considerar un equipo de alto rendimiento, que cumple los 2 siguientes puntos:

  1. Es capaz de entregar resultados excelentes, que sean eficientes, es decir, de la mejor manera posible utilizando los menos recursos posibles y eficaces, cumpliendo el objetivo.

2. La constitución, que los miembros tenga una elevada satisfacción y motivación.

Para Israel esto segundo es básico porque si sólo te centras en los resultados y no en las personas, las interacciones entre ellas, no estas enfocado en saber si es de alto rendimiento.

Y, ¿cuándo soy un equipo de alto-rendimiento? ¿en qué tareas soy de alto-rendimiento? Porque se puede ser en algunas y en otras no, por eso Alcázar lo ve como un proceso y no un estado. Es imposible estar siempre cumpliendo todo. Si se busca eso solo genera frustración.

¿Qué se necesita para generar equipos de alto rendimiento?

  1. Objetivos claros: Misión y visión clara. Aunque estamos en un mundo incierto deben estar más o menos este establecidas aunque luego se cambien. Alcazar comenta la aproximación de Google de los OKRs, una forma de trabajar que obliga a pensar en objetivos y en como medirlos. Pero para eso se debe definir perfectamente la visión y misión del equipo a grandes rasgos.
  2. Entorno y contexto seguro: todos los miembros del equipo deben ser capaces de sentirse vulnerables. Que se pueda dar feedback o decir que no se sabe hacer algo sin que pase nada.
  3. Co-responsabilidad: responsabilidad compartida de los resultados. Esto muchas veces no se tiene.
  4. Definir bien las reglas del juego: definir los límites de trabajo porque sino se hace de forma explícita se definirán de forma implícita y eso puede que lleve a expectativas que no son reales y se genere fricción y cierto roce. Los límites en los que un equipo puede decidir, que nivel de autoridad, cuales son sus límites para realizar esa tarea, sus canales de interlocución…

En el libro de Patrick Lencioni, de “Las 5 disfunciones de un equipo”, se habla de la cohesión y las 5 cosas que se encuentran en los equipos que hacen que no se cree esta cohesión.

5 disfunciones de un equipo

Alcazar comenta que no hay que ver esta pirámide como algo secuencia, un equipo puede tener 1 o 2, o estar en el 3, ir variando…

Seguir leyendo «Equipos de alto rendimiento»

Tipos de equipos

Israel Alcazar (@ialcazar), da una charla en la CAS 2017 titulada «Trabajando entre equipos de alto rendimiento«. Pero antes de comenzar debemos dejar claro que características debe tener un conjunto de personas para denominarse equipo.

¿Qué es un equipo?

Alcazar empieza la charla comentando la diferencia entre equipo y grupo de trabajo, ya que mucha gente se llama equipo cuando no lo es, proponiendo la siguiente definición.

Definicion de equipo

Un equipo es un conjunto de individuos que son interdependientes en sus tareas, y que comparten responsabilidades en sus resultados y que operan dentro de los límites de una organización.

Y es que sino existe interdependencia por mucho que los miembros se sienten al lado, sino se comparten responsabilidades seguramente no se esté trabajando en un equipo.

Nos pone un ejemplo grupo de trabajo: un grupo de estudio donde se hablan de temas, se debate pero no tenemos tareas interdependientes ni responsabilidad.

Y es que antes de pensar en equipos de alto rendimiento, hay que preguntarse: ¿somos un equipo?

Alcazar comenta otra definición, en este caso de Imanol Ibarrondo (@energizol):

Definición de equipo

Donde se introduce el término confianza (red de relaciones de confianza y de alta calidad), de personas diversas (multi-disciplinaridad) y co-responsables (vuelve a aparecer el concepto de responsabilidad) a la que añade que opera dentro de los límites de una organización, ya que le parece interesante establecer límites.

Con lo cual la primera agrupación que se puede encontrar en las empresas es ser un grupo de trabajo. Si se cumplen los requisitos que se acaban de nombrar se puede pasar a ser un equipo. Y es que ya en muchos casos no se llega a eso, habiendo que trabajar el ser un equipo, a trabajar en la corresponsabilidad, el hecho de compartir…

Una vez que se tiene el equipo montado,  ¿qué suele pasar?

Normalmente existe una persona llamada jefe, líder, manager… que marca los criterios de lo que el equipo debe hacer y también suele marcar los comos, es decir, cómo el equipo debe realizar ese trabajo.

Tipos de equipos

Pero el propio equipo podría decidir sobre el cómo hacer las cosas y no sólo el manager quien decide cómo trabajar. Eso en agilidad se llama equipos auto-organizados.

Es decir, es un nivel superior en cuanto a la autonomía y la autoridad del equipo.

Y el manifiesto agile se queda un poco por aquí, pero existen niveles superiores de equipos.

Seguir leyendo «Tipos de equipos»

Customer Experience y Agile

Una de las charlas que no pude ver en la CAS2017 (por estar coordinando otra de las salas) y que más me ha gustado al verla, fue la titulada: «No hay mejora de Customer Experience sin Agile» de Carlos Iglesias (@CarlosTheSailor)

El secreto es que esta relación no es unidireccional y el concepto más podereoso que espera aportar, es que Customer eXperience (CX) es una palanca para permitirnos introducir la cultura agile en las organizaciones.

Ejemplo Customer Journey Map

Para que explicar la diferencia entre User Experience (UX) y CX, Carlos nos empieza realizando un customer jorney de la típica experiencia de una boda, sacando las risas del público, lo cual ya les deja con ganas de saber más.

Definición Experiencia

Posteriormente pasa a comentar la definición de Experiencia de la RAE, destacando varios aspectos:

  • El tema de sentir
  • La práctica en el tiempo, prologanda
  • Vivido por 1 persona

Y esto último lo remarca, el tema de vivido por una persona, por un individuo. Porque pasa a explicar el mismo proceso de la experiencia de una boda, pero de SU boda.

Customer Journey Map boda Carlos

Pasa a comentar un tweet de Isidro López (@islomar) leyendo un libro de Foster Wallace «This is water»:

«La misma experiencia puede significar dos cosas totalmente diferentes para dos personas diferentes, dados dos tipos diferentes de creencias y dos maneras diferentes de construir significado desde la experiencia.»

¿Qué quiere decir esto?

No tenemos un cliente, sino muchos.

Tenemos que identificar cuales son nuestros arquetipos de clientes y trabajar de forma separada cada uno, entendiendo su journey, su experiencia completa.

Customer Jorney Map

Esto se hace con un Customer Jorney Map, poniéndo Carlos el ejemplo de uno simplificado en 5 pasos: Descubrimiento (Awareness), Consideración, Compra, Servicio y Post-compra.

Customer Journey Map

En el se identifica una serie de momentos por los que pasa el cliente,  mapeando la experienca en cuanto recuerdos positivos y negativos.

Seguir leyendo «Customer Experience y Agile»

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!

Conferencia Agile Spain

Este año voy a asistir a la CAS 2017 en Sevilla como voluntaria.

Me apatece un montón porque aunque he ido a muchos eventos nunca he participado con ese rol, y ahora que dispongo de tiempo me parece una forma genial de aprender y conocer a gente.

CAS 2017

Para los que no lo sepan la Conferencia Agile Spain (@confagilespain) es un evento que se celebra cada año en una ciudad diferente, generado por personas que viven el desarrollo de software de una manera diferente.

Profesionales del sector comparten conocimientos y experiencias en torno a las metodologías ágiles y como personalmente creo en ellas para desarrollar productos y servicios, es una oportunidad única de compartir conocimientos con empresas y personas de España que piensan igual.

¡Nos vemos allí el 7!

Y el sábado a primera hora a coger el AVE directa a Zaragoza a la Women TechMakers! Moriré de cansancio???? Nooo, I can!!!

Requerimientos de un proyecto

Ya sea cuando estaba trabajando para clientes pequeños, a nivel interno de una empresa, o para grandes clientes externos dentro de una consultora, me ha tocado en muchas ocasiones estar con los stakeholders (interesados)de un proyecto, definiendo sus requerimientos. Es decir, la lista de funciones, capacidades o características necesarias que debe tener y los planes para crearlos.

Stakeholders en un proyecto

Según la definición del PMBOK® (Project Management Body of Knoledgement), un requerimiento es la condición o capacidad que debe tener un sistema, producto, servicio o componente para satisfacer un contrato, estándar, especificación, u otros documentos formalmente establecido.

Se deben definir en la fase inicial junto con los stakeholders  implicados para obtener una visión completa y compartida de todas las piezas y poder priorizar en base a los objetivos del proyecto.

Los requerimientos no te indican que diseño debe tener tu producto o como desarrollarlo. Te indican que features, funciones y contenidos se espera que tenga, y como deben los usuarios interactuar con él.

Los requerimientos pueden incluso variar con el tiempo, ya que si el proyecto se desarrolla correctamente, en cuanto el MVP se haya desarrollado y se realicen pruebas con usuarios, los resultados pueden cambiar los requisito iniciales.

Tipos de requerimientos

Existen diferentes tipos de requisitos, casi tantos como implicados haya en un proyecto 😉 En un macronivel obtenemos los siguientes:

Requerimientos de negocio

Definen los objetivos y problemas que la empresa quiere resolver con el producto. Deben estar basados en una necesidad real del usuario, sea esta conocida o no por él.

Requerimientos de los usuarios

Describen las expectaciones de los usuarios y como éste interactuará con el producto. Sino son similares a los requerimientos de negocio, el proyecto irá mal encaminado.

Las técnicas de personas, escenarios y customer journeys sirven de ayuda para definir las funciones, tareas y características que definen los requisitos de usuario.

Requerimientos funcionales

Proporcionan detalle de como debe comportarse un producto y especifican lo que se necesita para su desarrollo.

Requerimientos de calidad

Detallan las características que un producto debe poseer para mantener su efectividad y prever posibles problemas y limitaciones.

En términos de experiencia de usuario, si la calidad del producto no concuerda con las expectativas que el usuario posee sobre él, no funcionará.

Requerimientos de implementación

Se usan para detallar cambios en los procesos, roles en el equipo, migraciones de un sistema a otro…

Escribiendo requerimientos

Para definirlos se recomienda usar una sentencia descriptiva que indique qué debe hacer el sitio o producto o debe permitir hacer a los usuarios, detallándola más adelante al ir avanzando en el proceso e ir obteniendo feedback de los test iniciales.

Seguir leyendo «Requerimientos de un proyecto»

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»

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»

Inteligencia colectiva, aprovechar el talento grupal

Esta tarde en el ITAINNOVA he asistido a un talle llamado Inteligencia colectiva: ¿Cómo aprovechar mejor el talento grupal de equipos y colectivos?

Y es que en una empresa puedes juntar a personas con mucho potencial, pero sino sabes gestionar su trabajo en grupo no logras nada.

Por ello, en el taller hemos tratado qué factores explican el éxito de un equipo y cuales son los avances de investigación más relevantes y prácticos en el campo de la Inteligencia Colectiva.

Dirigir personas

Internet y todo su potencial sirve para hacer a los grupos más inteligentes, pero aunque colaborar y el co-working está en boca de todos, cuanto más nos sumergimos en el proceso, más nos damos cuenta de su dificultad.

El resultado grupal de la Inteligencia Colectiva no depende significativamente de juntar personas con un alto coeficiente de inteligencia individual, sino de propiciar un tipo de interacción entre ellas que ayude a conseguir resultados extraordinarios.

Seguir leyendo «Inteligencia colectiva, aprovechar el talento grupal»

Scroll hacia arriba