Archivo de la etiqueta: Personas

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.

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.

El lío viene cuando nos metemos en el tema de certificaciones.

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

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.

Es un estándar, que se basa en procesos, y que describe el trabajo que se debe hacer en cada uno de ellos, reconocido como Global ANSI (American National Standards Institute) Standard.

Otros estándares de gestión son la norma ISO 9000 y CMMI (Capability Maturity Model Integration).

PMI® (Project Management Institute)

El PMI® es una organización estadounidense, fundada en 1969, sin ánimo de lucro que asocia a profesionales relacionados con la Gestión de Proyectos.

En los 80 se realizó la primera evaluación para la certificación como profesional en gestión de proyectos implantándose además un código de ética para la profesión. La primera edición de la Guía del PMBOK® (Project Management Body of Knowledge) se publico a principios de los 90 la cual se convirtió en un pilar básico para la gestión y dirección de proyectos

El PMI® gestiona el Comité Técnico de Gestión de Proyectos y Programas ISO/TC 258, en nombre de la  American National Standards Institute (ANSI).

A día de hoy, es la entidad más grande del mundo como referencia sobre Project Management,  con 450.000 integrantes en casi 100 países.

The Scrum Framework

SCRUM, por su parte es una metodología 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.

Igual que SCRUM encontramos otras metodologías ágiles como:

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

Más información

ISO 9000 es un conjunto de normas sobre calidad y gestión de calidad, establecidas por la Organización Internacional de Normalización (ISO). Las organizaciones que la poseen se comprometen a trabajar bajo esos estándares de calidad, tiempos de entrega y niveles de servicio.
CMMI o Capability Maturity Model Integration es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software. Las organizaciones no pueden ser certificadas CMMI. Al contrario, cada empresa adopta las prácticas CMMI en función de sus objetivos de negocio.

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

Resúmenes del UXSpain 2017

Tiempo de lectura: 1 minuto

Pues nada, ya llego la fecha y aquí estamos en Gijón comenzando el UXSpain:

Os dejo los resúmenes de las charlas que vaya documentando:

Espero que os gusten!

A veces es muy complicado escuchar, tomar apuntes, twuittear, leer tweets 😉 por lo que si hay alguna errata en los resúmenes, estaré encantada de corregirla.

Decisiones personales: dejar un trabajo nunca es fácil

Tiempo de lectura: 2 minutos

El final del 2016 ha sido bastante movidito. Tomar la decisión de dejar un trabajo donde estás bien valorada, existe un ambiente genial entre los compañeros y el equipo, tienes un horario decente, trabajas en pleno centro de la ciudad… es un momento muy, muy, MUY difícil.

Decidir dejar un trabajo nunca es fácil

Abandonar esa seguridad, ese sueldo seguro cada mes (sea mejor o peor), por algo que sientes dentro de ti, sin tener nada en la otra mano, sin saber cual es el siguiente paso, no es fácil. Y seguramente, si tienes ciertas responsabilidades personales, ni te lo planteas. Ni te atreves a pensarlo.

Pero bueno, después de estar 3 meses sopesando pros y contras, venciendo ese miedo interior, sintiéndote mal simplemente por pensar en ello, por querer dejar algo que tiene unas condiciones tan buenas, por haber puesto demasiadas expectativas en ello y no estar contenta con lo que tienes en ese momento, te lanzas. Y lo haces.

Porque cuando dejas tu un trabajo sin tener otro esperando, la gente te dice que estas loca. ¡Y sin paro! ¿Pero qué vas a hacer ahora? Pero, ¿en serio? Si es una empresa tan buena… ¿Con la seguridad que tenías ahí?

Son los comentarios que sueles oír.

Comentarios que no te ayudan. Que se suman a tu mar infinito de dudas.

La cosa cambia cuando te despiden, ya que aunque no sea nunca algo agradable no tienes poder de decisión. Es una situación donde seguramente no puedas hacer nada. Eres una pieza que alguien mueve, y seguramente en la mayoría de los casos, es algo que no se desea.

Has luchado por tu trabajo, lo has intentado hacer lo mejor posible, y ya sean motivos externos o internos, de repente te pasa esto. Y en muchas ocasiones esos despidos cambian la vida de una persona, de una familia, a una situación precaria y no deseada.

Razón de más para sentirte mal de dejar un trabajo por voluntad propia cuando muchas personas les ocurre lo contrario.

Tomar decisiones y no que las tomen por ti es lo difícil

