Formación específica para la preparación de la certificación de PMP

La importancia del Product Owner en Scrum

La importancia del Product Owner en Scrum

Introducción al Rol del Product Owner

El Product Owner (PO) es una figura clave en la metodología Scrum, desempeñando un papel esencial en la definición de la visión del producto y asegurando que el trabajo del equipo de desarrollo aporte el mayor valor al negocio.

Responsabilidades Clave del Product Owner

1. Definir la Visión del Producto

El PO establece y comunica una visión clara del producto, asegurando que el equipo entienda y comparta los objetivos a largo plazo.

2. Gestión de la Backlog

El PO prioriza y mantiene la lista de tareas (Product Backlog), asegurando que el equipo se enfoque en el trabajo que maximiza el valor del producto.

3. Colaboración con Stakeholders

Asegura una comunicación efectiva entre el equipo Scrum y las partes interesadas, recopilando feedback y alineando expectativas.

4. Toma de Decisiones

Toma decisiones informadas y oportunas sobre el producto, considerando las necesidades del negocio, el feedback del cliente y la capacidad del equipo.

5. Asegurar la Entrega de Valor

El PO es responsable de asegurar que el equipo de desarrollo entienda los requisitos y entregue las funcionalidades que aportan el mayor valor al negocio.

Habilidades Clave del Product Owner

1. Liderazgo y Visión Estratégica

Capacidad para dirigir el producto hacia la visión a largo plazo y asegurar que cada iteración aporte valor al negocio.

2. Comunicación Efectiva

Habilidad para comunicarse con claridad con el equipo Scrum y las partes interesadas, articulando necesidades y expectativas.

3. Capacidad de Negociación

Aptitud para equilibrar las demandas de diversas partes interesadas y tomar decisiones que beneficien al proyecto en su conjunto.

4. Conocimiento del Mercado y del Producto

Comprensión profunda de las necesidades del cliente y del mercado para guiar el desarrollo del producto efectivamente.

Desafíos del Product Owner

El PO enfrenta desafíos como equilibrar las necesidades de diversas partes interesadas, priorizar el trabajo bajo limitaciones de tiempo y recursos, y mantener una comunicación efectiva con el equipo de desarrollo y los stakeholders.

Conclusión y Llamado a la Acción

El rol del Product Owner es crucial para el éxito de cualquier proyecto que siga la metodología Scrum. Si estás buscando mejorar las habilidades de tu Product Owner o necesitas orientación en la adopción de Scrum, en Gestión Proyectos estamos aquí para ayudarte. Ofrecemos formación, asesoramiento y soporte para asegurar que tu Product Owner y tu equipo maximicen su potencial. Contáctanos hoy y da el primer paso hacia la excelencia en la gestión de productos con Scrum. ¡Tu proyecto merece un Product Owner que realmente haga la diferencia!

El rol del Scrum Master: Responsabilidades y habilidades clave.

El rol del Scrum Master: Responsabilidades y habilidades clave.

Introducción al Rol del Scrum Master

El Scrum Master juega un papel crucial en la implementación de la metodología Scrum en cualquier equipo o proyecto. No es solo un miembro del equipo, sino un líder servicial, facilitador y coach para el resto del equipo Scrum.

Responsabilidades Clave del Scrum Master

1. Facilitador de Procesos

El Scrum Master asegura que el equipo sigue las prácticas y reglas de Scrum, facilitando las ceremonias y manteniendo el orden y la estructura.

2. Coach Ágil

Ayuda al equipo a comprender y aplicar Scrum y principios ágiles, promoviendo un entorno de mejora continua.

3. Protector del Equipo

El Scrum Master protege al equipo de distracciones e interrupciones, asegurando que puedan concentrarse en las tareas del sprint.

4. Intermediario y Comunicador

Facilita la comunicación entre el equipo y las partes externas, asegurando que el flujo de información sea constante y claro.

5. Promotor de Cambios

El Scrum Master ayuda a la organización a adoptar Scrum, trabajando para cambiar la cultura y las prácticas existentes.

Habilidades Clave del Scrum Master

1. Liderazgo Servicial

Capacidad para guiar y servir al equipo sin necesidad de autoridad jerárquica.

2. Comunicación Efectiva

Habilidades para comunicarse claramente y escuchar activamente a los miembros del equipo y a las partes interesadas.

3. Resolución de Conflictos

Capacidad para identificar y resolver conflictos dentro del equipo de manera efectiva y empática.

4. Adaptabilidad

Habilidad para adaptarse a cambios rápidos y ayudar al equipo a hacer lo mismo.

5. Conocimiento Profundo de Scrum

Comprensión completa de las prácticas, teorías y técnicas de Scrum.

Desafíos del Scrum Master

Ser un Scrum Master efectivo implica enfrentar desafíos como resistencia al cambio, malentendidos sobre el rol y mantener el equilibrio entre guiar y permitir la autonomía del equipo.

Conclusión y Llamado a la Acción

El Scrum Master es más que un rol; es la piedra angular que mantiene el proyecto en movimiento, asegurándose de que el equipo Scrum esté en su máxima capacidad. Si buscas mejorar tus habilidades como Scrum Master o necesitas un profesional calificado para guiar a tu equipo, en Gestión Proyectos tenemos los recursos y la experiencia que necesitas. Contáctanos hoy para empoderar a tu equipo y maximizar la eficacia de tu proyecto con un Scrum Master experto. ¡Juntos, podemos llevar tu proyecto al siguiente nivel!

