Archivo de la etiqueta: Personas

Medición del impacto bajo la metodología de B Corp

Tiempo de lectura: 3 minutos

El pasado miercolés asití a una formación sobre cómo medir el impacto social de una actividad, aprendiendo a desarrollar los indicadores de medición necesarios.

Gracias a la metodología de B Corporation, se ha creado un movimiento global con más de 2.200 empresas en 50 países y 130 sectores con el objetivo de crear un modelo económico más humano y sostenible.

Pablo Sánchez fue el profesor que nos explicó los conceptos de la Teoría del cambio . Y es que no sólo los gobiernos deben implusar por cambiar el sistema que está claro que no funciona, sino que las empresas y los ciudadanos somos también responsables.

b Corporation

Y es que está demostrado que existen alternativas de compañías que son viables.

Que tienen beneficios preocupándose a la vez de generar un valor para la sociedad.

Sigue leyendo Medición del impacto bajo la metodología de B Corp

Mejorando la experiencia de usuario gracias a Soporte (I)

Tiempo de lectura: 6 minutos

Inés Luna (@cuquiesp) da una charla en la Tarugoconf 2016 (a mi modo de ver espectacular) sobre lo aprendido al montar un equipo de soporte desde cero en Teambox, titulada Usuarios, clientes y animales ¿Son todos iguales? con la que me siento muy identificada por las situaciones que comenta.

Nos cuenta que ha tenido suerte de no morir en el intento ya que era la primer empleada no programadora de la compañía, así como que nunca había trabajado en una startup ni en atención al cliente.

Divide la charla en 3 fases para definir la funcion de Customer service en base del crecimiento de la compañía, ya que al ser una startup empiezan con pocos clientes hasta llegar a manejar grandes cifras (3000-4000 clientes).

1 fase: Etapa del enamoramiento

Inés comenta que en esta primera fase, estableces una relación con tus clientes, y esta tiene que ser auténtica. El problema es que no eres la unica persona que habla con tus usuarios, sino que otros equipos ventas, mkt… también lo hacen.

Soporte debe ser la voz del cliente dentro de la empresa

Pero tu eres la unica persona que se preocupa de ayudarles. El de ventas quiere vender el producto y marketing va intentar disfrazar el producto para venderles la moto de algo.

UX y soporte

Si Soporte o Call Center no acaba defendiendo al cliente, siendo su voz dentro de la empresa, se corre el riesgo de que ese servicio se hace así de segundas, como “algo que hay que tener”, generando muchos problemas (algo que sucede en muchas empresas).

En Teambox, Inés nos cuenta que realizaba standup semanales donde comparte el feedback del cliente con el quipo de desarrollo y producto lo que les permite:

  • Tener una cultura de empresa de verdad centrada en los clientes
  • Identificar puntos de ficción de los usuarios con el producto
  • Descubrir casos de uso que nadie había pensado antes en la empresa, y los usuarios usan el producto de forma diferente a la que imaginabas.

Es ir más alla de la Atención al cliente y ser la voz cantante de que es lo que les pasa a tus clientes, por qué han venido a tu producto y cuales son los problemas que tienen con él.

Lo que haces con este feedback es todo y es determinante. No es solo escuchar sus preguntas y quejas y ser empático. Lo importanque es qué haces con todo ese feedback que te dan, cómo los sistematizas y lo vuelcas dentro de tu organización para que puedas influir en el producto y en el roadmap de forma q de verdad construyas un producto que resuelve los problems de verdad de tus clientes.

Una cosa que ha implementado Ines es un espacio donde los clientes pueden compartir su feedback, votar funcionalidades, sugerir que necesitan, que expresen por que las quieren… Todo eso crea un sentimiento de comunidad en la base de usuarios donde ellos mismo se ayudan unos a otros.

Sigue leyendo Mejorando la experiencia de usuario gracias a Soporte (I)

Cambiando la metodología de trabajo (o al menos intentarlo)

Tiempo de lectura: 4 minutos

He trabajado en varias empresas que querían modificar su proceso de desarrollo de producto. Algunas (2013) querían implantar una nueva metodología (Agile en este caso) y otras ya la tenían, pero necesitaban un pequeño reajuste para adecuarla a su cultura de empresa.

Y es que desde mi punto de vista, cualquier metodología o proceso de trabajo tiene sus herramientas e indicaciones, pero no siempre sirven al 100%, sino que debe adaptarse a lo que la empresa necesita en ese momento.

