2017

Ventajas de los workshops

Ir a un sitio nuevo, juntar varias personas de diferentes ámbitos para que trabajen juntas, darles rotuladores y post-its, y pedirles que no hablen sino que escriban o dibujen sus ideas, predispone al cerebro a trabajar de forma diferente.

Un workshop rompe la rutina y crea nuevas situaciones y sensaciones desde el inicio.

Te levantas a una hora diferente, te vistes de otra forma, coges un camino alternativo ya que no vas a la oficina… Con la idea de trabajar en grupo podemos incluso estar un poco nerviosos… nuestro corazón se acelera.

La rutina es buena para alcanzar orden y eficiencia en una profesión, pero si buscamos creatividad, necesitamos inspiración.

Un workshop consigue inspiración e innovación al juntar miembros con diferentes conocimientos, al cambiar los roles de cada día… pero lo más importante es que los equipos consiguen nuevas ideas JUNTOS.

Pensar y construir juntos

Tanto en la vida personal como en la profesional, trabajamos en varios proyectos con mucha gente en los que asumimos diferente roles. En algunos, lideramos, en otros delegamos, en otros colaboramos… pero ¿cuántas veces trabajos activamente juntos?

Muchas veces gastamos más energía defendiendo una primera opinión que explorando más opciones cuando a lo mejor no es la opción más adecuada para el grupo.

Además en una reunión hablada siempre hay gente que habla más o gente más tímida que no participa. Si todo el mundo está obligado a escribir o dibujar sus ideas, todo el mundo tiene voz. No existen problemas de ego, ni de que «siempre decida el jefe».

Las ideas no son de nadie, pertenecen al grupo.

Es el grupo quien las valora en conjunto. Nadie discute nada, sino que todo se visualiza. El resultado son un montón de opciones que facilitan la extracción de conclusiones.

Evitar la figura del experto

En un workshop no hay nadie delante de todo el grupo hablando. En vez de hacer un trabajo individual sobre lo que somos expertos que nadie lee, es mejor visualizar un proyecto común a través del dibujo o la escritura, construyendo un proyecto mediante la contribución de cada uno en vez de crearlo separadamente.

Seguir leyendo «Ventajas de los workshops»

Getting Things Done® (GTD®)

Getting Things Done® (GTD®) es una metodología para ser más productivo sin estrés. Escrita por David Allen y publicada en un libro en 2001, en un principio estaba dirigida a  altos directivos, pero su uso puede ser aplicado a cada aspecto de tu vida.

Your mind is for having ideas, not holding them®

(David Allen)

Se basa en la idea de que nuestra mente es para generar ideas, no para mantenerlas, con lo que sino almacenamos de forma correcta las ideas, pensamientos… que vamos teniendo, el espacio que ocupan no permitiendo entrar a otras o el miedo a olvidarnos de ellas, nos genera un entimiento de estrés constante.

Más que un conjunto de consejos para la gestión del tiempo y la organización, GTD® es un sistema de gestión total. Allen crea un modelo coherente para almacenar elementos clave, los cuales aun pueden ser necesarios para nosotros, tanto para su uso futuro como presente.

El GTD es para no hacer, o más bien hacer sólo lo que vale la pena hacer.

Se trata de reducir la presión entrante de tareas por hacer aparcándolas en un sistema de almacenamiento auxiliar para centrarse en hacer sólo algunas.

En este mundo de información, constantemente nos están llegando nuevos datos, proyectos, ideas… que procesar que se suman a los que ya teníamos. El propósito de su proceso de gestión de flujo de trabajo es facilitarnos el hacer buenas elecciones sobre lo que estamos haciendo en ese momento.

GTD Diagram

 

Regla de los 2 minutos

A mi modo de ver, lo que cuenta Allen es de sentido común, y seguramente muchas de las cosas ya las haceis en vuestro día a día. Un ejemplo muy sencillo es la regla de los 2 minutos descrita en el diagrama superior.

La idea es muy sencilla. Cuando algo te llega, lo primero que te preguntas es si puedes hcer algo con eso. Si la respuesta es si, piensas en cual es la siguiente acción que quieres hacer con eso. Y si esa acción te cuesta menos de 2 minutos, la haces en ese momento, sino la delegas o la pospones apuntándola en un calendario si es para hacer en una fecha específica o en tu sistema de siguientes acciones.

