#004 Gestión Ágil e Interesados

Primera Pregunta: Adquisición de Conocimiento Técnico

Escenario:

Un equipo ágil está comenzando un proyecto complejo que utiliza una nueva arquitectura de microservicios con tecnologías emergentes. Aunque el equipo tiene experiencia en desarrollo, nunca ha trabajado con estos frameworks específicos. La organización cuenta con un arquitecto senior que ha implementado exitosamente esta arquitectura en cinco proyectos anteriores. El equipo está preocupado por los desafíos técnicos que enfrentarán.

¿Cuál sería la mejor estrategia para ayudar al equipo a adquirir el conocimiento técnico necesario?”

a) Contratar un curso externo de microservicios

b) Implementar mentoring con el arquitecto senior

c) Documentar los requisitos técnicos

d) Realizar sesiones de programación en equipo (pair programming)

Respuesta correcta:

b) Implementar mentoring con el arquitecto senior

Análisis:

Durante la discusión, identificamos que el mentoring es la opción más efectiva porque:

• Aprovecha recursos internos: Ya existe un arquitecto con experiencia en la organización.
• Transferencia directa de conocimiento: El mentoring permite compartir experiencias prácticas y lecciones aprendidas en proyectos anteriores similares.
• Aprendizaje contextualizado: El equipo aprende específicamente lo que necesita para su proyecto actual.
• Resolución inmediata de dudas: Facilita la consulta de problemas específicos durante el desarrollo.

Diferenciamos claramente el mentoring de la capacitación tradicional:

• El mentoring es un proceso a largo plazo (no solo unas semanas)
• Se enfoca en desarrollar experiencia, no solo habilidades técnicas
• Establece una relación continua de apoyo durante todo el proyecto

Recuerda que contratar un curso externo tendría limitaciones porque estos suelen ser generales y no están orientados a las necesidades específicas del proyecto de la empresa.

Segunda Pregunta: Roles en Equipos Ágiles

Escenario:

Una empresa ha creado un equipo interdisciplinario que impulsa su proyecto de transformación digital. El equipo debe entregar un producto mínimo viable que responda a las necesidades del mercado en el menor tiempo posible. Relaciona las funciones del equipo de la izquierda con sus correspondientes responsabilidades de la derecha.

• Equipo de desarrollo
• Scrum Master
• Dueño de producto (Product Owner)

Responsabilidades:

• Organizar y realizar el trabajo
• Remover los bloqueadores
• Definir la versión que se va a liberar

Relaciones correctas:

• Equipo de desarrollo → Organizar y realizar el trabajo
• Scrum Master → Remover los bloqueadores
• Dueño de producto → Definir la versión a liberar

Análisis detallado:

Durante la sesión, analizamos cada rol dentro del marco de trabajo ágil:

El equipo de desarrollo tiene la responsabilidad primaria de ejecutar el trabajo técnico. Son quienes materializan las funcionalidades priorizadas en el backlog.

El Scrum Master funciona como facilitador del proceso, identificando y eliminando impedimentos que puedan afectar la productividad del equipo. No gestiona al equipo, sino que crea las condiciones para que éste pueda auto-organizarse de manera efectiva.

El Product Owner representa la voz del cliente y los interesados. Define qué características se incluirán en cada versión del producto, priorizando aquellas que aportan mayor valor al negocio.

En la discusión, se mencionó que este tipo de preguntas de relacionar conceptos suelen aparecer en los exámenes de certificación y pueden incluir más de tres opciones, lo que aumenta su complejidad.

Tercera Pregunta: Alineación con Especificaciones del Cliente

Escenario:

Al final del ciclo de vida de un proyecto, se ha entregado un producto vanguardista. Sin embargo, el cliente afirma que el producto no se diseñó conforme a las especificaciones. ¿Qué debería haber hecho el director de proyecto para evitar este problema?