Son una base sobre la que trabajar para encontrar el proceso que realmente funcione para cada grupo de trabajo.

En ambos casos las empresas contrataron los servicios de una persona que facilitase y guiase el cambio. En una el proceso duraba X meses, para luego la empresa continuar por su cuenta con lo aprendido, mientras que en la otra la fase de implantación duraba X meses, pero prosiguiendo después el trabajo con el facilitador.

Es decir, (o por lo menos lo que yo creo que es lo ideal) esa metodología por la que se estaba apostando no era algo cerrado, inmutable para siempre, sino que seguiría evolucionado en el tiempo.

En ambas empresas, como muchos imaginaréis, el proceso no fue sencillo.

Para mi existen 2 puntos claves en el proceso:

  1. ¿El cambio viene impuesto desde arriba o es algo en lo que todo el equipo cree y apuesta?
  2. Como en cualquier materia, la constancia y repetición son claves para hacer algo bien.

Si el cambio viene impuesto desde la dirección, va a ser muy difícil que suceda si los principales implicados no lo aprueban. El facilitador se va a encontrar con un muro muy difícil de romper, no digo que imposible, pero muy complicado.

Lo ideal es partir de una base en la que la mayor parte cree que es necesario el cambio porque lo existente no funciona. O funciona pero podría ir mejor.  Pero aun siendo algo querido por todos, cambiar unas costumbres suele ser muy complicado.

No olvidemos que estamos trabajando con personas.

Personas que pueden llevar 5, 10, 15, 20 años trabajando de una misma forma. Personas que han luchado por sacar adelante un proyecto. Personas que no se han sentido escuchadas. Personas que van agobiadas porque tienen unos plazos de entrega. Personas con un baggage emocional hacia la empresa y otros compañeros.

Sigue leyendo Cambiando la metodología de trabajo (o al menos intentarlo)

Trabajo en remoto o presencial

Tiempo de lectura: 4 minutos

LLevo unos 10 años trabajando en empresas de todo tipo, grandes y pequeñas, y hablando con mucha gente sobre el tema, tanto dentro como fuera de España.

Como ya he comentado en anteriores artículos creo que una buena relación entre trabajador y empresa se basa en una confianza plena. En dar ambos lo mejor de si mismos para cuidar esa relación en beneficio de ambos.

Trabajo en remotoEscritorio de bambú LILLÅSEN (IKEA)

Si no se confía en la responsabilidad del trabajador, el jefe debe estar constantemente encima, controlándolo. Qué hace, qué horario lleva… Eso a mi modo de ver, impide que la organización crezca de una forma sana, aparte de un desperdicio de recursos al tener a los managers haciendo de “padres”.

Puede que en determinados puestos de trabajo con una alta rotación tenga que ser así, pero en el sector que me encuentro quiero pensar que no.

Trabajo presencial

Para mi la mayor ventaja que tiene el trabajo presencial es la posibilidad de interactuar con las personas directamente, y la creación de equipo. No digo que no se pueda crear equipo en remoto, pero creo que cuesta más.

Y es que pese a que hoy en día la comunicación es más directa y efectiva que nunca, se pierden matices, como los correspondientes a la comunicación no verbal, que son los que transmiten mayor confianza.

El roce hace el cariño, ya lo dice el refrán

He estado en varias empresas que por tener separados a 2 departamentos en distintas planta del edificio ya no existía ese sentimiento de grupo e implicación. Y eso que eran ambos desarrolladores! Que cuando son dos departamentos diferentes, Call Center y Devs, por ejemplo, la cosa empeora (menos mal que está UX por en medio intentando que se comuniquen je je!)

Creo que se podrían haber hecho muchas cosas por intentar evitar eso, pero volviendo al tema, el estar trabajando en remoto, obliga a realizar un mayor esfuerzo de empatía por esas personas que no conoces físicamente.

Trabajo en remoto