certificaciones pmi

El nuevo examen de PMP®

Los cambios en el examen de PMP®

Hemos recibido muchas consultas sobre los cambios en el examen de Certificación PMP®  a partir de este 2 de enero de 2021. por lo que voy a intentar contar en este post en qué consisten estos cambios y como podemos adaptarnos en caso de que hayamos estudiado con la versión anterior del examen.

En primer lugar, la buena noticia: todo lo que has estudiado hasta ahora sigue vigente y sigue siendo aplicable al nuevo examen, por lo que, si ya lo estudiaste pero no llegaste a hacer el examen,  no has perdido el tiempo ni has hecho un esfuerzo en vano. La noticia “no tan buena” es que los contenidos se amplían y, además de los contenidos anteriores, ahora necesitarás incluir otros nuevos.

Seguimos con la 6ª Edición de la PMBOK Guide®

El nuevo examen de PMP® sigue basándose en la 6ª edición de la PMBOK Guide® (la 7ª edición no está previsto que se publique hasta mediados de este año aproximadamente y, como el PMI® siempre deja un periodo de adaptación, no es previsible que se empiecen a aplicar los cambios de la 7ª edición hasta el primer trimestre de 2022). Eso sí, la 7ª edición de la PMBOK Guide® supondrá una gran revolución a nivel de contenidos. Por ejemplo, ya no se hablará de “procesos”, sino de 12 “principios” y no se hablará de “áreas de conocimiento” (actualmente son 10), sino de 8 “dominios”. Por tanto, si estás pensando en certificarte como PMP®, nuestro consejo es que empieces a prepararte lo antes posible, para que puedas examinarte antes de estos cambios. Aquí puedes ver información sobre nuestro curso preparatorio y fechas disponibles.

Pero volvamos a la versión actual del examen, vigente desde el 2 de enero de este año:

¿Cuáles son los principales cambios? ¿Es ahora más difícil el examen?

Los cambios aplican en dos sentidos:

  • A nivel de contenidos, con el nuevo “Exam contet outline” (ECO)
  • A nivel de formato del examen
El nuevo ECO

El nuevo examen content outline nos muestra que el examen dará mucho más peso del que se estaba dando hasta ahora a dos ítems: people y business enviromnet. Según el ECO, las preguntas se distribuirán según los siguientes porcentajes:

  • Process: 50%
  • People: 42%
  • Business Envorinment: 8%
Gestión predictiva y ágil

Por otra parte, otro cambio fundamental, es que ahora el examen se basará en un 50% en la gestión predictiva y otro 50% en el marco de trabajo ágil o modelos híbridos.

A nivel práctico, esto significa que no será suficiente basarnos en la PMBOK Guide® (que cubre perfectamente toda la parte de los procesos) sino que, necesariamente, tendremos que recurrir a otras fuentes. Si bien el PMI® siempre ha dicho que la PMBOK Guide ® no era la única guía de referencia para preparar el examen, el hecho es que hasta ahora el examen se aprobaba basándonos fundamentalmente en dicha guía. Ahora, en cambio, será imprescindible incluir en el estudio la “Agile Practice Guide®” y recomendable revisar alguna otra bibliografía (la propia guía ágil incluye otra bibliografía recomendada).

El formato del examen

Los cambios principales del nuevo examen son:

  • Ya no hay 200 preguntas, sino 180. Como en la versión anterior, no todas las preguntas puntúan, ya que el PMI® introduce en el examen cierto número de preguntas “de prueba”, cuya calificación no computa. Pero, como no sabremos cuáles son esas preguntas, hay que responderlas todas.
  • La duración del examen es de 230 minutos en lugar de los 240 anteriores, con dos pausas (opcionales) de 10 minutos.
  • Ya no serán todas las preguntas tipo test con una única respuesta correcta, sino que se introducen otras opciones como multiple-choice, multiple responses, matching, hotspot and limited fill-in-the-blank.

Puedes ver más información sobre todo esto en la propia página del PMI®.

¿Significa esto que el examen será ahora más difícil? Nosotros creemos que no necesariamente. Por experiencia, sabemos que el examen hasta ahora podía complicar mucho el enunciado de las preguntas. Entendemos que esto puede pesar más en la dificultad del examen (incluso en la velocidad de respuesta para cada pregunta) que el hecho de que la pregunta se formule de una u otra forma. Teniendo los concetos claros, creemos que cierto tipo de preguntar podrán ser, incluso mas sencillas planteadas en los nuevos formatos. La experiencia nos lo irá diciendo (con el nuevo formato recién estrenado aún tenemos poco feedback de los alumnos), y sin duda, os lo iremos contando.

CAMBIOS EN EL EXAMEN PMP® DEL PMI®: Se retrasa la fecha al 1 de julio de 2020.

El PMI® acaba de anunciar que os cambios en el examen no empezarán a aplicarse hasta el 1 de julio de 2010.

Tras la actualización a la 6ª ediicón de la Guía PMBOK®, y la correspondiente actualización en los cambios en el examen, el PMI® había anunciado un nuevo cambio en los contenidos del examen a partir del 15 de diciembre de 2.019.