GTD® en 5 pasos

La metodología se basa en 5 pasos que son los que naturalmente suceden en nuestra mente con las acciones más simples, solo que muchas veces lo hacemos de forma automática (Natural Planning Model) y no le ponemos nombres.

Seguir leyendo «Getting Things Done® (GTD®)»

Recursos sobre Evaluación Heurística

Un análisis heurístico es una técnica para evaluar la usabilidad de un sistema de interfaces y procesos a cargo de un experto, a partir de los principios de la disciplina de Interacción Persona-Ordenador (IPO o HCI en inglés, Human Computer Interaction).

Esta técnica es perfecta para entender el estado actual del producto e identificar problemas básicos a evitar si es un rediseño o proponer soluciones para arreglarlos.

El análisis consiste en una serie de comprobaciones en base a criterios establecidos que velan por la usabilidad y la consecución de los objetivos de negocio de la aplicación.

Estos criterios se deben adecuar al contexto, por lo que hay que previamente hay que conocer las tareas que se han de realizar y el perfil de usuarios que van a utilizar el sistema o sitio web.

Principios de Jakob Nielsen

Los principios heurísticos de Jakob Nielsen son probablemente los más usados para verificar la usabilidad del diseño de interfaz de usuario.

Existen dos versiones, una primera publicada junto con Rolf Molich en 1990, donde se les denomino «heurísticas» y una segunda junto con Marie Tahir en 2002, donde se revisan los anteriores en base a un análisis de más de 200 sitios web (anglosajonas). A continuación, se enumeran los contenidos en la segunda publicación:

  1. Visibilidad de estado del sistema, informando a los usuarios de lo que ocurre proveyendo feedback adecuado.
  2. Correspondencia entre el sistema y el mundo real. El lenguaje empleado debe ser adecuado al usuario, siguiendo en todo momento las convenciones del mundo real.
  3. Control de uso y libertad. Dado que el usuario va a cometer errores, el sistema debe ayudar a evitar situaciones indeseadas.
  4. Consistencia y estándares para que el usuario no tenga que adivinar diferentes conceptos o palabras. Seguir las convenciones de la plataforma que se esté usando.
  5. Favorecer la prevención de errores antes de que estos ocurran mediante elementos que ayuden a evitarlos.
  6. Reconocimiento de los elementos antes que recuerdo, optando por la visibilida y repetición de elementos, así como de estándares de uso evitando la sobre carga cognitiva de la memoria a corto plazo.
  7. Flexibilidad y eficiencia de uso, estando adaptado tanto para usuarios novatos y expertos.
  8. Estética y diseño minimalista evitando usar elementos que no sean necesarios y sólo añadan ruido visual, restando importancia a los que si la tienen.
  9. Ayuda a los usuarios para reconocimiento, diagnóstico y recuperación de errores mediante indicaciones claras de cómo resolverlos.
  10. Aunque lo ideal es que no sea necesaria, en el caso de que se requiera debe existir una ayuda general y documentación de forma accesible y concisa.

Recursos:

Lista de comprobación de Deniese Pierotti

El conjunto de principios heurísticos de Nielsen ha servido como punto de partida para la creación de numerosas listas de subheurísticos. La de D. Pierotti fue usada por la empresa Xenox Corporation, famosa pionera en evaluar la usabilidad de sus interfaces.

Añade 3 principios a la lista de Nielsen, más una lista de sub-heurísticas de los 10 principios de Nielsen y de los 3 nuevos añadidos:

  • 11. Habilidades: el sistema debe tener en cuenta, extender, suplementar e incentivar las habilidades del usuario, sus conocimientos y su experiencia.
  • 12. Interacción placentera y respetuosa: Las interacciones de los usuario con el sistema deben favorecer su calidad de vida, presentando un diseño estético, en donde los valores artísticos se igualen a los funcionales.
  • 13. Privacidad: el sistema debe ayudar al usuario a proteger la información personal o privada, tanto la del propio usuario como la que pertenece a los clientes del usuario.

8 Principios de usabilidad de Ben Schneiderman