El trabajo en remoto tiene para mi varias ventajas:

  • Acceso a los mejores profesionales allá donde estén, ya no tienes que preocuparte de buscar gente que viva en tu ciudad sino que tienes el mundo entero para buscar.
  • Evitar perder tiempo y dinero en transporte (y menos contaminación en muchos casos). Ese ahorro de tiempo repercute en una mayor calidad de vida.
  • Flexibilidad laboral. Normalmente las empresas que realizan este tipo de trabajo, al confiar en las personas, no les obligan a estar de 9:00 a 18:00 en su sitio, permitiendo que se organicen como quieran. Lo importante es que el trabajo salga.
  • Muchas veces, el estar rodeado de personas, hace que haya estímulos que interrumpen el estado de “flow” propuesto por el psicólogo Mihály Csíkszentmihályi en 1975. El estar en remoto mucha veces hace que cunda más el tiempo de trabajo al no gastarlo en distracciones no productivas.
  • Se evita que todos los trabajos se concentre en las ciudades más grandes, pudiendo vivir el trabajador donde desee. En España, hay muchas más oportunidades laborales en Madrid y Barcelona, y mucha gente se ve obligada a vivir allí si quiere prosperar profesionalmente. Esto es una serpiente que se muerde la cola, al masificarse y encarecerse estas ciudades, bajando su calidad de vida, y dejando otros núcleos vacíos.
  • Ahorro de costes para la empresa al no necesitar pagar el alquiler de un local.

Esa mayor calidad de vida y confianza, genera en los empleados una sensación de gratitud y estima hacia la empresa. Los trabajadores se vuelven leales.

Creo que funciona mucho mejor cuando todos los miembros están en remoto, pero aun así con sólo una parte también funciona, siempre que exista la cultura y las herramientas adecuadas.

¿Algunos ejemplos? Ahí van…
Sigue leyendo Trabajo en remoto o presencial

Esto va de siglas: PMBOK® vs SCRUM

Tiempo de lectura: 3 minutos

Últimamente, durante este pasado año, he estado leyendo bastante sobre gestión de proyectos. Como en todo, hay un montón de información, con siglas y definiciones que pueden volver loca a cualquier persona.

En esta caso nos centraremos en las referidas a PMBOK® y SCRUM, cuyo error más común es pensar que PMBOK® es una metodología de gestión de proyectos, cuando es un estándar que recoge “the best practices”, es decir, las mejores prácticas del sector.

Es el Project Manager quien decide que procesos aplica, con que nivel de detalle y ver que metodología escoge para la gestión, ya sea ágil como SCRUM o tradicional.

Web de Scrum.org

Imagen de la web de srcum.org

No son opciones excluyentes, sino complementarias, gestionando un proyecto teniendo en cuenta el marco definido en el PMBOK® pero aplicando metodologías ágiles para su desarrollo.

Más lío viene aun cuando nos metemos en el tema de certificaciones con tantas siglas ya que dependen de la entidad que las gestiona:

  • Certificación PMP® (Project Management Professional) del PMI®
  • Certificación PMI-ACP® (PMI Agile Certified Practitioner) del PMI®
  • Certificación PSM I (Professional Scrum Master) de Scrum.org

The Scrum Framework

SCRUM, por su parte es un método de gestión de proyectos con un enfoque ágil, especialmente útil en proyectos de desarrollo de software, pero que también se puede aplicar a otro tipo de proyectos y sectores. Aquí puedes descargarte de forma gratuíta la guía de Scrum escrita por Ken Schwaber and Jeff Sutherland, las persona que definieron el método.

Igual que SCRUM encontramos otras metodos ágiles como:

  • Extreme Programming (XP)
  • Lean Development
  • Kanban Development
  • Feature Driven Development (FDD)
  • Dynamic systems development method (DSDM)
  • Crystal Clear

Scrum.org ofrece entre otras la Certificación Professional Scrum Master™ (PSM) con 3 niveles de evaluaciones profesionales Scrum Master (fundación, intermedio y avanzado) que validan y certifican sus conocimientos de Scrum y la capacidad de aplicar ese conocimiento.

PMBOK® (Project Management Body of Knowledge)

El PMBOK®, en castellano, Guía de los fundamentos para la dirección de proyectos, es un estándar de gestión de proyectos que recoge las mejores prácticas del sector, gestionado y actualizado periódicamente por el PMI®.

Actualmente se encuentra en su 5ª Edición, y su 6ª Edición, se publicará oficialmente en septiembre de 2017.

Sigue leyendo Esto va de siglas: PMBOK® vs SCRUM

Requerimientos de un proyecto

Tiempo de lectura: 3 minutos

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.

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

Sigue leyendo Requerimientos de un proyecto

¿Qué busca el usuario en una web?

Tiempo de lectura: 3 minutos