Sin embargo, tras la abrumadora respuesta de las consultoras de formación, especialmente de los que estamos acreditados como Registered Education Provider (REP), demandando más información respecto a la manera de adaptar nuestros contenidos a los cambios y, sobre todo, más tiempo para poder hacerlo, el PMI® ha decidido posponer el cambio en el examen hasta el 1 de julio de 2020.

Por tanto, tanto las consultoras de formación como nuestros alumnos, sentimos un cierto alivio, y esperamos que este aplazamiento sirva para que el PMI® facilite más información y recursos para que podamos adaptar nuestros materiales a los nuevos contenidos, para tener así la seguridad de que serán los contenidos adecuados para la preparación del nuevo examen. Queremos, como hasta ahora, ofrecer a nuestros alumnos un material de la máxima calidad.

En todo caso, a falta de más información, sí conocemos ya por dónde van a ir los cambios, según el nuevo Exam Content Outline 2020 que ha publicado el PMI®:

  • Si el anterior Exam Content Outline, de 2015 se organizaba en base a los 5 grupos de procesos (inicio, planificación, ejecución, monitoreo-control y cierre), el nuevo se organiza en base a tres dominios:
    • Personas: 42% de peso en el examen
    • Procesos: 50% de peso en el examen
    • Estrategia/entorno de negocio: 8% peso en el examen
  • Sin embargo, lo que supone un mayor cambio es que, en el nuevo examen, los modelos ágiles e híbridos tendrán un peso de aproximadamente el 50%. La última versión de la Guía PMBOK®, apenas introduce algunas ideas sobre estos modelos, por lo que parece que, como mínimo, habrá que incluir también en el estudio la «Guía práctica de ágil» que ha publicado el PMI®, junto con la «Agile Alliance».  

Esperamos, por tanto, tener más información detallada en los próximos meses, para actualizar los contenidos. Mientras tanto, respiramos aliviados con la prórroga hasta julio de 2020 y seguimos recomendando a nuestros alumnos que, siempre que les sea posible, se examinen con la versión actual del examen, ya que todo indica que la nueva versión va a suponer una mayor carga de contenidos y, por tanto, una mayor esfuerzo y tiempo de dedicación.

¡Afortunadamente, contamos con 10 meses más para poder hacerlo!. 

catalogo servicios

COACHING PARA CONSEGUIR TUS PROPÓSITOS

¿Te cuesta concretar tus objetivos? ¿Tienes claro lo que te gustaría, pero no sabes cómo llevarlo a la práctica? 

Ahora que el verano termina, nos acercamos a ese momento de los «buenos propósitos» en el que, nuevamente, retomamos esos planes que llevamos tiempo posponiendo. Pensamos que esta vez será la definitiva, y nos hacemos una lista de esas tareas que siempre tenemos «por hacer», con el convencimiento de que, esta vez sí, las pondremos en marcha. Sin embargo, como dijo Einstein «locura es hacer la misma cosa una y otra vez, esperando obtener resultados diferentes».

«De acuerdo»- pensarás – «Se dice muy fácil». «Debo hacer algo distinto… pero ¿qué? Si lo supiera, ya lo habría hecho….»

Si tengo claro que quiero hacer algo, ¿por qué no lo consigo? ¿por qué, año tras año, llega diciembre y me doy cuenta de que sigo donde estaba y de que el trabajo y los demás deberes cotidianos han consumido todo mi tiempo y no he hecho lo que QUERÍA  hacer?

En primer lugar,  te diré que proponerse una tarea ya es un primer paso y, además, muy importante. Si no estás dispuesto a dejarte llevar, si tienes una ilusión, si quieres algo más, pero no sabes cómo darle forma, participar en un proceso de coaching puede servirte de ayuda para salir de donde estás.

Estas son algunas de las «causas» que, a menudo,  nos impiden avanzar en nuestros propósitos. ¿Te sientes identificado con alguna?:

No tener claramente definido un objetivo: A veces tenemos claro «lo que no queremos», lo que no nos gusta, pero no sabemos definir dónde queremos llegar. Tenemos un sueño difuso, una idea abstracta, o simplemente tenemos un malestar, no nos sentimos a gusto, pero no sabemos por qué.
No ser consciente de la realidad: Normalmente, creemos tener clarísimo lo que hacemos e, incluso, el por qué. Sin embargo, es sorprendente la cantidad de cosas que hacemos sin darnos cuenta, las conductas repetitivas y los pensamientos inconscientes que están boicoteando nuestro objetivo. Es necesario sacarlos a la superficie, porque sólo desde la consciencia se podrán cambiar.
Adoptar los objetivos de otros: A veces «nos imponemos» objetivos a nosotros mismos . Pero, ¿de verdad queremos cumplir lo que nos hemos propuesto? Te invito a que te preguntes si TIENES QUE hacerlo o si QUIERES hacerlo. Si tu objetivo no es suficientemente motivador para tí, si no te seduce lo suficiente como para vencer las resistencias e, incluso, los temores, seguirás anteponiendo cualquier otra tarea.
Falta de confianza: si no sientes que puedes cumplirlo, dificilmente lo harás. Según las palabras atribuidas a Henry Ford, «si crees que puedes, tienes razón. Si crees que no puedes, también tienes razón».
No quieres asumir la responsabilidad: Es cierto, a veces conseguir lo que uno se propone, cuesta, hay que hacer un esfuerzo. ¿Hasta dónde estás dispuesto a poner de tu parte? ¿Qué precio estás dispuesto a pagar? ¿Qué pasará si no lo consigues? (Recuerda: ¡no hay fracasos, sólo aprendizajes!).
No sabes como hacerlo: a veces no nos permitimos ponernos objetivos porque no sabemos cómo cumplirlos. «Como no se cómo hacerlo, lo ignoro y hago como si no lo quisiera». Sin embargo, ésto, raramente se consigue y, normalmente, eso que no hemos cumplido nos persigue en forma de «tarea pendiente»…

