Cualquier crecimiento es una transformación

Uno de los espacios que más me gustó del SOS Zaragoza 2019 fue la que salió de la suma de 2 propuestas de @guilleciencia y Jorge Viarte, con los títulos «Doblar el tamaño sin morir en el intento» y «Postmortem Terminator». Dejando de lado que eran bastante marketinianas y llamaban la atención, la propuesta se basaba en cómo anticiparse a todo lo que puede ocurrir cuando el equipo se escala y así estar preparado para que no ocurra.

Cultura y organizacion

Aunque lo ocurrido en cada caso era distinto, había algo similar. La empresa por fin tenía dinero y podía ampliar el equipo. En una de las compañías, había sido un crecimiento en todas las áreas (almacen, marketing, desarrollo…) y en la otra era más la parte técnica.

Estas decisiones van ligadas al momento financiero de la empresa.

Lo ideal es que el crecimiento sea gradual, pero en muchas ocasiones eso no es así. Ya sea porque el mercado lo impone (por ejemplo, entra un nuevo proyecto), o por tema económico, muchas empresas tienen a gente absorbiendo esa carga extra de trabajo hasta que pueden permitirse crecer. A veces la tecnología permite que un equipo bueno pequeño absorba un crecimiento de 100 a 2000, pero llega un momento en que si la empresa quiere crecer no basta con ello.

Pueden darse muchos casos distintos. En ocasiones la empresa conoce ya a gente que ha trabajado con el equipo o que trabaja de forma continua, y los absorbe. En ese caso, el proceso es mucho más suave, ya que no hay sorpresas en cuanto a su conocimiento, a su «seniority» ya que se lleva tiempo colaborando de forma conjunta. También es más fácil que conozca más sobre la empresa, los roles de los que ya están dentro, el negocio y producto que desarrollan y lo que se espera de ellos.

Otras veces las personas que se contratan no tienen el nivel esperado, o una falta de conocimiento de hasta dónde llega la responsabilidad de cada uno. Esto puede hacer que no se reparta bien el pastel y que algunos acaben asumiendo más trabajo de lo que les toca, quemándose a la larga. Para solucionar esto, entre los asistentes comentaban que una posible idea era realizar un delegation board.