Las personas accedemos a internet buscando satisfacer una necesidad de información y/o realizar una transacción.

Este artículo vamos a hablar sobre el primer caso: la satisfacción de una necesidad de información, basándonos en el libro de Mario Pérez-Montoro Gutiérrez, “Arquitectura de la información en entornos web“. Te recomiendo su lectura si te gusta el tema.

Tipos de necesidad de información

Existen 4 tipos de necesidades informativas:

  1. Necesidad de información concreta (NIC) o búsqueda de un item conocido. Esta necesidad responde al momento en que el usuario busca cuánto vale un vuelo de Barcelona a Nueva York o quién ganó la copa de futbol en 1982. Es una necesidad que se puede formular de forma exacta y que se resuelve a partir de una única respuesta.
  2. Necesidad de información orientada a problemas (NIOP). En este caso, no acostumbra a presentar unos límites bien definidos o no se puede establecer si se necesita más información para resolverla. Para ello, el usuario navegará a través de diferentes items de información hasta que crea que ha resuelto su necesidad. El ejemplo que nos presenta Mario Pérez-Montoro en su libro sería conocer la relación entre la educación de un país y su economía.
  3. Necesidad de información exploratoria (NIE) o búsqueda exploratoria. En este caso se busca una respuesta útil dentro de un conjunto de respuestas localizadas previamente. Lo que ocurre es que no estamos seguros de que la respuesta elegida sea la más adecuada. Por ejemplo ocurre, cuando después de haber investigado varios hoteles para las vacaciones que se ajustan a nuestro presupuesto, buscamos opiniones de otros usuarios que nos ayuden a decidirnos sobre el tema.
  4. Necesidad de información sobre búsquedas previas (NIBP) o recuperación de una búsqueda. En este caso el problema de necesidad de información se resuelve volviendo a localizar una información que ya habíamos encontrado previamente, como cuando abrimos una página web que tenemos guardada en favoritos.

¿Cómo resuelvo mi necesidad de información?

Dependiendo del contexto, la forma de satisfacer esa necesidad cambia. Un niño pequeño, le pregunta a su madre, en el instituto le preguntamos al profesor, en un aeropuerto a la persona del mostrador de información, antiguamente si estábamos perdidos con el coche por una ciudad, al primer peatón que pase.

Sigue leyendo ¿Qué busca el usuario en una web?

Investigación de usuarios en la BBC, un caso práctico con impacto

Tiempo de lectura: 4 minutos

Júlia Ivorra da una de las charlas que más me ha gustado este año: Investigación de usuarios en la BBC, un caso práctico con impacto.

Nos cuenta como en la BBC Sport habían desarrollado un ecosistema de productos y servicios (online y offline) para su audiencia y querían, aprovechando un verano lleno de deporte, mejorar los servicios de la BBC online y preparar la cobertura de las Olimpiadas de Tokyo 2020.

El objetivo era averiguar cuáles eran las motivaciones de nuestros usuarios para conocer porque usaban unos productos u otros. Es decir, averiguar como estaba la BBC integrada en la vida de las personas.

Pero no querían hacer una investigación que sólo generase un informe tocho de entrega al final del verano que solo vieran (en el caso de que lo lean) los jefes, en vez de todo el equipo, por lo que definieron como querían que fuera su proyecto de investigación:

  • Tenía que ser agile
  • Tenía que ser reportada diariamente. Integrada con el trabajo. No sólo un informe al final del proceso
  • Involucrando a todo el mundo

Tenían unos 30 eventos para analizar en 3 meses y medio. Y pensarás, ¿por qué tantos?
Pues porque cada evento es único, y la gente que los sigue es diferente, no es la misma persona la que sigue el golf que la que ve el futbol.

Dividieron la investigación en 4 rondas con 4 participantes cada uno, realizando un análisis de resultados en cada ronda y difundiendo al equipo lo que estaban descubriendo.

Informaban al resto del equipo en vivo, mientras estaban pasando los eventos.

Iban publicando todo lo que iban averiguando en un canal de Slack consiguiendo que la gente les hiciera preguntas para que el equipo de investigación se las preguntase a los usuarios. O si veían algo raro en las analíticas, lo comentaban para que intentaran averiguar porque sucedía.

Como todo el mundo seguía el canal, muchos incluso se acercaban a las entrevistas que les interesaban.

Todo el equipo estaba hablando de usuarios, de cómo usaban sus productos.