Pero estos no son los primeros. Existen otros, como las 8 reglas de oro para el diseño de interfaces de Ben Schneiderman, publicadas por primera vez en 1986 en su libro «Designing the User Interface: Strategies for Effective Human-Computer Interaction«. Seguir leyendo «Recursos sobre Evaluación Heurística»

Esto va de siglas: PMBOK® vs SCRUM

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

Seguir leyendo «Esto va de siglas: PMBOK® vs SCRUM»

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»

¿Qué busca el usuario en una web?

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.

Seguir leyendo «¿Qué busca el usuario en una web?»

Meetup de Juegos y dinámicas ágiles

El pasado día 7 de junio nos juntamos en las oficinas de Flywire para una nueva reunión del grupo de Agile Levante, organizado por Emma López (@hell03610).

El taller consistía en la realización de dos dinámicas lúdicas, aprendiendo de ellas diferentes tipos de problemas que surgen en entornos de desarrollo.

Comunicación y visión compartida

La primera dinámica se realizaba en parejas. Una persona era el constructor y la otra el gestor (creo, no recuerdo muy bien los nombres). La idea era cambiar en base a los roles que ejecutamos en nuestro día a día para entender el papel de la otra persona.

Juegos agile

Emma le dio a cada gestor unas instrucciones para hacer una figura de origami (la conocida ranita) para que se las dictará al constructor. El constructor, apoyado en una mesa, con un folio, y de espaldas al gestor, no podía verlas no podía tampoco hablar con el gestor.

Así mismo el gestor tampoco podía ver lo que iba haciendo el constructor en base a sus indicaciones, con lo cual, imaginaos lo que salió de ahi. Ningún equipo consiguió finalizar algo similar a una ranita 🙁

En la segunda ronda, el gestor podía ver lo que realizaba el constructor e ir guiándole en consonancia a los pasos que daba. En este fase, sólo 2 equipos acabaron las ranitas.

Y en la tercera ronda, tanto el gestor como el constructor, veían las instrucciones. El gestor ayudaba al constructor guiándole y explicándoselas. En este caso todos los equipos acabaron las ranitas y a una mayor velocidad.

De este juego, se extrae la importancia de compartir todos los miembros del equipo la misma visión, y que está quede de alguna manera reflejada de una forma visual, ya que las palabras dependiendo de quien las interprete pueden tener diferentes significados.

Y es como dice Dani Latorre en este post sobre Una de BDD, Specification by Example y Cucumber: «Muchos problemas cuando desarrollamos software surgen de los malentendidos de comunicación entre los diferentes miembros del equipo. »

Estimación, competitividad y la importancia del testeo

En el segundo juego nos dividimos en 2 equipos. Emma nos dio 3 tipos de aviones diferentes a construir en papel, cada uno en folios de un color. Dependiendo de su dificultad cada tipo valía unos puntos u otros.

En una reunión inicial, debíamos decirle cada equipo, cuantos aviones de cada tipo íbamos a entregarle en los 4 minutos de tiempo para construir que disponíamos con el requisito imprescindible de que pasasen su test de vuelo.

Ahí, ya cometimos el primer error. Estimamos pensando en que TODOS iban a volar, es decir, el número de aviones que íbamos a construir en los 4 minutos no tenía que ser el mismo que el numero de aviones que iba a pasar el test.

Y lo que es peor, nos pusimos a hacer aviones como locos, sin probar antes que alguno volase (Hola?? TESTEO!!), para en el caso de que no lo consiguiesen, introducir alguna mejora. Emma no nos había especificado que no podíamos cambiar los diseños, simplemente dimos por hecho que no podíamos hacerlo.
Seguir leyendo «Meetup de Juegos y dinámicas ágiles»

Elementos de un sistema de diseño

Seguimos con la serie de artículos de cómo crear un buen sistema de diseño, primero vimos por qué eran útiles y segundo las características de un buen sistema de diseño. Continuamos con este artículo sobre qué debe contener un sistema de diseño.

Como comenta el libro Lean UX, «Si está hecho de pixels va en el sistema de diseño«.

Todos los componentes, con la definición de su aspecto visual e interacción, el código necesario para insertarlo, sus clases, selectores, modificadores… deberían estar en el sistema.

iOS Design System

Ejemplo de Search Bars en el Sistema de Diseño para iOS