La lista podría ser interminable… ¿Te sientes identificado con alguna ellas? Si es así, te invito a que valores realizar un proceso de coaching. Podemos cerrar una primera sesión exploratoria gratuita, en la que explicarte, con todo detalle, como funciona el proceso, y resolver todas tus dudas.

¡Ponte en marcha y el destino actuará en tu favor! ¿Te atreves?

 

Fechas de publicación PMBOK® 6ª edición y actualización Examen PMP®

Nuevo Examen PMP® con PMBOK® 6ª edición: desde el 26 marzo 2018

Ya se ha anunciado por parte del PMI® (Project Management Institue) las fechas oficiales de la renovación de tres de sus estándares (Gestión de Programas, Gestión de Portafolio y Análisis de Negocio), además de las fechas de actualización de la Guía PMBOK ® (6ª Edición) y la publicación de la Guía Práctica Ágil.

Publicación Liberación versión PDF Liberación Versión Impresa Actualización Examen
Guía PMBOK® 6ª Edición Septiembre 2017 Septiembre 2017 26/marzo/2018(PMP®)

21/mayo/2018 (CAPM®)

Guía Práctica Ágil Septiembre 2017 Septiembre 2017  26/marzo/2018(PMI-ACP)®
Estándar para la Gestión de Programas –4ª Edición Q3 2017 Q4 2017 Q1 2018 (PgMP)®
Estándar para la Gestión de Portafolios – 4ª Edición Q4 2017 Q4 2017 Q2 2018 (PfMP)®
Guía PMI para el Análisis de Negocio Q4 2017 Q4 2017 Pendiente (PMI-PBA)®

Podemos ver los cambios propuestos a nivel de áreas de conocimiento y procesos de gestión en esta tabla:

ÁREAS DE CONOCIMIENTO GRUPOS DE PROCESOS de Gestión de Proyectos
INICIACIÓN (2) PLANIFICACIÓN (24) EJECUCIÓN (10) MONITORIZACIÓN Y CONTROL (12) CIERRE (1)
4. Gestión de Integración del proyecto 4.1 Desarrollar Acta Constitución del Proyecto 4.2 Desarrollar Plan de Dirección del Proyecto 4.3 Dirigir y Gestionar el Trabajo del Proyecto

4.4 Gestionar el conocimiento del Proyecto (Manage Project Knowledge)

4.5 Monitorear y Controlar el Trabajo del Proyecto

4.6 Realizar Control Integrado de Cambios

4.7 Cerrar Fase o Proyecto
5. Gestión de Alcance del proyecto   5.1 Planificar  Gestión de Alcance

5.2 Recopilar Requisitos

5.3 Definir Alcance

5.4 Crear la EDT

  5.5 Validar Alcance

5.6 Controlar Alcance

 
6. Gestión de la programación/cronograma del proyecto   6.1 Planificar  Gestión del Cronograma

6.2 Definir Actividades

6.3 Secuenciar Actividades

6.4 Estimar Duración Actividades

6.5 Desarrollar Cronograma

  6.6 Controlar el Cronograma  
7. Gestión de Costes del proyecto   7.1 Planificar gestión de Costos

7.2 Estimar Costos

7.3 Determinar Presupuesto

  7.4 Control de Costos  
8. Gestión de Calidad del Proyecto   8.1 Planificar Gestión de Calidad 8.2 Gestionar la calidad (manage quality) 8.3 Control de Calidad  
9. Gestión de Recursos del Proyecto   9.1 Planificar  Gestión de Recursos

9.2 Estimar Recursos de actividades

 

9.3 Adquirir recursos

9.4 Desarrollar el Equipo de Proyecto

9.5 Dirigir el Equipo de Proyecto

 9.6 Controlar Recursos  
10.Gestión de Comunicaciones   10.1 Planificar Gestión de Comunicaciones 10.2 Gestionar Comunicaciones 10.3 Controlar Comunicaciones  
11.Gestión de Riesgos   11.1 Planificar gestión de Riesgos

11.2 Identificar Riesgos

11.3 Análisis Cualitativo de Riesgos

11.4 Análisis Cuantitativo de Riesgos

11.5 Planificación de Respuesta Riesgos

 11.6 Implementar respuestas de riesgos 11.7 Monitorizar Riesgos  
12.Gestión de Adquisiciones   12.1 Planificar Gestión de Adquisiciones 12.2 Realizar Adquisiciones  12.3 Controlar Adquisiciones  
13.Gestión de los Interesados 13.1 Identificar Interesados 13.2 Planificar Gestión de Interesados 13.3 Gestión Compromiso(engagement)  de los Interesados 13.4 Monitorizar el compromiso de los Interesados  
user story mapping 2