a) Los requisitos del cliente deben haberse recopilado y modificado para cumplir los estándares del proveedor

b) La reunión para planificar la revisión de iteración debería haberse planificado adecuadamente

c) Los requisitos del cliente deberían haberse recogido para cumplir con los estándares del cliente

d) La reunión de retrospectiva del sprint debería haber incluido a las partes interesadas necesarias

Respuesta correcta:

c) Los requisitos del cliente deberían haberse recogido para cumplir con los estándares del cliente

Análisis detallado:

Esta pregunta generó una discusión significativa. Analizamos cada opción:

La opción a) es incorrecta porque modificar los requisitos del cliente para adaptarlos a los estándares del proveedor va en contra de los principios básicos de gestión de proyectos. Esto alteraría lo que el cliente realmente necesita.

La opción b) sobre planificar adecuadamente la revisión de iteración no aborda el problema central. Aunque las revisiones son importantes, el problema fundamental es la desalineación inicial entre lo desarrollado y las especificaciones del cliente.

La opción c) es correcta porque enfatiza la necesidad de alinear desde el principio los requisitos con los estándares y expectativas del cliente. Cada requisito debe generar un entregable que aporte valor real y satisfaga las necesidades expresadas.

La opción d) es incorrecta porque las retrospectivas son reuniones internas del equipo para analizar su propio desempeño y no suelen incluir a los interesados. Las partes interesadas participan en las reuniones de revisión, no en las retrospectivas.

Durante la discusión, se mencionó que este tema está documentado en la página 174 del PMBOK, donde se detallan los métodos de recopilación y análisis de datos para obtener una comprensión clara de los requisitos del cliente.

Cuarta Pregunta: Gestión de Nuevos Interesados

Escenario:

A mitad de un proyecto, el director del proyecto identifica nuevos interesados. Cada uno de estos interesados tiene roles diferentes dentro del proyecto. ¿Qué debe hacer el director del proyecto en esta situación?

a) Reunirse con el sponsor para saber si se han creado nuevas funciones

b) Revisar el registro de interesados

c) Enviar una solicitud de cambio

d) Actualizar el plan de involucramiento de interesados

Respuesta correcta:

d) Actualizar el plan de involucramiento de interesados

Análisis detallado:

Esta pregunta generó un debate interesante, con varios participantes considerando inicialmente la opción b) como correcta.

La clave está en entender que el escenario ya indica que “el director identifica nuevos interesados”, lo que implica que ya se conoce la existencia de estos interesados. El siguiente paso no sería revisar el registro (puesto que ya se sabe que son nuevos), sino actualizar el plan de involucramiento.

Durante la discusión, se aclaró que:

• Cuando se identifican nuevos interesados, es necesario analizar su poder e interés en el proyecto
• Se deben determinar sus expectativas específicas
• Hay que desarrollar estrategias adecuadas para su involucramiento

Un punto importante que surgió fue la relación entre el registro de interesados y el plan de involucramiento. Como explicó uno de los participantes (Arturo), el plan de involucramiento es un documento más amplio que incluye el registro. Cada vez que se actualiza el registro, necesariamente debe actualizarse también el plan de involucramiento.

También se discutió la estrecha relación entre el plan de involucramiento y el plan de comunicaciones:

• El plan de involucramiento establece la estrategia general para gestionar a los interesados
• El plan de comunicaciones define las herramientas y métodos específicos para implementar esas estrategias

Se mencionó que esta información puede encontrarse en la página 129 del PMBOK.

Quinta Pregunta: Motivación en Equipos Ágiles

Escenario:

Un equipo ágil ha estado trabajando en un proyecto durante seis meses. A pesar de que están cumpliendo con los entregables, el líder ágil nota que el equipo muestra señales de desmotivación como participación reducida en las ceremonias, menor iniciativa para resolver impedimentos y discusiones en las interacciones entre los miembros. El dueño del producto sugiere implementar un sistema de bonos por entregables. ¿Cuál sería la acción más efectiva para mejorar la motivación del equipo a largo plazo?