Qué aspecto visual tiene el elemento

Detalles sobre el tamaño mínimo y máximo, restricciones verticales u horizontales, color, estados (active, inactive, hover….)….

Dónde se coloca normalmente en la pantalla

Especifica claramente si un elemento sólo puede estar ubicado en ciertos lugares de la pantalla, así como posibles excepciones.

Seguir leyendo «Elementos de un sistema de diseño»

Arquitectura de la información

La arquitectura de la Información​ es la disciplina encargada del estudio, análisis, organización, disposición y estructuración de la información en espacios de contenidos y de la selección y presentación de los datos en los sistemas de información interactivos y no interactivos.

Fue definida por primera vez por Richard Saul Wurman en 1975 «El estudio de la organización de la información con el objetivo de permitir al usuario encontrar su vía de navegación hacia el conocimiento y la comprensión de la información«.

Arquitectura de la información

Ejemplo de AI con procesos asociados

En 1998, Morville y Rosenfeld, definen que «El arquitecto de información es la persona que debe identificar la misión (los objetivos) y la visión (las expectativas de los usuarios) de la pagina web, determinar los contenidos y funcionalidades de la página, facilitar el acceso mediante sistemas de organización, etiquetado, navegación y búsqueda y planificar en previsión de futuras modificaciones y crecimiento de la página.»

Garret, en 2003, propone una definición más amplia, alineada con la anterior. «Durante la fase de “estrategia” se deben identificar los objetivos, en la fase de “alcance” las necesidades de los usuarios, en la fase de “estructura” especificar las funcionalidades y requerimientos de la web, en la fase de “esqueleto” el diseño de los sistemas de navegación, organización, etiquetado y búsqueda y en la fase de “interfaz” prototipar la página.»

Para Morville y Rosenfeld, una buena arquitectura de información se sustenta en tres pilares: el contexto organizacional en el que se desarrolla, el contenido que alberga y los usuarios que la visitan y consultan (2006).

Y es que por ejemplo, no es lo mismo definir un etiquetado para usuarios con conocimientos técnicos avanzados sobre un tema, que para personas que no los posean.

De ello surgen muchos problemas en la definición de la AI de páginas gubernamentales o de salud, al ser términos no conocidos por los usuarios finales. Esto se puede preveer mediante sesiones de Card sorting o Tree Jack.

Gracias a pruebas con usuarios reales podemos confirmar si el mapa metal del usuario coincido con el planteado en la AI.

Listado de artículos interesantes sobre la arquitectura de la información:

¿Buscar trabajo o encontrar una pareja? Es más parecido de lo que crees!

Hablando con un Sergio (@delacasa), salió el tema en plan broma, pero luego me quedé pensando y me pareció que valía la pena profundizar un poco más y hacer escribir sobre ello. Y es que aunque no lo parezca, elegir un (buen y estable) trabajo es igual de complicado que encontrar una (buena y estable) pareja.

Esta claro que podemos estar solos, pero al ser humano le gusta la compañía y aparte de satisfacer ciertas necesidades, a muchos, nos gusta compartir nuestra vida con una persona especial.

Buscar trabajo

Lo mismo ocurre con el trabajo. A no ser que partas con cierta ventaja económica, tal y como esta planteado el mundo en el que vivimos, necesitamos dinero para vivir y satisfacer nuestros deseos. Osea que no queda más remedio que trabajar.

Y ambas uniones para que sean duraderas deben cumplir las necesidades de ambas partes y evolucionar al mismo ritmo.

Por lo que… ¿quién es esa persona/empresa indicada que quiera compartir su vida conmigo?

Caso 1: No tienes donde elegir (o lo que a ti te interesa, no le gustas)

Si lamentablemente no tienes mucho donde elegir, no te comes mucho la cabeza. Te quedas con lo que hay en ese momento en el mercado, y/o te contentas con lo que has conseguido e intentas ser feliz o intentas ir mejorando con el tiempo.

En el tema personal, vas al gimnasio a ponerte en forma, te compras nueva ropa… o si lo trasladamos al mundo laboral, buscas formarte más, apuntándote a cursos o leyendo blogs.

Seguir leyendo «¿Buscar trabajo o encontrar una pareja? Es más parecido de lo que crees!»

Scroll hacia arriba