Preguntas de entrevista Gerente de TI

Mantengo un backlog estructurado de demanda de TI y lo reviso mensualmente con los principales stakeholders del negocio. Cada solicitud entrante se evalúa en tres dimensiones: impacto en el negocio (¿qué falla o mejora si lo hacemos o no?), urgencia (¿hay un plazo, un requisito de cumplimiento o un riesgo operativo que condicione el momento?) y nivel de esfuerzo (¿cuánto tiempo tomará realmente?). Categorizo el trabajo en tres grupos: run (mantener los sistemas en funcionamiento), grow (mejorar las capacidades existentes) y transform (cambio estratégico). El trabajo run tiene prioridad por defecto porque las interrupciones afectan a todos de inmediato. Para el trabajo grow y transform, uso una matriz de puntuación y presento la lista ordenada al comité de dirección trimestralmente para que las decisiones de priorización sean del negocio, no solo de TI.

Mantengo un registro de proveedores con cuatro datos clave para cada proveedor crítico: fecha de vencimiento del contrato, rendimiento del SLA, contactos de escalada y responsable de la renovación. Reviso el rendimiento del SLA mensualmente y mantengo revisiones de negocio trimestriales con los proveedores críticos. También me aseguro de no tener una dependencia excesiva de un solo proveedor para un servicio crítico: cada proveedor de nivel uno debe tener un plan de salida documentado y una alternativa probada. Antes de renovar cualquier contrato significativo realizo una revisión competitiva ligera, aunque tenga intención de renovar, porque me da palanca para negociar precios y mantiene honesta la relación con el proveedor.

Trato la seguridad como un riesgo de negocio, no una responsabilidad del departamento técnico. Mantengo un registro de riesgos con probabilidad, impacto y estado de las medidas de mitigación para cada riesgo de TI identificado, y lo reviso trimestralmente con el equipo directivo. Mi marco de seguridad cubre cuatro capas: seguridad perimetral (cortafuegos, detección de intrusiones), gestión de identidades y accesos (mínimo privilegio, MFA en todos lados), protección de datos (cifrado en reposo y en tránsito, pruebas de copia de seguridad y recuperación) y concienciación (simulaciones de phishing regulares y formación del personal). También realizo una prueba de penetración anual y soluciono todos los hallazgos críticos en 30 días. El fallo de seguridad más frecuente que veo es el de organizaciones que invierten en controles técnicos pero descuidan la capa humana.

Sufrimos una interrupción completa de nuestra plataforma orientada al cliente un miércoles por la tarde causada por una migración de base de datos fallida. El sistema estuvo caído durante 90 minutos. Activé de inmediato nuestro proceso de respuesta a incidentes: asigné un responsable de incidentes, creé un canal de Slack dedicado y establecí un ciclo de actualizaciones cada 15 minutos para la comunicación con los stakeholders. Mantuve al CEO y al responsable de atención al cliente informados con actualizaciones en lenguaje claro en lugar de logs técnicos. La causa raíz fue un script de migración no probado con volúmenes de datos de producción. Una vez restaurado, realicé un post-mortem sin culpas en las 48 horas siguientes. Identificamos tres brechas de proceso y las solucionamos todas en una semana. La disponibilidad en los 12 meses siguientes fue del 99,97%.

Nuestro CEO quería migrar toda nuestra infraestructura de datos a una nueva plataforma en la nube en seis semanas, impulsado por una conversación en una conferencia. El plazo era poco realista: una migración adecuada tardaría seis meses, requeriría una formación significativa del equipo y conllevaría un alto riesgo de integridad de datos si se precipitaba. Preparé un documento de una página para el CEO: un resumen de lo que la migración implicaría realmente, el riesgo del plazo de seis semanas y un plan por fases alternativo que entregaba la primera mejora de capacidad en ocho semanas gestionando el riesgo adecuadamente. Presenté ambos plazos uno al lado del otro con sus perfiles de riesgo. El CEO aceptó el plan por fases. La migración se completó con éxito en cinco meses.

Cuando me incorporé a mi empresa anterior, TI era completamente reactivo: el equipo pasaba el 80% del tiempo en tickets de soporte sin capacidad para trabajos de mejora. Descubrí que el 40% del volumen de tickets era causado por tres problemas recurrentes: una infraestructura de impresoras obsoleta, una VPN mal configurada y un proceso de incorporación que generaba problemas de acceso para los nuevos empleados. Resolví las tres causas raíz en el primer trimestre. El volumen de tickets bajó un 38%, lo que liberó capacidad para un portal de autoservicio de TI que redujo las solicitudes por correo un 60%, y una implantación de gestión de dispositivos que redujo el tiempo de configuración de los nuevos empleados de 4 horas a 45 minutos. Al sexto mes, el equipo había pasado de un 80% reactivo a un 50% proactivo.

Mantengo una hoja de ruta de infraestructura a tres años alineada con el plan de crecimiento del negocio. Cada seis meses reviso la utilización actual en cómputo, almacenamiento y red, y modelo la demanda futura basándome en las previsiones de plantilla, la hoja de ruta del producto y el volumen de transacciones esperado. Establezco umbrales de utilización que desencadenan una revisión: si cualquier sistema de nivel uno alcanza el 75% de capacidad, comienzo a planificar el siguiente incremento. Para los recursos en la nube uso el escalado automático donde es posible para evitar el sobreaprovisionamiento. Para la infraestructura local incorporo un margen del 20-25%. Reviso la hoja de ruta frente al gasto real trimestralmente y presento un resumen escrito al CFO.

Utilizo una clasificación de cambios de tres niveles: cambios estándar (pre-aprobados, de bajo riesgo, aplicables en cualquier momento), cambios normales (requieren revisión del CAB, aplicados durante una ventana de cambio) y cambios de emergencia (omiten el proceso normal pero requieren una revisión post-implementación en 24 horas). Cada cambio tiene una evaluación de riesgos, un plan de reversión y un enfoque de prueba definido antes de pasar al CAB. Mantengo una reunión semanal del comité asesor de cambios de 30 minutos. También mantengo un calendario de congelación de cambios para períodos críticos del negocio. La mayor mejora que he introducido en los procesos de cambio es hacer obligatorios los planes de reversión: obliga a los ingenieros a pensar en el escenario de fallo antes del cambio, no durante él.

Estructuro el presupuesto de TI en tres categorías que se corresponden con el valor del negocio: mantener (mantener los sistemas existentes en funcionamiento, normalmente el 50-60% del gasto de TI), mejorar (ganancias de eficiencia y mejoras de capacidades, normalmente el 30%) e innovar (nuevas capacidades que apoyan el crecimiento, normalmente el 10-20%). Presento esta distribución al equipo directivo en el momento del presupuesto porque les ayuda a entender que la mayor parte del gasto de TI es un coste operativo. También hago seguimiento del valor entregado frente al presupuesto de mejora e innovación: para cada proyecto significativo documento el resultado de negocio esperado e informo del real versus esperado al cierre del proyecto.