Mapa de historias de la gestión de proyectos: aplicación de una técnica ágil en un escenario tradicional

El mapa de historias de usuario- Jeff Patton (http://jpattonassociates.com/user-story-mapping/)  es una técnica ágil que permite trabajar con una de las mayores problemáticas que aparece en la construcción de aplicaciones y productos tecnológicos software : la elaboración de documentación compartida no genera entendimiento compartido. Un ejemplo tradicional y común: definir y analizar los requisitos de cómo queremos que funcione una determinada aplicación y plasmar los resultados de reuniones, entrevistas, encuestas,… que podamos realizar con todos los interesados clave, en diferentes tipos de documentación como documento de requisitos alto y bajo nivel, casos de uso, diseño de arquitectura, patrones,….

Todo parece ir bien al inicio del proyecto, dónde existe un alineamiento entre todos los participantes o al menos esa es la impresión. Pero una vez que ya estamos obteniendo resultados de los requisitos definidos nos damos cuenta que esa sinergia inicialmente consensuada no lo es tanto en absoluto, y empezamos a ser conscientes que tenemos un entendimiento diferente en nuestras cabezas.

Este es un ejemplo de cuantas veces ocurre que lo que inicialmente interpretamos como una meta conjunta y consensuada, cuando empezamos a trabajar, nos damos cuenta que estábamos pensando cosas completamente diferentes.

user story mapping 2

 

 

 

 

Fuente: www.comakewith.us, Jeff Patton

El mapa de historias de usuario trata de mitigar el riesgo de este escenario a través de la gestión visual y la conversación. Por un lado, usa herramientas visuales como tableros físicos- posteriormente se puede llevar a un soporte digital si es necesario- y postits para trasladar el entendimiento que se va generando de lo que se quiere construir con la participación de todos los interesados clave, y además utiliza el modo de comunicación que tiene mayor probabilidad de éxito, la comunicación cara a cara con retroalimentación a través de la conversación continua entre todos los participantes, como base para la generación del entendimiento compartido.

Fuente: www.comakewith.us, Jeff Patton

Se trata pues de una técnica  ágil perfectamente utilizable no sólo por el motivo para el que se ideó, construir aplicaciones de software, sino en cualquier contexto que demande conseguir el entendimiento compartido más allá de los resultados que se muestran en la documentación a desarrollar.

En particular utilizamos la técnica para trabajar el mapa de historias de usuario de la gestión de proyectos de una organización. El mapa resultado dinámico y evolucionable, es el fundamento junto con el apoyo de otras técnicas para construir una nueva metodología para la gestión de los proyectos de dicha organización, que no parece por concepto algo «ágil».

Lo más importante no es el documento o documentos entregables como resultado del proceso de definición de la metodología de gestión de los proyectos, sino este propio proceso o camino en la búsqueda del entendimiento compartido, el empoderamiento en los propios involucrados para participar  en la construcción del cambio en la forma de trabajar de la organización, y establecer la base de un proceso de mejora continua mediante la inspección y adaptación conforme se vaya implementando la metodología inicialmente establecida para aprender  tanto de lo que funciona como de aquello que no genera los resultados esperados.

La técnica del mapa de historias de usuario en este contexto abarca el ciclo de vida global end-to-end de la gestión de proyectos para la metodología, que sería el “producto” a definir,  incluyendo la etapa de viabilidad pre-proyecto e incluso parte de la etapa del posible  traspaso al área de operaciones.

La técnica del mapa de historias de usuario comprende una serie de pasos a realizar, que de forma resumida serian:

1. Enmarcar: Qué se quiere hacer, Quienes participan y Por qué se quiere hacer. Antes de mapear, creamos una breve descripción del producto para enmarcarlo y contextualizar el mapa. Este paso inicial fundamental lo trabajamos con una técnica ideada por nuestro compañero Raúl Herranz: el diagrama WAGI (http://blog.utopicainformatica.com/2014/03/el-diagrama-wagi-o-diagrama-de-mangle.html ) que recopila a su vez de forma ingeniosa una serie de técnicas ya reconocidas en su utilidad como los 5whys y el GQM (Goal, Question, Metric), para ayudar a enmarcar un proyecto de coaching/asesoría de implementación de agile en una organización. Vuelve a ser un objetivo trabajar con gestión visual el entendimiento compartido, en nuestro caso para la pregunta ¿Por qué queremos una metodología de gestión de proyectos en la organización?.

Se trabaja en identificar los beneficios/objetivos que la organización pretende obtener, o problemática que se quiere resolver  con el producto “metodología de gestión de proyectos”, como seremos capaces de medir los logros pretendidos y quienes deben participar en el proceso y como deben hacerlo.

Es importante identificar cuáles son los diferentes usuarios que usaran el producto, y lo «electores» o clientes que “compraran” el producto, y para cada usuario y elector establecer el beneficio que pretende obtener de utilizar el producto.

A modo de ejemplo,  diferentes actores que participan en la gestión de proyectos y productos de una organización (con una nomenclatura estándar) podrían ser:

  • CEO/Presidencia (“comprador”)
  • Director/Gestor de proyecto
  • Dueño de producto(agile)
  • Miembro del equipo
  • Manager funcional
  • Cliente
  • Usuario
  • ….

Esto nos permitirá personalizar el “producto” metodología a las necesidades de cada rol y empatizar con todos los participantes. Se trata de crear el escenario de cada rol.

2. Mapear el Big Picture: Focalizarse en obtener la historia completa –think «mile-wide, inch deep»-: lo importante es cubrir todo el ciclo de vida de experiencia del usuario a través de las actividades y tareas de alto nivel que realiza y que cuentan la historia completa, formando el llamado backbone de nuestro mapa de historias.

user story mapping 3 

 

 

 

 

 

 

Fuente: www.comakewith.us, Jeff Patton

Un mapa de historias de usuario contiene dos importantes características “anatómicas”

  • El backbone de la aplicación/producto es la lista de actividades-grandes historias o metas- esenciales que la aplicación/producto soporta.
  • El walking skeleton es el producto que construimos que soporta el mínimo número de tareas necesarias a través del ciclo completo de la experiencia del usuario.

De forma generalista y resumida, para el desarrollo del backbone comenzamos con el usuario más crítico para el éxito del proyecto  e imaginamos un típico día en la vida del usuario con el nuevo producto. Mapeamos las acciones como tareas del usuario de izquierda a derecha.

A continuación identificamos las actividades del usuario, que son los grupos de tareas que trabajan juntas para soportar una meta común. Las actividades típicamente emergen después cierto tiempo transcurrido tras haber empezado a trabajar el mapa.

Después, se añaden los usuarios adicionales. Una vez hayamos pensado en el típico usuario del producto, podríamos trabajar con los otros tipos de usuario en nuestra historia. Continuamos modelando su historia de izquierda a derecha.

Para nuestro particular “producto” de la metodología de gestión de proyectos, como elemento de ayuda para plantear este nivel más alto del mapa de historias –backbone– podemos partir del marco propuesto por la guía de buenas prácticas en gestión de proyecto del PMBOK, que no es una metodología y que, en contra de creencias extendidas, no promulga un estricto apego a normas o documentación que no sean valiosas. A partir de PMBOK podemos construir tanto una metodología más predictiva aplicable a proyectos simples o complicados, como una metodología más ágil en escenarios de proyectos complejos (https://en.wikipedia.org/wiki/Cynefin_framework).

Tenemos pues el backbone identificado y establecido a través de las etapas de gestión propuestas en PMBOK: Estudiar la viabilidad del proyecto-esta no es formalmente PMBOK-, Iniciar el proyecto, Planificar el proyecto, Ejecutar el proyecto, Monitorizar y Controlar el proyecto y Cerrar el proyecto. Posteriormente podremos usar las diferentes áreas de conocimiento descritas en PMBOK para trabajar el mapa de historias en los diferentes niveles.

Hacer hincapié en que el mapa de historias de usuario puede reflejar de izquierda a derecha el posible orden cronológico de las acciones a realizar por los diferentes actores de la aplicación, aunque esta característica es posible que no siempre se cumpla o incluso que haya intercambios temporales para ciertas acciones.

Nuevamente para el caso de la gestión de proyectos, el propio planteamiento de la etapas de gestión implica cronología, si bien es cierto que es fundamentalmente en la etapa de planificación dónde se llevan a cabo procesos/ actividades con lógica temporal. Por ejemplo, se define/estima que se quiere construir a alto nivel, para después tratar de detallarlo- al menos el corto-medio plazo- y estimar cuanto tiempo  y dinero implica desarrollarlo.

3. Explorar: Se trata de rellenar el cuerpo del mapa de historias descomponiendo las grandes tareas/actividades del usuario en sub-tareas más pequeñas y detalladas, e idealmente obtener como segundo nivel el llamado walking skeleton, que representa la primera versión/release del producto metodología que pretende entregar el mejor producto posible con las restricciones temporales presentes. Es  la versión de funcionalidades más simple posible del producto que cubre el ciclo de vida completo del usuario a través de las actividades objetivo mostradas en el primer nivel del mapa –backbone-. Debe servir para validar el desempeño cuando se comience a implementar y ser  escalable, por ejemplo por tipo o tamaño de proyecto.

En esta fase podremos añadir tarjetas al tablero físico del mapa de historias, dividir una tarjeta en dos, re-escribir tarjetas y reorganizarlas. Usar esta fase para pensar en el «cielo azul» sin restringir sobre todas las posibilidades que aparezcan y para pensar en todo lo que podría ir mal y qué tendría que hacer el usuario para corregirlo. No preocuparse si las ideas están «fuera de alcance».

Jugar a: «no sería fantástico si…» para grandes ideas del producto. Investigar variaciones: ¿qué más podrían haber hecho los usuarios?

Seguir considerar  los otros usuarios: ¿Que podrían hacer otros tipos de usuario para alcanzar sus objetivos?

Añadir otros detalles del producto como herramientas de ayuda a la gestión del proyecto, reglas de negocio,…

Involucrar a otros: contar la historia de tu producto a otros para explicarles los usuarios y el uso. Encontrar agujeros en tu historia y la ayuda para cubrirlos. Ellos te pueden apuntar a áreas con riesgos o  que resulten caras de implementar.

4. Dividir en Versione/Releases viables: El mapa de historias pretende ser dinámico y poder evolucionar, así como implementar el producto metodología de gestión de proyecto resultante de forma gradual e incremental para ir midiendo los resultados y aprender a través de un proceso de mejora continua. Se trata pues de cortar el mapa en “versiones” de producto viables que dividan los usuarios y el uso del producto. Estas rebanadas forman una hoja de ruta incremental de las versiones-releases- del producto donde cada versión es una liberación de lo que se conoce como producto mínimo viable.

Es recomendable para cada release, describir los resultados que son objetivo e impacto esperado, y como contribuyen a la meta global descrita tras el paso 1 sobre  el por qué. Esto sirve de motivación para la construcción del producto.

Para cada release identificar la métricas clave de identificación de éxito del producto (forma parte también de la técnica wagi).Es la respuesta a la pregunta ¿Que podremos medir para determinar si este producto es exitoso?.

5. Estrategia de desarrollo/implementación: El mapa de historia también trata de reflejar en el eje vertical de arriba a abajo el criterio de importancia/necesidad en orden descendente de las historias conforme se van descomponiendo y detallando hasta un nivel apropiado.

El objetivo es cortar la primera release/versión del mapa, el “walking skeleton”, para permitir a la organización aprender rápidamente y evitar/mitigar riesgos de implementar toda una metodología y procesos asociados que no se vayan probando y midiendo el beneficio que se obtiene  o la problemática que se resuelve.

A partir de esta primera versión, avanzamos completando las principales funcionalidades, haciéndolas más ricas y más detalladas. Seguimos buscado las pruebas con los usuarios y recibiendo retroalimentación para ajustar el producto.

Con el desarrollo de los talleres de trabajo para construir el mapa de historias de la gestión de proyectos, se profundiza y adapta para considerar casuísticas como tipologías- interno, para terceros- y tamaño de los proyectos, orientaciones predictiva y ágil para la gestión,… que pueden conducir incluso a la generación de más de un mapa.

Como ejemplo ilustrativo del trabajo sobre el mapa hasta un segundo nivel (las historias que aparecen son ficticias y parciales pero sirven para mostrar el resultado de la técnica):

EjemploUMGP

apply pmp

Cómo acreditar la experiencia profesional exigida por el PMI

¿Cómo tengo que “demostrar” al PMI® que dispongo de la experiencia profesional que me exigen para poder optar al examen de PMP®? ¿Debo entregar un Certificado emitido por mi empresa? ¿Presento alguna documentación oficial?

Estas son algunas de las preguntas más repetidas por aquellos que se interesan por la certificación PMP®, hasta el punto de que algunos llegan a plantearse si optar o no a ella, temiendo no poder, llegado el momento, demostrar la experiencia que tienen, que muchas veces excede por mucho la exigida.

Por ello, en este post, vamos a explicar cómo es el proceso de “Application”, en el que el candidato debe acreditar que cumple los siguientes requisitos:

  • 35 horas de formación en el ámbito de la gestión de proyectos (normalmente los cursos que preparan para este examen sirven a la vez para cumplir este requisito, emitiendo el correspondiente Certificado de realización)
  • Una determinada experiencia profesional:

a) 3 años de experiencia (4.500 horas), si tienes estudios universitarios.

b) 5 años de experiencia (7.500 horas) si no los tienes.

Bien, en el caso de que cumplas estos requisitos, ¿Cómo debes acreditarlos?

Para ello, debes cumplimentar tu application a través de la página web de PMI®. Para ello, debes crearte  un usuario con tus datos a través de su página www.pmi.org.

Una vez registrado, ya puedes presentar tu candidatura on line para la Certificación PMP®, registrando la información requerida. Primero, te pedirán los datos de tu nivel de estudios (básicos, universitarios, etc). A continuación, deberás acreditar dónde y cuando has realizado la formación en Gestión de Proyectos (recuerda que, si haces la formación con una empresa acreditada cono REP – Registered education Provider- tendrás la garantía de que será aprobada por el PMI®.

Hasta aquí, la parte “sencilla”.

A continuación, pasamos a detallar la experiencia profesional. Y no es que esto sea complicado ni difícil, pero si suele resultar una tarea laboriosa. Tendrás que ir introduciendo proyectos en los que hayas participado (en todo o en parte)- y que el total de estos proyectos sumen los 3 o 5 años requeridos. No es necesario que tu rol en estos proyectos haya sido “oficialmente” el de Project Manager o Jefe de Proyectos, pero si es importante que quede claro que has tenido un cierto grado de responsabilidad en los mismos, ya sea porque has gestionado los costes, has dirigido equipos de trabajo, has tenido que tratar directamente con el cliente, o ejercido alguna otra labor de responsabilidad.

Nunca te van a pedir que envíes ninguna información oficial de la empresa que acredite la veracidad de lo que has contado (contrato laboral, contrato del proyecto con el cliente, partes de trabajo, etc), simplemente tendrás que introducir una persona de contacto (o varias) que, en su caso, pueda acreditar lo que has reportado. Esta persona de contacto puede ser alguien que haya co-liderado contigo el proyecto, algún responsable o superior, alguna persona del departamento de Recursos Humanos de tu empresa, alguien de la empresa cliente, etc. El abanico es bastante amplio, y no importa que, en el momento en que haces tu application, esa persona o personas ya no trabajen en esa empresa o, incluso, se hayan jubilado.

Y ya está: una vez finalizada la cumplimentación de tu solicitud de elegibilidad, le das a “enviar”, y el PMI® te responderá en 5 días laborables.

Como ves, todo el proceso se hace a través de internet, sin aportar ninguna documentación.

Como sabrás, existe la posibilidad (estimada en un 15% aproximadamente), de que tu solicitud resulte seleccionada para pasar la “auditoría”. Existe la errónea creencia  bastante extendida de que las auditorías se deben a defectos en la application enviada. Sin embargo, no es así: las auditorías se comunican al interesado en el momento del pago de tasas de examen, es decir, con su application ya aprobada, y son totalmente aleatorias.

En nuestro próximo post comentaremos qué pasa si nos auditan, pero ya os adelanto que tampoco supone ningún problema, y que las auditorías se superan sin ninguna dificultad.

Aula virtual

Nueva política para el examen PMP®

Con carácter efectivo inmediato, PMI® y Prometric han decidido el siguiente cambio para el formato en el examen de las certificaciones del PMI®: No se permitirá tomar ninguna nota durante los 15 primeros minutos de tiempo correspondientes al tutorial del examen. La nueva política explicita del PMI® para el examen PMP®:

  • Los candidatos que realizan el examen podrán comenzar a utilizar las hojas para notas/apuntes una vez que el examen haya comenzado oficialmente.
  • Realizar un “volcado de memoria” durante el tutorial de 15 minutos o incluso previo, ya no está permitido.
  • Todas las hojas de papel utilizadas durante el examen serán recogidas a la finalización del mismo.

Esta nueva política parece indicar que ya no se permite usar un “volcado de memoria”, pero lo único que refleja es que ya no se puede hacer durante los 15 minutos del tutorial del examen. Se puede esperar hasta que el examen haya comenzado oficialmente y una vez que esto ocurra, y no antes, se puede escribir el volcado de memoria. El impacto obviamente es que se resta tiempo de dedicación a resolver preguntas del examen, y si tu preocupación es si el tiempo- 4 horas– es suficiente para responder a las 200 preguntas, puede ser que valores no realizar el volcado.

Por lo tanto, la principal conclusión de la nueva política es que hay que decidir si dedicar o no un tiempo durante el examen a realizar este volcado de memoria, según las capacidades y preparación de cada uno. En todo caso como esta nueva política se acaba de publicitar, su exacta implementación podría variar de un centro examinador a otro, y es mejor preguntar antes de comenzar el examen:
¿Qué puedo escribir en las hojas de apuntes y cuando puedo empezar a escribir?

Recordar también que un volcado de memoria no es más que un apoyo al examen PMP®, pero no te va hacer aprobarlo o no pasarlo.

PMP2

Best TIPS for the PMP Exam

The PMP® exam has a lot of situational questions, i.e. we should answer many questions about the real behavior in project management so we need to figure out and try to identify «What is the best thing you could do«, «What is following action to do…» or «You therefore…» .

We must therefore assume that certain «conditions» are being fulfilled in such situations, for example: We assume that we are integrated in a large project in different locations and with a multi-cultural international team. Our projects are always of high-cost, long-term and many resources.

Sometimes, especially when we have spent so much time in the PMP exam – 4hours- and we are tired or there are big questions, it may be a good option/approach to read first the possible answers and then read the question. In this manner we got a better approach into the question and it is easier eliminating the superfluous in the same time of the reading of the paragraph.

tips examen PMP

Let us look at this example:

You are in the early stages of a project to assemble a new optical telescope with a segmented mirror of more than 10 meters of diameter. You need a number of engineers including ones with specialties in mechanical, environmental, and systems engineering. In the early stages of this project, your resource pool includes a large number of both junior and senior engineers in the various specialty areas. However, as the project progresses—
a. Fewer systems engineers will be needed
b. The resource pool can be limited to those people who are knowledgeable about the project
c. To complete the project on time, you will continue to require access to a large number of engineers in their specialty areas
d. You will only need junior level engineers as the senior level people can be used early in the project to mentor and train them

First we are going to read the last paragraph of the question: «However, as the project progresses…», and then we read the four possible answers. The answers a. and d. are easily disposable in the first review because are focused on a «how-to» very specific. You should remember that the PMBOK® is a general guide for the project management profession
PMBOK® is a framework of good practice in project management but it is not a project management methodology.
We can understand that PMBOK® says «what» but not «how specific»: when an answer of the PMP® exam lead to think that «always «or «never » something should be done in a certain way we have to suspect that this is not the valid option. Responses that include «probably» or «frequently» will be better options.

The correct choice may be selected among the answers b. and c.

Now as we read the question from the beginning really should be easier for us identifying that the relevance of the question is indeed to know how to manage a pool of resources in a large-scale project in the most optimal way. In this case the best answer is b: The resource pool can be limited to those people who are knowledgeable about the project.
Resource calendars are an input to the estimate activity resource process and to the estimate activity durations process. They are used to estimate resource use. Early in a project, the resource pool might include people at different levels of expertise in large numbers, but as the project progresses, the resource pool then can be limited to those people who are knowledgeable about the project because of their work on it. [Planning]