Otro de los asistentes, con uno de sus comentarios (como muchas veces agudos y certeros9 sugirió que la situación del mercado actual de recruiting la hemos generado nosotros por lo que también tenemos que arreglarla. Sino encuentras seniors, contrata lo que encuentres y gasta el presupuesto en hacerles seniors.

Sigue leyendo

¿El backlog cuesta dinero?

Mantener inventario cuesta dinero. Ya sean sacos de plástico apilados al lado de la máquina para ser inyectado, tomates en una nevera de un restaurante, o pantalones en un camión esperando su transporte, es dinero almacenado. Además existe la posibilidad de que si hay una inundación, entran bichos, o simplemente se pasa de moda, pierde su valor.

Lo más fácil sería que no fuera necesario mantener ese material almacenado, pero claro eso tiene otros costes asociados. No te puedes quedar fuera del negocio por no tener ruedas para fabricar más coches o cerveza para servir un día caluroso. De ahi el Sistema de producción Toyota, precursor del «Lean manufacturing» o la Teoría de las restricciones o limitaciones (Theory of Constraints, TOC).

Pero, ¿esto también sucede cuando hablamos del desarrollo de un producto digital?

Pues si, que no sea un producto físico y tangible, no significa que no tenga grandes costes asociados.

En cada una de las etapas por las que pasa el código antes de llegar al consumidor final, es «producto almacenado». Desde la User Story definida por el product owner, hasta el tiempo que un tester se pone a probar el código desarrollado, es material almacenado.

El coste del inventario de código es enorme.

En algunos casos pueden tardar meses en llegar a las manos del consumidor final. Esto puede ser la diferencia entre sacar al mercado un producto novedoso o estar constantemente copiando a los más vendidos. Y es que ser el primero muchas veces marca la diferencia en un mercado donde los consumidores están constantemente pensando en la siguiente novedad.

Y dado que los recursos que normalmente se disponen en las empresas son escasos, es muy importante focalizar y no perder tiempo en escribir algo que no va a ser utilizado o salir a producción.

Backlogs

Durante el desarrollo de un producto digital pueden surgir muchas ideas de funcionalidades que jamás llegan a ver la luz. Tal cual vienen, ya sea en una sesión de grooming o porque un cliente o alguien de la empresa hizo una sugerencia, se escriben y se almacenan en un backlog.

El problema es que el 90% de las cosas que están en el backlog nunca se implementarán. NUNCA.

Por ello cada minuto que se gasta escribiéndolas, detallándolas, diseñándolas o discutiéndolas es tiempo desperdiciado.

La mente es compleja, y como describe la metodología GTD® (Getting Things Done® de David Allen) es mejor poner algo por escrito y dejar de pensar en ello, que no tenerlo rondando por la cabeza y estar inquieto. Pero debe almacenarse en el lugar correcto y de la forma correcta. A lo mejor una línea de texto en la herramienta que uses de forma personal como PO bastará para almacenar esas ideas que jamás se programarán.

Sigue leyendo

Nuevo diseño de formularios

Este invierno hemos cambiado el diseño de los formularios. Los objetivos a conseguir eran:

  • Que todos los sistemas usaran los mismos formularios del sistema de diseño
  • Obtener un diseño con un aspecto más moderno
  • Intentar que el formulario en su totalidad ocupara lo menos posible en altura
  • Mejorar la usabilidad en la visualización de los datos, el manejo de los errores…

Todos ellos eran importantes pero el primero sobre todo era básico, para evitar esfuerzos en el futuro.

Cualquier cambio que se hiciera en el sistema de diseño debía propagarse automáticamente al resto.

En un principio estudiamos la viabilidad de aplicar Material design pero decidimos crear unos patrones de diseño e interacción propios.

Para ello lo primero que se hizo fue recopilar los diferentes casos de formularios que existían en todos los sistemas para estudiar las funcionalidades y definir una serie de reglas (como buena fan que soy del Gov.uk):

  • Sólo se pedirá información cuando sea necesario.
  • Mejor formularios en una sola columna a no ser que no se quiera que haya scroll vertical. En el caso de que por cuestiones de espacio no se quiera alargar la página, el máximo serán 2 columnas principales.
  • Las labels siempre deben estar visibles.
  • Las labels deben estar asociadas al campo. Si se ponen encima del campo que haya separación visual del bloque con los otros campos.
  • Los textos de las label deben ser cortos y claros.
  • En móviles los campos irán normalmente al 100%.
  • Se leen mejor las minúsculas que las mayúsculas.
  • Placeholder o hint solo cuando aporte valor.
  • Agrupar los campos relacionados de forma visual.
  • Indicar el estado del campo en todo momento (focus, inactivo, error…)
  • En el caso de que haya errores debe quedar claro a que campo se refiere.

Sigue leyendo

Equipos de alto rendimiento

Continuamos con el resumen de la charla de Israel Alcazar (@ialcazar) en la CAS 2017 sobre como 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 qué 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…

Sigue leyendo

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.

Sigue leyendo

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.

Sigue leyendo

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.

Sigue leyendo

Eventos en Scrum I

Los eventos se usan en Scrum para crear un patrón constante y minimizar la necesidad de reuniones no definidas.

Todos los eventos son «time boxeados», es decir, tienen una duración máxima, pudiendo acabarse, siempre que se logre el objetivo del evento.

La idea es evitar el desperdicio de tiempo

El Sprint es un evento «contenedor«para todos los demás eventos, siendo cada uno de ellos una oportunidad formal para inspeccionar y adaptar algo. Y es que los creadores de Scrum,Jeff Sutherland y Ken Schwaber, diseñaron estos eventos para conseguir la máxima transparencia e inspección.

Scrum events

Existen 5 eventos diferentes:

  1. Sprint
  2. Sprint Planning, o Planificación del Sprint en castellano
  3. Daily Scrum, normalmente llamada Daily
  4. Sprint Review, o Revisión del Sprint
  5. Sprint Retrospective, o Retrospectiva del Sprint

He estado en algunas empresas que unifican Sprint Planning con Sprint Review, llamándo al evento «Syncro» o «Planificación» (adaptan Scrum a lo que han visto que mejor le funciona).

1. El Sprint

El Sprint es la base del Scrum. Es un periodo de tiempo de 1 mes, 3 o 2 semanas, durante el cual se crea un incremento de producto, utilizable y potencialmente liberable. Lo ideal es que siempre tengan la misma duración.

Para entender el párrafo anterior, debemos ver cada Sprint como un proyecto con un horizonte no mayor a un mes. Y al igual que un proyecto, el Sprint se utiliza para lograr algo. Cada Sprint tiene una definición de lo que se va a desarrollar, un diseño y un plan flexible que guiará su construcción, el trabajo y el producto resultante.

Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.

Un sprint está formado por el Sprint Planning, las Daily Scrums, el trabajo de desarrollo, Sprint Review y Sprint Retrospective.

Consideraciones a tener en cuenta durante el Sprint

  • No se realizan modificaciones que pongan en peligro el Sprint Goal.
  • Los objetivos de calidad no disminuyen.
  • El alcance (scope) puede ser clarificado y renegociado entre el Product Owner y el Developmente Team a medida que se descubren las cosas.

La limitación máxima de un mes es para minimizar riesgo y desperdicio. Si es más tiempo, en el mundo tan cambiante en el que estamos, la definición de lo que se está construyendo puede quedarse obsoleta, aumentando además la complejidad de lo creado.

Sigue leyendo

Product Manager

He estado trabajando bastante tiempo con empresas tecnológicas. En cada una tenía un nombre diferente, pero con el tiempo y hablando con la gente me he dado cuenta que se pueden aglutinar bajo uno solo: Product Manager.

Y es que uno de mis principios desde que realicé la carrera de Diseño, ha sido crear productos que la gente adore: bonitos, funcionales y usables, y sean sostenibles para la empresa.

Porque para construir un buen producto o servicio digital, el equipo o persona encargado de su Road Map, debe tener un conocimiento mixto de negocio, tecnología y experiencia del usuario (UX).

product_manager

Aunque como es imposible saber de todo, debe ser experto en al menos uno (en mi caso UX), ser apasionado por los 3 y haber trabajado en los 3 en general.

  • Negocio: no hay que olvidar que alguien tiene que pagar la fiesta. El Product Manager se centra en la optimización de un producto para alcanzar los objetivos comerciales mientras se maximiza el retorno de la inversión.
  • Tecnología: es muy complicado definir qué construir si se desconoce como se va a hacer y más importante, los recursos requeridos.
  • Experiencia del usuario: el Product Manager es la voz del usuario dentro de la empresa: debe hablar constantemente con los usuarios, testear el producto, analizar datos, detectar y priorizar los problemas a solucionar…. .

Funciones del Product Manager

Se debe establecer una visión del producto, investigando constantemente el mercado (informes de investigación, tendencias…), los usuarios (comentarios, atención al cliente, investigación etnográfica…) y el problema a resolver (mapas de empatía, customer journeys, análisis cuantitativo y cualitativo…).

Esa visión debe ser conocida por todo el equipo.

Si se realiza bien, cada miembro del equipo, desde ventas hasta desarrolladores, debe ayudar a crearla y sentirse parte de ella. Todos deben remar en la misma dirección.

Una parte importante es el establecimiento de las prioridades a desarrollar, el Road Map, el cual no es un documento definitivo, sino que puede variar dependiendo de la investigación que se vaya haciendo (recuerda que estamos en un mundo de constante cambio y es imposible predecir nada a futuro).

Sigue leyendo