Planteamiento y contexto
El entrevistador busca evidencia de que has impulsado un cambio con un bagaje histórico real. Un sistema heredado puede seguir funcionando mientras consume tiempo de guardia (on-call), no cumple con un requisito de seguridad o bloquea un nuevo producto. Explica cómo decidiste retirarlo, cómo migraste a los usuarios y cómo gestionaste los desacuerdos.
Esta no es una solicitud de una reescritura técnica ni una historia que atribuya todo al "trabajo en equipo". La respuesta debe hacer que tu juicio, acciones, evidencia y resultados sean audibles y evidentes.
Qué está evaluando el entrevistador
Están evaluando si comienzas a partir de los flujos de trabajo de los usuarios en lugar de la antigüedad del sistema, si utilizas datos para encontrar a las personas afectadas, si haces visibles los riesgos y la propiedad (ownership), y si mantienes intacto el objetivo del usuario a través del desacuerdo y la ejecución. La guía de entrevistas de Amazon enfatiza el método STAR, las contribuciones individuales específicas y los resultados medibles; el caso de retiro de sistemas de Google SRE enfatiza los flujos de trabajo de los usuarios, la comunicación y las herramientas de migración.
Preguntas para aclarar primero
Aclara si "retirar" significa detener a nuevos usuarios, mantener un archivo de solo lectura, apagarlo por completo o reemplazar un proceso interno. Luego aclara tu rol, alcance, fecha límite, el reemplazo disponible y los riesgos irreversibles. Si los datos de la empresa no se pueden compartir, etiqueta las cifras como mediciones reales anonimizadas o supuestos de la entrevista.
Estructura de respuesta de 30 segundos
Usa cinco oraciones: el contexto y el costo; el objetivo del que fui responsable; cómo utilicé los datos de acceso y las entrevistas con usuarios para elegir las cohortes de migración; cómo diseñé la ejecución dual, la reversión (rollback) y la comunicación; y el resultado, la lección aprendida y el siguiente cambio. Usa la primera persona ("yo") para las acciones y números para los resultados.
Análisis paso a paso
Paso 1: Traducir lo "heredado" en problemas comprobables
No anuncies un apagado simplemente porque el stack tecnológico sea antiguo. Cuantifica las horas de mantenimiento, los incidentes, el costo, las brechas de cumplimiento y los flujos de trabajo críticos que aún lo utilizan. Segmenta por usuario, flujo de trabajo, tamaño de datos y frecuencia de acceso para encontrar excepciones que el reemplazo aún no puede cubrir. Google SRE utilizó patrones de acceso para comprender los flujos de trabajo en lugar de decidir basándose únicamente en las estadísticas del sistema.
Paso 2: Construir evidencia de migración y el camino seguro más pequeño
Define un estado objetivo para cada grupo de usuarios: migración directa, herramientas de conversión, archivo de solo lectura o una extensión con límite de tiempo. Proporciona una lista de verificación de compatibilidad, conciliación de datos, un entorno de ensayo y condiciones de parada explícitas. Comienza con una cohorte de bajo riesgo para que la capacidad de reemplazo y el costo de migración se midan en un uso real.
Paso 3: Gestionar desacuerdos y partes interesadas
Transforma las objeciones en riesgos sobre pérdida de datos, interrupción del trabajo, falta de claridad en la propiedad o falta de capacidad de reemplazo. Elabora una lista de riesgos y un registro semanal de decisiones con soporte, servicio al cliente, seguridad y el propietario del reemplazo. Debate con evidencia; después de una decisión, nombra al ejecutor y a la autoridad de pausa para que el desacuerdo no se convierta en un retraso indefinido.
Paso 4: Diseñar ejecución dual, reversión y comunicación
Mantén el sistema antiguo en modo de solo lectura o reversible durante la migración y dale a cada cohorte una señal de finalización verificable. Comunica el impacto, la razón, la fecha límite, los pasos y los canales de ayuda con anticipación; si un lote falla, expón el hecho, la solución y la próxima actualización. Los falsos positivos que alarman a usuarios no afectados y los falsos negativos que pasan por alto a usuarios afectados erosionan la confianza y generan trabajo de servicio técnico.
Paso 5: Definir resultados y aprendizaje
Monitorea la finalización de la migración, el éxito de los flujos de trabajo críticos, las reversiones, las horas de incidentes, las solicitudes de ayuda y las horas de mantenimiento. No informes únicamente que "se apagó el sistema antiguo"; muestra si los usuarios afectados completaron su trabajo, si la carga operativa disminuyó y qué excepciones quedaron. La retrospectiva debe registrar las suposiciones incorrectas, las señales tempranas y las validaciones para anticiparse la próxima vez.
Ejemplo de respuesta de alta calidad
En una ocasión lideré el retiro de un flujo de trabajo de generación de informes que todavía utilizaba un pequeño grupo de clientes. Consumía alrededor de 20 horas de mantenimiento manual cada semana. El reemplazo cubría la mayoría de las consultas, pero los clientes de alto volumen temían discrepancias en los datos históricos. Segmenté a los usuarios según los registros de acceso y los flujos de trabajo: el 82% podía migrar directamente, mientras que el 18% necesitaba conversión histórica.
Establecí como objetivo completar primero las cohortes de bajo riesgo, no apagar el sistema de inmediato. Ingeniería generó informes de conciliación para ambos resultados, soporte preparó avisos agrupados por cliente y yo lideré un panel semanal de migración con criterios de pausa. Después de un piloto de dos semanas, la consistencia de los informes críticos alcanzó el 99.9% sin ninguna reversión. Para los usuarios restantes, proporcionamos herramientas de conversión y un archivo de solo lectura, y extendimos la fecha límite final una vez.
El mantenimiento se redujo de unas 20 horas a 4 horas por semana, y cada cliente con acceso remanente tuvo una vía de reemplazo. La retrospectiva reveló que habíamos subestimado el formato de exportación de una región, por lo que agregamos la región y el tipo de exportación a la segmentación inicial en lugar de descubrirlo cerca de la fecha límite.
Errores comunes y mejoras
- Decir solo "el sistema era viejo": agrega el impacto en el usuario, el costo de mantenimiento y la evidencia del reemplazo.
- Contar una historia de reescritura de código: explica el descubrimiento de flujos de trabajo, las cohortes y la comunicación.
- Llamar bloqueadores a los escépticos: muestra la evidencia de riesgo detrás de su preocupación y tu respuesta.
- Reportar únicamente el porcentaje de migración: agrega el éxito de tareas críticas, reversiones y volumen de ayuda.
- Afirmar que el riesgo fue cero: nombra la vía de solo lectura, reversión o extensión.
Preguntas de seguimiento y respuestas
¿Qué pasa si el reemplazo no está listo para todos los usuarios?
Mantén una vía de excepción documentada: archivo de solo lectura, herramientas de conversión o una extensión con límite de tiempo. Define el propietario y la condición de salida para cada excepción en lugar de forzar una transición riesgosa.
¿Cómo convenciste a una parte interesada que se oponía al retiro?
Pregunté de qué falla se estaban protegiendo, medí ese flujo de trabajo y ejecuté una pequeña migración para probar el reemplazo. Si la decisión aún iba en contra de su preferencia, registraba el riesgo y me comprometía con el plan acordado con una condición de pausa.
¿Qué harías si la migración causara pérdida de datos?
Detener el lote, preservar la fuente original antigua, identificar los registros afectados y comunicar un cronograma concreto de recuperación. Después de restaurar el servicio, agregar una verificación de conciliación automatizada y revisar los criterios de pase del siguiente lote.
¿Cómo sabes que el proyecto tuvo éxito?
Utiliza métricas de resultados del usuario y métricas operativas en conjunto: éxito en flujos de trabajo críticos, finalización de la migración, volumen de reversiones y soporte, además de las horas de mantenimiento. Un sistema cerrado sin una ruta segura para el usuario no es un retiro exitoso.