Gerente de proyectos Preguntas de entrevista & Respuestas

Respuesta modelo

Heredé un proyecto de implementación de CRM que llevaba 3 meses de retraso y superaba el presupuesto en un 40%. El gerente de proyecto anterior había abandonado el equipo y la moral estaba por los suelos. Durante mi primera semana, mantuve reuniones individuales con cada miembro del equipo y con los principales interesados para entender los problemas reales. Encontré tres causas raíz: el alcance se había triplicado respecto al plan original sin ajustes de plazo, el proveedor tenía un rendimiento insuficiente en las integraciones, y dos miembros clave del equipo habían sido reasignados a otros proyectos. Presenté un plan de recuperación: renegocié el alcance con el patrocinador del negocio, recortando el 30% de las funcionalidades a una Fase 2 y enfocando la Fase 1 en las capacidades imprescindibles. Escalé el problema de rendimiento del proveedor a compras, que aplicó penalizaciones contractuales y nos consiguió un desarrollador sénior dedicado. Logré apoyo parcial de sustitución para los miembros reasignados. Entregamos la Fase 1 con un mes de retraso (frente a tres), dentro del presupuesto ajustado y con una satisfacción del 92% por parte de los interesados. Las funcionalidades de la Fase 2 se entregaron en el trimestre siguiente.

Respuesta modelo

Dos ingenieros sénior de mi equipo tenían opiniones radicalmente opuestas sobre la arquitectura de una migración de datos: uno defendía un corte único (big bang), el otro un enfoque por fases. El desacuerdo había adquirido un cariz personal y estaba afectando a las reuniones del equipo. Me reuní con cada uno por separado para entender sus preocupaciones. El defensor del corte único temía tener que mantener dos sistemas en paralelo. El defensor del enfoque por fases temía la pérdida de datos durante el traspaso. Ambas preocupaciones eran legítimas. Organicé una revisión de diseño estructurada en la que cada uno expuso su propuesta con un análisis de riesgos. Pedí al equipo que evaluara ambas opciones con tres criterios: riesgo de pérdida de datos, complejidad operativa y plazo. Los datos mostraron que el enfoque por fases era menos arriesgado, pero requería mayor esfuerzo. Tomé la decisión: enfoque por fases, pero con automatización para reducir la carga de los sistemas paralelos (abordando así la preocupación del primer ingeniero). Reconocí públicamente las inquietudes válidas del defensor del corte único y le asigné el liderazgo del trabajo de automatización. La migración se completó con cero pérdida de datos.

Respuesta modelo

A mitad de una migración de plataforma de 6 meses, el equipo de cumplimiento normativo identificó nuevos requisitos regulatorios que añadían 8 semanas de trabajo. El patrocinador del negocio seguía esperando el plazo original. Realicé de inmediato un análisis de impacto: los nuevos requisitos suponían 320 horas de desarrollo y 80 horas de pruebas adicionales. Presenté tres opciones al comité directivo. Opción A: ampliar el plazo 8 semanas para abarcar el alcance completo. Opción B: incorporar 3 contratistas para mantener el plazo con un coste adicional de $90K. Opción C: aplazar las funcionalidades no relacionadas con el cumplimiento para respetar el plazo y el presupuesto, y entregar esas funcionalidades 6 semanas después. Recomendé la Opción C porque el cumplimiento normativo era innegociable, y varias de las funcionalidades aplazadas no eran necesarias hasta el tercer trimestre. El comité directivo estuvo de acuerdo. Actualicé el plan del proyecto, comuniqué el cambio a todos los interesados con una justificación clara y entregué la versión centrada en el cumplimiento a tiempo. Las funcionalidades aplazadas se lanzaron 5 semanas después. La clave fue presentar opciones con sus compensaciones, en lugar de limitarme a dar malas noticias.

Respuesta modelo

Gestioné un proyecto de rediseño de sitio web con miembros del equipo en Nueva York, Londres y Bangalore, tres zonas horarias con solo 3 horas de coincidencia. Establecí una estructura de comunicación que respetaba los husos horarios: comunicación asíncrona como primera opción a través de Slack y Confluence para todo lo que no requería discusión en tiempo real, una reunión diaria de 15 minutos durante la franja de coincidencia solo para bloqueos, y sesiones semanales de análisis profundo que rotaban entre horarios adaptados a cada zona horaria para que nadie estuviera siempre en una llamada nocturna. Creé documentación detallada de los sprints para que el equipo de Bangalore pudiera retomar el trabajo dejado por el de Nueva York, y viceversa. También invertí mucho en construir relaciones: eventos virtuales mensuales de equipo y videollamadas individuales trimestrales con cada miembro. El proyecto se entregó a tiempo con una puntuación de satisfacción del equipo de 4,5 sobre 5. Dos miembros me dijeron que había sido el proyecto distribuido mejor gestionado en el que habían participado.

Respuesta modelo

