Cómo armar el caso de negocio para modernizar el frontend

La dirección aprueba presupuestos para tener menos riesgo, entregas más rápidas y costos predecibles. Esta guía muestra cómo presentar la modernización del frontend en esos términos, con datos de tu propia empresa.

Parte de la decisión

Un gerente de finanzas o un gerente general tiene una decisión que tomar: gastar ahora, o aceptar un costo que crece en silencio. Puede tomarla sin saber qué es AngularJS. Tu trabajo es hacer visibles los dos lados de esa decisión, en los términos que ellos ya usan: dinero, fechas, riesgo y personas.

Un buen caso de negocio cabe en una página y se apoya en cuatro argumentos. Cada uno necesita evidencia de tu propia empresa. Las estadísticas prestadas son fáciles de descartar.

Argumento 1: El costo de esperar

Esperar tiene un precio aunque nada se rompa.

• El código legacy sigue creciendo, porque todavía se le agregan funcionalidades. Cada pantalla que se construye ahí este año es una pantalla por migrar el próximo.
• El trabajo que depende del frontend queda en espera. Ejemplos: una renovación de diseño, un requisito de accesibilidad, una versión adaptada a móviles, una integración nueva.

Cómo obtener tu número. Cuenta las pantallas agregadas a la app legacy en los últimos doce meses. Lista las iniciativas del roadmap que se postergaron o se descartaron por causa del frontend. Pregunta a producto qué se esperaba obtener de ellas.

Argumento 2: El riesgo

Hay tres tipos de riesgo que le importan a la dirección.

• Seguridad y cumplimiento. El software sin soporte genera hallazgos de auditoría y respuestas incómodas en los cuestionarios de clientes. Revisa la guía de seguridad y cumplimiento.
• Operacional. Una actualización del navegador o un cambio en una dependencia puede romper algo que nadie sabe arreglar rápido.
• Conocimiento. Si dos personas entienden el código, la empresa depende de que esas dos personas se queden.

Cómo obtener tu número. Reúne los hallazgos de auditoría y las preguntas de cuestionarios del último año. Pregunta a ventas si alguna negociación se retrasó por una revisión de seguridad. Anota quién puede modificar con seguridad cada módulo crítico.

Argumento 3: Contratación y retención

Los ingenieros prefieren herramientas vigentes. Una vacante que exige un framework abandonado tarda más en llenarse, y quienes se sienten atrapados en él tienden a irse.

Cómo obtener tu número. Pregunta a tu equipo de selección cuánto tiempo quedan abiertas las vacantes de frontend en comparación con otras, y qué dicen los candidatos cuando conocen el stack. Revisa las entrevistas de salida. Averigua cuánto cobran los contratistas con experiencia legacy frente a las tarifas normales.

Argumento 4: La velocidad de entrega

Es el argumento que la dirección siente todos los días y el más difícil de probar. Evita prometer una mejora específica. Muestra, en cambio, el freno actual.

Cómo obtener tu número. Elige algunas funcionalidades recientes de tamaño parecido, unas construidas en código legacy y otras en código moderno, si lo tienes. Compara el tiempo transcurrido y los defectos posteriores. Si todavía no tienes código moderno, el piloto te dará la primera comparación.

Pon las opciones lado a lado

Completa cada celda con tus propias cifras. La guía de opciones describe cada camino, y la guía de costos explica cómo estimar la fila de la migración.

Cómo presentarlo

1. Abre con la decisión. "Tenemos que elegir entre financiar una migración por fases y aceptar estos costos crecientes."
2. Usa dinero, fechas y nombres. Cambia "deuda técnica" por "tres iniciativas del roadmap retrasadas el año pasado" y "dos personas que pueden modificar el módulo de facturación".
3. Pide un primer paso pequeño. Solicita la aprobación de un diagnóstico y un piloto. Es un compromiso acotado y produce la estimación real.
4. Muestra los puntos de aprobación. Cada fase tiene un precio, un resultado y un punto de control. La dirección puede detenerse después de cualquier fase y conservar lo entregado.
5. Di qué no va a cambiar. El mismo producto, las mismas pantallas, sin congelar funcionalidades. Esto quita el miedo a un proyecto largo sin nada que mostrar.

Errores que hunden el caso

• Nombres de frameworks y números de versión en las diapositivas.
• Una sola solicitud grande con una única fecha al final.
• Beneficios tomados de informes de proveedores en lugar de tus propios datos.
• Promesas de productividad con porcentajes inventados.
• No tener respuesta para "¿qué pasa si esperamos un año más?".

Después de la aprobación

Convierte el caso en un plan con fases y puntos de control. La plantilla de hoja de ruta es el paso siguiente. Luego reporta contra ese plan todos los meses, para que quienes aprobaron el presupuesto vean qué se obtuvo con él.

Más en esta sección

• Una hoja de ruta por fases para modernizar el frontend
• Cómo elegir un partner para migrar tu frontend
• Riesgos de una migración de frontend y cómo reducirlos
• El patrón strangler fig aplicado a frontends