a) Implementar el sistema de bonos sugerido por el product owner

b) Otorgar más autonomía al equipo para que definan cómo abordar los desafíos técnicos

c) Establecer objetivos más desafiantes con plazos más cortos

d) Aumentar la frecuencia de reuniones de seguimiento

Respuesta correcta:

b) Otorgar más autonomía al equipo para que definan cómo abordar los desafíos técnicos

Análisis detallado:

Durante la discusión, aplicamos la teoría de Herzberg sobre factores de higiene y motivación:

• Factores de higiene (externos): Salario, condiciones de trabajo, relaciones con compañeros. Su ausencia desmotiva, pero su presencia no necesariamente aumenta la motivación a largo plazo.
• Factores de motivación (internos): Autonomía, aprendizaje, reconocimiento, trabajo con propósito. Estos generan motivación sostenible.

Analisis de Opciones:

Opción a) sobre implementar bonos puede generar un impulso motivacional inicial, pero no es sostenible a largo plazo. Como se explicó en la sesión, los incentivos económicos tienden a perder su efecto motivador con el tiempo.

Opción b) es correcta porque la autonomía es un factor de motivación intrínseco que genera sentido de responsabilidad y pertenencia. Al permitir que el equipo defina cómo abordar los desafíos técnicos, se fomenta la creatividad, el compromiso y la satisfacción personal.

Opción c) sobre establecer objetivos más desafiantes podría ser motivadora, pero los plazos más cortos generarían estrés adicional en un equipo ya desmotivado.

Opción d) sobre aumentar reuniones de seguimiento probablemente empeoraría la situación, ya que el equipo ya muestra baja participación en las ceremonias existentes.

Un participante (Carlos) señaló acertadamente que esta respuesta se alinea con el quinto principio del Manifiesto Ágil: “Construir proyectos alrededor de individuos motivados, darles el entorno y el apoyo que necesiten y confiar en ellos para hacer el trabajo.”

Se mencionó que pueden encontrarse más detalles sobre este tema en la página 159 del PMBOK.

Temas Analizados

Trabajo en Pares (Pair Programming)

A raíz de la primera pregunta, surgió una discusión interesante sobre el trabajo en pares. Algunos puntos clave:

• Origen y aplicaciones: Aunque nació en el desarrollo de software, es aplicable a diversos contextos.
• Cuándo es efectivo: Funciona mejor cuando:
  • Los participantes tienen niveles de conocimiento similares
  • Ambos son expertos en sus roles complementarios
  • Las tareas requieren revisión inmediata
• Ejemplos :
  • En desarrollo de software: un programador escribe código mientras otro revisa
  • En elaboración de informes técnicos: un experto define la estructura mientras un novato desarrolla el contenido operativo
  • En soldadura: un soldador realiza el trabajo mientras un inspector verifica inmediatamente
  • En cableado y certificación de redes: un técnico instala mientras otro certifica

Un participante (Anthony) compartió su experiencia utilizando esta técnica con nuevos miembros de equipo, asignándoles tareas operativas mientras los miembros experimentados se ocupan de aspectos más complejos, permitiendo así la transferencia gradual de conocimiento.

Transferencia de Conocimiento vs. Trabajo en Pares

También se discutió la relación entre transferencia de conocimiento y trabajo en pares:

• La transferencia de conocimiento es un concepto más amplio que puede implementarse mediante diferentes estrategias
• El trabajo en pares es una de las técnicas para lograr esta transferencia
• Otras estrategias incluyen:
  • Talleres y workshops
  • Documentación en portales de conocimiento
  • Revisión de lecciones aprendidas

Varios participantes compartieron cómo combinan estas estrategias en sus organizaciones para maximizar la retención del conocimiento y reducir dependencias de personas específicas.