La decisión la baso en tres factores: la estabilidad de los requisitos, la flexibilidad de los interesados y la experiencia del equipo. Waterfall funciona cuando los requisitos están bien definidos y es poco probable que cambien (proyectos de cumplimiento normativo, construcción, hardware), cuando el cliente necesita un precio y un plazo fijos desde el inicio, o cuando el proyecto tiene dependencias estrictas que deben seguir una secuencia. Agile funciona cuando los requisitos evolucionarán en función del feedback de los usuarios (desarrollo de producto, transformación digital), cuando entregar valor de forma incremental es más importante que esperar a una solución completa, y cuando el equipo tiene experiencia con el trabajo iterativo. En la práctica, la mayoría de los proyectos se benefician de un enfoque híbrido: ejecución ágil dentro de un marco de gobernanza Waterfall. Defino el alcance y los hitos globales desde el principio (para el presupuesto y la alineación de los interesados), pero ejecuto en sprints con flexibilidad para ajustar prioridades dentro del alcance. El antipatrón que evito: usar Agile como excusa para no planificar, o usar Waterfall como excusa para no tener flexibilidad.

Respuesta modelo

Utilizo una combinación de técnicas según la fase del proyecto. En etapas iniciales (orden de magnitud): estimación análoga, comparando con proyectos pasados similares ajustados por complejidad. Esto da un rango, no un punto exacto. 'Basándome en el proyecto de CRM del año pasado, esto tiene entre 4 y 6 meses.' En la fase de planificación: estimación ascendente. Descompongo el trabajo en tareas, pido al equipo que estime cada tarea (uso Planning Poker para la estimación relativa), y añado dependencias y margen. Aplico la regla del 1,5: cualquier estimación del equipo la multiplico por 1,5 para dar cabida a incertidumbres desconocidas, complejidad de integración y cambios de contexto. Para las tareas individuales, solicito estimaciones en tres puntos: optimista, más probable y pesimista. La fórmula PERT (O + 4M + P) / 6 proporciona una media ponderada. Siempre presento las estimaciones como rangos, nunca como cifras únicas. Y las reviso en cada hito importante a medida que conocemos mejor el proyecto. La estimación más peligrosa es la que nunca se actualiza.

Respuesta modelo

Mantengo un registro de riesgos vivo que se revisa semanalmente. Para cada riesgo, registro: descripción, probabilidad (1-5), impacto (1-5), puntuación de riesgo (probabilidad x impacto), responsable, estrategia de mitigación e indicadores de alerta. Categorizo los riesgos en: técnicos (nueva tecnología, complejidad de integración), de recursos (dependencia de personas clave, brechas de competencias), externos (retrasos de proveedores, cambios normativos) y de plazo (cadenas de dependencias, incertidumbre en las estimaciones). Para los 5 riesgos con mayor puntuación, desarrollo planes de mitigación específicos. Algunos ejemplos: para la dependencia de personas clave, me aseguro de que haya transferencia de conocimiento y documentación. Para el riesgo de proveedor, mantengo una relación con un proveedor alternativo. Para el riesgo de plazo en la ruta crítica, añado márgenes de tiempo e identifico tareas que se pueden paralelizar. Distingo entre mitigación del riesgo (reducir la probabilidad o el impacto antes de que ocurra) y planificación de contingencias (qué hacemos si el riesgo se materializa). Cada responsable de riesgo informa del estado semanalmente. Los riesgos que se materializan pasan a ser incidencias y se registran en el registro de incidencias con un responsable y un plazo de resolución.

Respuesta modelo

Hago seguimiento de cuatro categorías. Plazo: tendencia de la velocidad del sprint (¿el equipo acelera, se mantiene estable o desacelera?), tasa de cumplimiento de hitos e índice de rendimiento de cronograma (valor ganado / valor planificado). Presupuesto: gasto real frente al planificado, tasa de consumo y estimación a la conclusión. Calidad: densidad de defectos, tasa de superación de pruebas y porcentaje de retrabajos (cuánto trabajo se devuelve). Equipo: satisfacción del equipo (encuestas mensuales de pulso), horas extra (las horas extra sostenidas son señal de problemas) y riesgo de rotación. Presento todo esto en un panel de una sola página con semáforos de rojo, ámbar y verde para cada categoría. La métrica más importante no es ningún número en particular: es la tendencia. Una velocidad estable en 30 puntos de historia está bien. Una velocidad que era de 40 en el sprint anterior y ahora es de 30 es una señal de alerta que requiere investigación. También hago seguimiento de una métrica honesta que no se puede manipular: fechas de entrega reales frente a las previstas para los hitos completados. Si entregamos consistentemente tarde, el proceso de estimación necesita corrección.

Respuesta modelo

