Checklist de arranque de proyecto UX

Muchas empresas antes de empezar el proyecto, mandan al cliente una checklist de preguntas para obtener la máxima información de contexto, y obtener así una primera impresión del proyecto, su naturaleza, su competencia, su historia, responsables, objetivos…

Toma de requerimientos proyecto UX

Imagen extraída del checklist de Olga Revilla

A continuación os dejo un ejemplo de este tipo de preguntas realizado por Olga Revilla en 2009, pero  cuyo contenido sigue siendo actual: Requerimientos iniciales de un proyecto. Son 69 preguntas repartidas en varias categorías:

  • Datos básicos
  • La empresa y su entorno
  • Los usuarios y clientes
  • Misión y objetivos del sitio
  • Tareas
  • Expectativas, requisitos y preferencias
  • Contenidos
  • Requisitos de accesibilidad
  • Recursos humanos disponibles
  • Recursos técnicos disponibles

Estas preguntas son perfectas para una primera toma de contacto y más importante, alinear expectativas con el cliente de lo que espera del proyecto.

Seguir leyendo

Consejos para trabajar con equipos remotos

Noviembre vino cargadito de eventos en Valencia y entre ellos uno de los más importantes fue  la StartupWeek (@vlcstartupweek) con charlas en diferentes lugares de la ciudad y de diferente temática.

En concreto una de las que más me gustó fue la impartida en Insommnia por Jordan Mirchev (@jordanmirchev) de Trello y Børge Dvergsdal (@borgedv) de Appear.in sobre Future of work, es decir, el “Futuro del trabajo”.

Y es que los Milleninials trabajan tienen diferentes espectativas de la vida que las anteriores generaciones y buscan diferentes motivaciones, siendo una de ellas conocer el mundo.

Por ello, buscan compañías que les permitan realizar su trabajo en cualquier lugar, es decir, que creen y fomenten el trabajo en remoto, motivándoles con ello a alcanzar uno de sus sueños.

Y es que aunque el trabajo en remoto pueda parecer complicado a primera vista, tiene muchas ventajas, entre ellas que las empresas pueden alcanzar a los mejores profesionales de todo el mundo.

Y es que no solo los Millenials, sino que determinados perfiles o no viven en el lugar donde está la empresa o no quieren ubicarse en un lugar específico. Y, como empresa, ¿vas a dejar escapar ese potencial por no adaptarte?

Lógicamente no todas las personas están capacitadas para saber o querer trabajar de esta forma.

La confianza y la responsabilidad son elementos claves que deben darse en empresa y empleado.

En mi opinión estos elementos son claves para cualquier forma de trabajo, no sólo debe darse cuando se trabaja a distancia. Porque sino se confía en esa persona o ella no es responsable para entregar el mejor trabajo posible, ¿cómo se va a delegar y crecer?

Siguiendo con el tema del trabajo en remoto, una de sus desventajas es que con la distancia es más complicado establecer vínculos entre los miembros del equipo. Jordan y Børge, especializados en ofrecer software que ayuda a salvar este problema nos contaban como ayudar a construir empatía entre compañeros y equipos que trabajan de forma remota.

Appear.in, es una compañía que desarrolla software para realizar videoconferencias de forma sencilla, llamadas metafóricamente “Rooms”.

Cuando se trabaja de forma remota el vídeo es una herramienta extremádamente importante para comunicarse.

Uno de los problemas que más se repiten (desde mi punto de vista) en las empresas es la falta de comunicación. Por ello, si ya en persona es un punto clave que cuesta conseguir (he visto empresas que un pasillo era peor que el Abismo de Helm) en remoto ésta debe ser muy consciente y fluída.

He trabajado en empresas con parte de las personas en remoto, y conseguir que el equipo tenga el mismo mindset es clave.

Por ello si se parte de un equipo que ha trabajado de forma presencial, se debe cambiar la mentalidad, que con las herramientas adecuadas y un poco de consciencia por parte de todos se puede conseguir.

Seguir leyendo

Análisis transaccional

Israel Alcázar comenta en su charla de la CAS 2017 que al descubrir el concepto de análisis transaccional comprendió muchas de las relaciones que veia entre las personas cuando las analizaba en el ámbito laboral.

Las relaciones entre las personas en las estructuras jerárquicas funcionan como relaciones padre-madre-hijo. En la que el jefe es la figura de autoridad y se comportan con él como si lo hicieran con sus padres.

Análisis transaccional

Y desde el punto de vista del jefe, se ve al colaborador como el hijo, al que hay que decirle lo que tiene que hacer porque es lo mejor para el y preguntarle a ver como va, porque no te fías…

Esto en el fondo es una disfunción porque hace que las personas no sean autónomas o responsables para hacer su propio trabajo.

Es un sistema que viene del psicoanálisis desarrollado en los años 50 y que básicamente trata de que con un lenguaje sencillo las personas tengan esa autonomía o responsabilidad. Algo que en principio todos somos capaces de tener a no ser que se tenga alguna enfermedad psicológica.

El análisisis transaccional establece que en estas relaciones, el yo, la persona, se puede comportar de 3 modos diferentes, como padre, como adulto o como niño. Y que la otra persona con la que se interacciona, con la que se establece la relación, le pasa exactamente igual, asumiendo uno de estos roles.

El problema viene cuando en la relación con la otra persona, por ejemplo con mi jefe, yo me comporto como hijo, esperando que mi jefe se comporte como padre. Si lo hace, hay un matching, y no ocurre nada, todo el mundo se ha comportado como se esperaba.