Consiguieron erradicar, el típico “yo creo”, “a mi me gusta” o “he leído un post que dice esto”.

A nivel formal después de cada ronda iban difundiendo lo que aprendían colgando en una pared de la oficina las cosas para que todo el mundo las tuviera presente.

Caso de research en la BBC

También crearon artefactos UX: un journey map de toda la información que les estaba llegando. 
Y lo mejor, es que estos artefactos se siguen usando a día de hoy, no son algo puntual.

Están basados en algo real. En casos de usuarios reales.

Y a un nivel superior, pasó algo muy bonito. Los jefes ya no estaban encerrados en reuniones decidiendo que iban a hacer, sino que iban leyendo el mismo canal y haciendo preguntas cuando creían conveniente.

Y es que como comenta Julia, si sólo involucras a los jefes mandándole sólo a ellos el informe, en vez de a todo el equipo, acaba pasando que parece que están en una bola de cristal, aislados, con conocimientos únicos que solo poseen ellos.

Habían conseguido q los stakeholders hicieran User Centre Design.

Así cuando los jefes tuvieron que tomar decisiones estratégicas, las tomaban en base a casos reales.

Y cuando compartían los nuevos objetivos estratégicos a seguir todo el mundo los entendía y supo porque se habían tomado esas decisiones.

A mi modo de ver, una de las cosas que más fallan las empresas es en conseguir que todo el mundo comparta la misma visión del negocio. Qué los de arriba tengan información del día a día para tomar decisiones y encaminar el futuro de la empresa y qué las elegidas sean entendidas por toda la compañía.

Porque se puede IMPONER remar en una dirección, pero se avanza mucho más rápido cuando todo el equipo CREE que es la correcta.

En resumen, Ivorra finaliza compartiendo lo que ha aprendido en base a este proceso y que aplica en su día a día:

  • Ser agile: dividirlo todo y realizarlo a menudo
  • Ser transparente: todo el mundo tiene acceso a leer los proyectos e involucrarse en la investigación
  • La investigación tiene que tener un propósito, se hace para ayudar a otros a hacer mejor su trabajo.

Muchas gracias Julia por compartir un caso real de trabajo. Me ha encantado!

Diseñar servicios cara a cara

Tiempo de lectura: 3 minutos

Una de las charlas que más me ha gustado ha sido la de Itziar Pobes de la empresa WeQuestionOurProject, un estudio de diseño de servicios en Barcelona.

Itziar nos comenta 3 ejemplos de proyectos que han realizado (me encanta cuando nos los ponentes nos cuentan ejemplos).

El primero trata sobre un pequeño ayuntamiento el cual, su población al estar cerca de la universidad tenia un elevado porcentaje de gente joven. Éstos les empezaron a hablar y a preguntar dudas usando las cuentas de Facebook y otras redes sociales que poseía la institución.

¿Y qué pasaba? Que sino respondan quedaban mal, por lo que aunque no era muy legal responder a algo oficial por ese medio, prefirieron dar el servicio.

Y los ciudadanos estaban encantados.

La alcaldesa se enteró y en vez de pararlo, decidió ver como podía mejorar el sistema. Incluso decidió tirar la oficina y construir una nueva generando un montón de inquietudes en el equipo de atención al ciudadano, al no tener ni un sitio donde trabajar. Y es en estos momentos, es cuando el equipo de Itziar entró a trabajar.

Empezaron a investigar las dinámicas de trabajo, cuales eran los diferentes servicios que los ciudadanos podían hacer… construyendo prototipos muy rápidos mediante cajas de cartón en la oficina en obras para ver como interactuaban en una situación real, probando la experiencia en la oficina.

El resultado final fue muy visual y tuvo mucho impacto, y el ayuntamiento, que siguió contando con WeQuestionOurProject durante los años siguientes, les ha gustado tanto la nueva forma de enfocar sus servicios, que ha llegado a montar incluso su propia oficina de innovación.

Rediseño de oficina aplicando service design

Rediseño de oficina aplicando service design

El siguiente proyecto consistía en una app para evitar la soledad a las personas mayores.

Cuando llegaron al proyecto ya estaban realizando un segundo proyecto piloto con desarrollo, equipo de UX y accesibilidad, de desarrollo, equipo de servicios sociales, personal de Evaluación de políticas públicas…

Service design

Sigue leyendo Diseñar servicios cara a cara