Lo primero sería mantener una conversación honesta con el miembro que se marcha sobre sus plazos y su disposición a colaborar en la transferencia de conocimiento. Incluso 2 semanas de traspaso estructurado tienen valor. De inmediato, evaluaría el impacto: ¿qué trabajo depende del conocimiento exclusivo de esta persona? ¿En qué tareas está trabajando actualmente? ¿Dónde están los puntos únicos de fallo? Después actuaría en tres frentes. Captura de conocimiento: sesiones intensivas de documentación y grabaciones de sus áreas de trabajo. Incluso una documentación imperfecta es mejor que ninguna. Redistribución de carga de trabajo: reasignaría sus tareas según la capacidad y las competencias de los demás miembros del equipo. Siendo realista: el equipo irá más despacio temporalmente. Comunicación: informaría a los interesados sobre el impacto en el plazo y lo que estoy haciendo al respecto. Prefiero dar malas noticias pronto con un plan, que sorprender a todos con un retraso. En cuanto a la sustitución: iniciaría el proceso de contratación de inmediato, pero planificaría la continuidad del proyecto sin esa persona. Ningún proyecto debería depender de una sola persona; si es así, es un riesgo que debería haber mitigado antes.

Respuesta modelo

Empezaría por hacer visibles los conflictos. A menudo los interesados no saben que están en conflicto porque cada uno ha comunicado sus prioridades al responsable del proyecto por separado. Organizaría una sesión de alineación de prioridades con todos los interesados clave, presentando: la lista completa de requisitos, los recursos y el plazo disponibles, y el hecho de que no podemos entregarlo todo a la vez. Usaría un ejercicio de clasificación forzada: cada interesado dispone de 100 puntos para distribuir entre las funcionalidades. Esto hace tangibles las compensaciones: no se puede dar 100 puntos a todo. Donde las clasificaciones divergen significativamente, facilitaría una discusión: ¿cuál es el argumento de negocio para cada prioridad? ¿Cuál es el coste del retraso? Muchas veces, escuchar el razonamiento del otro resuelve el conflicto. Si no lo hace, escalaría al patrocinador del proyecto para una decisión de desempate, con los datos del ejercicio de clasificación y mi recomendación. Tras la alineación, documentaría las prioridades acordadas y las compartiría ampliamente. Cuando las prioridades inevitablemente cambien, repetiría el proceso en lugar de tomar la decisión por mi cuenta.

Respuesta modelo

Actuaría rápido: las desviaciones presupuestarias empeoran cuanto más tiempo se espera. Primero, análisis de causas raíz: ¿por qué estamos por encima del presupuesto? Las causas habituales son expansión del alcance (se añadió trabajo sin ajuste presupuestario), errores de estimación (las tareas llevaron más tiempo del esperado), cambio en los costes de los recursos, o factores externos (subidas de precios de proveedores, requisitos regulatorios). Segundo, presentaría la situación y las opciones al patrocinador del proyecto. Opción A: aumentar el presupuesto en un 25% y entregar el alcance completo, justificando el incremento con detalles específicos sobre qué cambió. Opción B: reducir el alcance para ajustarse al presupuesto original, con una lista de las funcionalidades que se aplazarían y su impacto en el negocio. Opción C: ampliar el plazo (si la desviación se debe a costes de horas extra, distribuir el trabajo en más tiempo puede ser más económico). Opción D: optimizar la ejecución: ¿podemos reducir costes mediante automatización, renegociación de tarifas con proveedores, o usando recursos diferentes? Presentaría mi recomendación respaldada por datos. Cualquiera que sea la decisión, implementaría controles de costes más estrictos en adelante: revisiones semanales del presupuesto en lugar de mensuales, puntos de aprobación para cualquier nuevo alcance y estimaciones actualizadas para el trabajo restante. Lo fundamental: que una sorpresa presupuestaria nunca sea una sorpresa. Hay que comunicar a tiempo.

Respuesta modelo

Investigaría antes de prescribir. Primero, analizaría los datos: ¿qué tipo de trabajo incumplimos sistemáticamente? ¿Se subestima constantemente, o hay interrupciones que apartan a los miembros del equipo del trabajo del sprint? ¿Existen cuellos de botella por dependencias donde un equipo bloquea a otro? Después hablaría con el equipo en las retrospectivas: ¿consideran que los objetivos del sprint son realistas? ¿Hay problemas sistémicos que ellos ven y yo no? Las causas raíz habituales que buscaría son: sobrecarga de compromisos (el equipo planifica al 100% de capacidad cuando la realidad es el 70% por reuniones, soporte e interrupciones), estimación deficiente (las historias son sistemáticamente entre 2 y 3 veces más grandes de lo estimado), requisitos poco claros (las historias entran en el sprint y luego pasan 2 días en aclaraciones) y cambio de contexto (los miembros del equipo se ven arrastrados a incidencias u otros proyectos). Mis soluciones dependen del diagnóstico: incluir un margen del 30% en la capacidad, mejorar el refinamiento de historias para detectar la ambigüedad antes de la planificación del sprint, negociar tiempo de concentración protegido con la dirección, o descomponer las historias en piezas más pequeñas, más fáciles de estimar y completar.