Pero, ¿y si se espera de esa transacción algo diferente?

Es decir, yo me comporto como adulto que soy, y espero que mi jefe se comporte de la misma forma, tratándome de adulto a adulto, y me oriente y me deje esa resposabilidad. Pero si él está acotumbrado a comportarse como padre y me dice lo que tengo que hacer, tratándome como hijo, eso no me gusta.

Estoy segura que te has sentido alguna vez en esta situación.

Por mi parte, espero de un jefe indicaciones, que se comporte como un guía indincando una dirección a seguir pero no que me lleve de la mano todo el camino ni que me vigile constantemente a ver si se descubrirlo yo solita.

Por que en el caso de que me vea perdida, soy lo suficientemente adulta para alzar la voz, reconocerlo y pedir ayuda.

¿Y tú? ¿Me cuentas si te has sentido en esta situación alguna vez?

Nota: La imagen está extraída de la keynote de Israel Alcazar en la CAS 2017

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…

Seguir 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.

Seguir leyendo

La II Guerra Mundial, Japón y su importancia en la UX

Últimamente he estado leyendo mucho sobre Lean, Agile, Scrum, Kaizen… Y bastantes términos y artículos mencionan Japón, viniendo en muchos casos relacionados con su rápido resurgimiento después de la destrucción que vivió durante la Segunda Guerra Mundial.

Por ejemplo, el framework Scrum fue creado por Ken Schwaber y Jeff Sutherland directamente después de la publicación de Ikujiro Nonaka e Hirotaka Takeuchi de “The New New Product Development Game” en 1986, en la Harvard Business Review (HBR).

Pues bien, Nonaka fue contratado por el gobierno japonés después de la Segunda Guerra Mundial para ayudar a analizar por qué perdieron la guerra.

Otro ejemplo más relacionado con la UX o Experiencia de Usuario es el caso de W. Edwards Deming y su sistema de medios para generar de forma sostenible y económica productos y servicios que satisfagan los requerimientos del cliente (¿te suena?)

William Edwards Deming

Como consecuencia de la II Guerra Mundial, Japón estaba muy dañado, a pesar de diferentes cómites de los países aliados, no había grandes mejoras.

La situación era grave ya que no podía producir la sufciente comida para alimentar a la población, y no podían exportar bienes para ganar dinero para comprar alimentos, ya que la producción industrial era muy mala (patrimonio negativo).

El Dr. Deming (1900-1993) ingeniero y consultor de gestión estadounidense, fue invitado por el directore ecutivo de la a Unión de Científicos e Ingenieros Japonenes, JUSE (Japanese Union of Scientists and Engineers), Qenichi Qoyanagi, para que les diera a los investigadores, líderes empresarios e ingenieros, una serie de conferencias sobre métodos de control de calidad y sus teorías de gestión en agosto de 1950 en Tokyo (Hakone Convention Center).

En ellas animaba a los japoneses a producir con calidad, siguiendo el método de realizar una investigación y mirar a futuro para producir bienes que tuvieran mercado durante mucho tiempo. Al finalizar el verano, había llegado a le gerencia de la mayoría de las grandes compañías, como Sony.

Muchos consideran que Deming fue una de las inspiraciones del milagro económico japonés de posguerra (1950 a 1960) al influenciar con sus ideas la forma de trabajar, entre ellas:

  • Mejorar el diseño de los productos para mejorar el servicio
  • Conseguir el mejor nivel uniforme de calidad de producto
  • Mejorar las pruebas de productos en el lugar de trabajo y en los centros de investigación
  • Aumentar las ventas gracias a los mercados secundarios (glbales)

En resumen el mensaje a los líderes japoneses fue que si invertían en calidad e investigación, la mejora en el diseño y la calidad a la larga reduciría los gastos al tiempo que aumentaría la productividad y la cuota de mercado.

Varios fabricantes japoneses aplicaron sus técnicas y experimentaron niveles de calidad y productividad desconocidos hasta el momento. Combinando el aumento de calidad junto con un coste reducido creó una nueva demanda internacional de productos japoneses.

Seguir leyendo

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 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.

Seguir 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).

Seguir leyendo

Ley de Little

La ley de Little (por la primera persona que la enunció John Little, 1954), conocida como Teoría de colas o Líneas de espera, usada para calcular el rendimiento de los sistemas ofrece múltiples aplicaciones.

La ley enuncia lo siguiente: el número medio de usuarios “N” que hay en un sistema (durante un tiempo determinado) es igual a la velocidad media “V” a la que entran en el sistema multiplicada por el tiempo medio “T” que están dentro.

 N = V × T.

Aunque parece intuitivamente fácil, hay que destacar que la relación no está influenciada por la distribución del orden de llegada, cómo se atiende a los usuarios o prácticamente cualquier otra cosa.

Gestión trabajo

Visualización de tareas en un sistema mediante Jira

Por ello se puede aplicar a cualquier sistema que procese cosas, y ​​a sistemas dentro de otros sistemas. Los únicos requisitos son que el sistema sea estable y no preventivo.

Es usada en sistemas informáticos, para calcular plazos de entrega de trabajos o pedidos, para saber cuanto tiempo un cliente tiene que esperar a ser atendido en una caja de un supermercado…

Ley de little en la gestión del trabajo

Yo descubrí esta ley oyendo un vídeo sobre Kanban de Jerónimo Palacios en la Coferencia Agile Spain 2016 hablando sobre la relacion directa entre nuestro lifetime, el trabajo existente en curso y la capacidad de entrega. De ahi me puse a aprender un poco más sus aplicaciones.

Seguir leyendo