Entiendo que cada persona tiene su situación personal, pero lo que quería resaltar es que tomar decisiones y no que las tomen por ti es lo realmente complicado del asunto. Y más cuando son decisiones que pueden cambiar tu vida. Decisiones que pueden ser erróneas y que no tienen marcha atrás.

Pero sientes que algo te impulsa a hacerlas, que no te deja dormir, que por muchas vueltas que le des y muchos pros y contras que hagas sigues pensando igual, y lo haces. Y te lanzas a ese vacío, a ese camino invisible que aun no sabes por donde va a ir…

Pero eso es la vida. Y es muy corta. Por lo que hay que intentar realizar un trabajo donde la motivación sea máxima, donde sigas aprendiendo constantemente con nuevos retos que resolver, donde te sientas orgullosa de lo que haces.

UX Academy: We can be heroes

Tiempo de lectura: 1 minuto

Juan Moyano inaugura la temporada de UX Academy tras el parón de agosto con su charla “We can be heroes”.

Y es que como nos cuenta Juan, tenemos que aceptar la realidad, ya que no existe el cliente perfecto… ni el proyecto, ni el socio, ni el jefe, ni el equipo, ni la metodología, ni la tecnología, ni el diseño, ni la experiencia. Ni el usuario…

Y por supuesto, nosotros tampoco lo somos.

Pero podemos dejar de quejarnos y empezar a probar otros modelos de trabajo en busca de mejores resultados.

Juan Moyano en UX Academy

Moyano compartirá una reflexión personal, sobre dónde se encuentra, en su opinión, la clave para luchar por conseguir los mejores resultados posibles en el diseño de experiencia de usuario.

Si te interesa, apúntate al Meetup. Será el próximo miercoles 28 de septiembre a las 19:00 en las bonitas oficinas de Flywire, en el centro de Valencia. Después nos quedaremos charlando y tomando algo cortesía de Flywire.

¿Quieres saber más sobre Juan?

Con más de 10 años de experiencia desarrollo de soluciones Web, ha sido ponente además del III Encuentro nacional de diseño de experiencias e innovación (ExperienceFighters.com.

Gamificación, apps educativas y profesionales para el bienestar de las personas

Tiempo de lectura: 2 minutos

El día 5 de julio asistí a una una mesa redonda en Las Naves donde se discutía el tema: “Gamificación, aplicaciones educativas y profesionales para el bienestar de las personas” organizado por la Fundación Inndea Valencia .

Se presentaron diferentes aplicaciones educativas y proyectos de investigación realizados por parte de los ponentes en torno a la gamificación mediante diferentes herramientas: realidad virtual, realidad aumentada, videojuegos…

Los ponentes por orden de actuación fueron:

  • José Martí-Parreño, Director del Máster Universitario en Formación del Profesorado. Universidad Europea de Valencia
  • Mª Carmen Juan, Catedrática de Universidad. Instituto ai2. UPV
  • Juan Peralta, Flynns Arcade. Profesor en Florida Replay
  • Jaime Torres y Gustavo Aranda, de la ESAT (Escuela Superior de Arte y Tecnología)

En muchos casos, en los proyectos presentados, se había contrastado si era beneficiosa la introducción de las nuevas tecnologías y la gamificación, estableciendo una correlación entre el nuevo sistema y los métodos más tradicionales.

La gamificación mejora la experiencia de aprendizaje

Tanto Mº Carmen como Jose Martí-Parreño habían llegado a conclusiones similares, donde la gamificación no conseguía que el usuario aprendiera más, pero si que mejoraba gratamente la experiencia de aprendizaje.

En uno de los casos, en concreto al realizarse la prueba en grupo, si que se habían notado mejoras frente al medio tradicional.

ARBreakfast

Entre los proyectos presentados, destacar “ARBreakfast”, una aplicación desarrollada por un equipo de investigadores del Instituto Universitario de Automática e Informática Industrial de la Universitat Politècnica de València (ai2-UPV),
donde la realidad aumentada (RA) se usaba como método educativo terapéutico en pacientes con diabetes.

ARBreakfast Apps gamificacion

La idea es que los niños aprendan que alimentos o conjuntos de alimentos pueden comer en su desayuno, y en alguno tipos de diabetes, llegando a conocer además a cantidad de insulina tienen que administrarse en cada caso.

Sigue leyendo Gamificación, apps educativas y profesionales para el bienestar de las personas