3) Preguntas técnicas y profesionales (las que separan a un PM real)
Acá es donde muchas entrevistas en Uruguay se ponen interesantes. No te van a pedir que programes, pero sí que entiendas el terreno: delivery ágil, dependencias, seguridad, proveedores, y cómo se gobierna un proyecto cuando hay auditoría o un cliente enterprise.
Para preparar estas respuestas, pensá como Director de Proyectos de TI: método, evidencia y decisiones explícitas.
Q: ¿Qué metodología usás: Scrum, Kanban o híbrido? ¿Cómo decidís cuál aplicar?
Why they ask it: Quieren pragmatismo, no fanatismo.
Answer framework: “Contexto–Señales–Diseño”: tipo de trabajo, incertidumbre, dependencias y cadencia.
Example answer: “Si tengo producto con incertidumbre y necesidad de feedback, uso Scrum con sprints cortos y definición de listo/hecho fuerte. Si es soporte evolutivo con flujo continuo, Kanban con límites de WIP y políticas explícitas. En la práctica suelo ir a un híbrido: planificación por sprint, pero con tablero que muestre bloqueos y lead time. La decisión la tomo mirando variabilidad del trabajo y costo de cambiar prioridades.”
Common mistake: Responder “Scrum siempre” sin justificar.
Q: En Jira, ¿qué configuraciones o tableros te ayudan a controlar un proyecto sin microgestionar?
Why they ask it: Buscan dominio de herramientas reales de delivery.
Answer framework: “Tablero–Métrica–Acción”: qué ves, qué medís, qué decidís.
Example answer: “Armo un tablero por equipo con estados que reflejen el flujo real (incluyendo ‘Blocked’ con causa). Uso versiones/releases para compromisos y un dashboard con burn-up, cumulative flow y aging de issues. Lo importante es que el tablero sea un espejo del sistema: si hay mucho ‘In Progress’, ajusto WIP y destrabo dependencias; si el burn-up se aplana, reviso alcance o capacidad.”
Common mistake: Hablar de Jira como lista de tareas, sin métricas ni decisiones.
Q: ¿Cómo armás y mantenés un RAID log (Riesgos, Asunciones, Issues, Dependencias) en un proyecto de TI?
Why they ask it: Esto es “oficio” de Jefe de Proyectos de Tecnología; pocos lo hacen bien.
Answer framework: “Plantilla mínima viable + cadencia”: qué campos, quién lo actualiza, cómo se usa.
Example answer: “Uso un RAID log simple en Confluence o Excel compartido: descripción, probabilidad/impacto, dueño, fecha, plan de mitigación y gatillos. Lo reviso semanalmente con el equipo y quincenalmente con stakeholders. Si un riesgo se materializa, pasa a issue con plan y fecha. Y las dependencias las conecto a hitos: si no hay fecha y responsable, no es dependencia, es deseo.”
Common mistake: Tratar riesgos como ‘lista para auditoría’ y no como herramienta viva.
Q: ¿Cómo estimás y planificás cuando el equipo te dice “no sabemos, nunca lo hicimos”?
Why they ask it: Quieren ver si sabés gestionar incertidumbre técnica.
Answer framework: “Descubrimiento–Spike–Reestimación”: convertir incertidumbre en aprendizaje.
Example answer: “Primero separo lo desconocido en hipótesis y riesgos. Propongo spikes timeboxed para validar arquitectura, performance o integraciones. Con resultados, reestimamos y definimos un plan por incrementos con checkpoints. Prefiero un plan que admita cambios a una fecha ‘de fe’ que después se rompe.”
Common mistake: Forzar una estimación exacta sin reducir incertidumbre.
Q: ¿Cómo gestionás integraciones con proveedores (por ejemplo, pasarelas de pago, facturación electrónica o servicios cloud) en Uruguay?
Why they ask it: En UY es común depender de terceros; quieren ver control contractual y técnico.
Answer framework: “Contrato–Interfaz–Prueba”: SLA/alcance, definición de API, plan de pruebas end-to-end.
Example answer: “Alineo expectativas por escrito: entregables, SLA, ventanas de soporte y criterios de aceptación. A nivel técnico, cierro contrato de interfaz (API, formatos, errores, timeouts) y un plan de pruebas con ambientes y datos. Y pongo hitos de integración temprano: si esperás al final, el proveedor te define la fecha. Prefiero fallar rápido en sandbox que fallar en producción.”
Common mistake: Tratar al proveedor como ‘caja negra’ y descubrir problemas al final.
Q: ¿Qué harías si el día del Go-Live falla el pipeline de CI/CD o el despliegue?
Why they ask it: Quieren un plan de contingencia real, no heroísmo.
Answer framework: Respuesta por capas: contención → diagnóstico → decisión → comunicación.
Example answer: “Primero activo el plan de release: freeze, roles claros y canal único de comunicación. Si el pipeline falla, evalúo si hay rollback seguro o si conviene pausar y volver a la versión estable. Paralelamente, asigno a un responsable a diagnóstico (logs, permisos, runners, credenciales) y a otro a comunicación con negocio. La regla: no improvisar en producción; ejecutar runbook y documentar post-mortem.”
Common mistake: “Nos quedamos hasta que salga” sin rollback ni comunicación.
Q: ¿Cómo manejás seguridad y compliance en proyectos (por ejemplo, datos personales)?
Why they ask it: En Uruguay hay exigencias reales de protección de datos y auditoría.
Answer framework: “Shift-left de riesgos”: requisitos → controles → evidencia.
Example answer: “Involucro seguridad desde el inicio: clasificación de datos, controles de acceso, logging y retención. Si hay datos personales, pido revisión de cumplimiento con la normativa local y políticas internas, y lo traduzco a historias y criterios de aceptación. Además, dejo evidencia: decisiones, aprobaciones y pruebas. Seguridad no es un ‘check’ al final; es diseño.”
Common mistake: Delegar todo en el área de seguridad y enterarte al final.
Q: ¿Qué estándares o certificaciones te sirven en el rol (PMP, PRINCE2, ITIL, Scrum) y cómo los aplicás en la práctica?
Why they ask it: Quieren separar “tengo el papel” de “lo uso para decidir”.
Answer framework: “Principio–Aplicación–Resultado”: 1 principio, 1 práctica, 1 impacto.
Example answer: “De PMP tomo el foco en gestión de alcance, riesgos y stakeholders: acta, WBS cuando aplica y control de cambios. De Scrum, la inspección y adaptación: retrospectivas con acciones reales. Y de ITIL, el cuidado del cambio en producción: ventanas, aprobaciones y comunicación. La certificación suma si se ve en cómo ordenás el trabajo y reducís sorpresas.”
Common mistake: Enumerar siglas sin aterrizarlas a prácticas.
Q: ¿Cómo armás un business case simple para priorizar un proyecto frente a otro?
Why they ask it: En empresas uruguayas medianas, el PM muchas veces ayuda a priorizar inversión.
Answer framework: “Valor–Costo–Riesgo–Tiempo”: 4 variables, una decisión.
Example answer: “Pongo en una hoja: beneficio esperado (ingresos, ahorro, riesgo evitado), costo total (equipo + licencias + proveedor), riesgos y time-to-value. Si dos iniciativas compiten, priorizo la que entregue valor antes con riesgo controlado. Y dejo supuestos explícitos: si cambian, cambia la decisión.”
Common mistake: Priorizar por ‘quién grita más fuerte’.
Q: ¿Cómo reportás a dirección sin caer en status reports eternos?
Why they ask it: Quieren comunicación ejecutiva, no burocracia.
Answer framework: “Semáforo + decisiones”: estado, riesgos top 3, decisiones requeridas.
Example answer: “Hago un reporte de una página: semáforo por alcance/tiempo/calidad, hitos próximos, riesgos top con mitigación y, sobre todo, decisiones que necesito del steering. Si no hay decisiones, el reporte es demasiado largo o demasiado tímido. Dirección compra claridad, no detalle.”
Common mistake: Mandar un mail largo con tareas y sin pedidos concretos.