Robert Encarnacao Liderazgo en transformación con IA

También ofrezco · Análisis de portafolio de software

Toda estimación de modernización es una conjetura hasta que alguien lea el código.

Los programas de modernización se aprueban con base en un relato: qué hace el sistema, qué tan malo es el código, cuánto tardaría una reescritura. El relato suele estar equivocado en dos o tres puntos que importan, y nadie se entera hasta que el presupuesto ya se gastó.

Este es un servicio que ofrezco junto a mi trabajo principal, el liderazgo en transformación con IA. Nace de quince años dirigiendo las evaluaciones que vienen antes del dinero: de dos a cuatro semanas leyendo el código, sesiones de trabajo con las personas que conviven con él y una decisión que ambas partes pueden defender. Aplicaciones individuales y portafolios completos, desde VB6 y PowerBuilder hasta suites de millones de líneas.

Si está decidiendo qué hacer con sus sistemas legados, así es como yo dirigiría la evaluación. El panel muestra cómo se hace el triaje de un portafolio, y qué cambia una vez que se lee el código.

Para quién es
Líderes que deciden qué modernizar Fabricantes de software con un producto que envejece Equipos que heredaron sistemas legados Responsables de contratación que quieren ver cómo trabajo
Tres pasos · 60 segundos

Adónde debe ir cada aplicación, y por qué la primera respuesta suele estar equivocada

Aplicaciones
8
Movidas por la evidencia
Aún no
Decidido por
Migrar0
Reescribir0
Reemplazar0
Mantener0
    Tres preguntas, en este orden, para cada aplicación. El orden importa tanto como las respuestas.

    Seis pasos, dos compuertas

    Los pasos nunca cambian. Lo que va en ellos se adapta a la empresa, a las personas en la sala y al proyecto que sigue.

    Antes del arranque
    Primera llamada01

    Calificar la pregunta

    Quién es dueño del código, qué hace, hacia dónde lo quieren llevar, cuánta ayuda quieren y quién firma. Siete preguntas siempre, y luego todo el contexto que la conversación permita.

    Usted obtiene
    Un resumen de calificación y una lectura clara de qué tipo de decisión es esta.
    Antes de la firma02

    Poner el alcance por escrito

    Qué aplicaciones, de qué tamaño, qué pantallas tendrán prueba de concepto, cuánto dura y cuánto cuesta. Todo lo que quede vago aquí se convierte en una discusión en la tercera semana.

    Usted obtiene
    Un alcance firmado, con un tope de tamaño y un objetivo para la prueba de concepto.
    Antes del arranque03

    Alinear tres objetivos

    El objetivo de la empresa, el de cada parte interesada y la decisión que la evaluación debe respaldar, contrastados entre sí. Luego la incorporación, las personas correctas agendadas y un primer escaneo del código antes de que nadie se reúna.

    Usted obtiene
    Un mapa de partes interesadas, agendas de sesión a la medida y un primer escaneo.
    Compuerta 1

    No hay arranque hasta que el código compile y se ejecute, los objetivos coincidan y las personas correctas estén agendadas.

    La evaluación
    Día 104

    Arrancar con las dudas sobre la mesa

    Por qué ahora, qué se ha intentado antes, cómo se ve el éxito y quién está en contra sin decirlo. Confirmar la agenda y qué módulos adicionales aplican.

    Usted obtiene
    Objetivos acordados, criterios de éxito y una agenda que todos han visto.
    Semana 105

    Trabajarlo con quienes saben

    Una demostración técnica rápida, no una capacitación. Arquitectura actual, pruebas y liberación, la plataforma destino y las restricciones del negocio, con un punto de control al final de cada día.

    Usted obtiene
    Notas de sesión: qué se confirmó y qué sigue abierto.
    Semanas 1 – 306

    Leer el código

    Escaneos automatizados de todo el código, una migración de prueba, una prueba de concepto en las pantallas más difíciles y un análisis manual a fondo dondequiera que esté de verdad el riesgo.

    Usted obtiene
    Un inventario, calificaciones de complejidad y de preparación, una estrategia por componente y los riesgos.
    Compuerta 2

    El cliente confirma los hallazgos antes de ponerle precio a nada. Después vienen el informe y las opciones.

    Mismos pasos, distintas preguntas

    Todos los clientes reciben el núcleo. Los módulos adicionales entran solo cuando la primera llamada o el primer escaneo indican que importan.

    El núcleo, siempre
    • Contexto del negocioObjetivos, por qué ahora, qué se ha intentado, quién decide
    • Entorno y accesoCódigo que compila y se ejecuta, herramientas instaladas, fuentes completas
    • Aplicación y usuariosQué hace, quién la usa, las pantallas más difíciles
    • El código baseTamaño, lenguajes, código compartido y código muerto, dependencias
    • Arquitectura e integracionesAcceso a datos, sistemas externos, componentes de terceros
    • Pruebas y liberaciónActivos de prueba, cobertura, cadencia de liberaciones, qué tan rápido cambia el código
    • Destino y estándaresStack, versiones, rumbo de la interfaz, quién aprueba
    • Restricciones del proyectoPlazos, personas, despliegue, regulación
    Módulos adicionales, cuando importan
    • Código nativo y a la medidaCapas en C y C++, bibliotecas propias, pantallas generadas a partir de metadatos
    • ReportesMotores de reportes, y la lógica de negocio escondida en ellos
    • Datos y esquemas compartidosOtros sistemas que leen y escriben las mismas tablas
    • Seguridad y cumplimientoPatrones de vulnerabilidad, secretos en el código, la regulación vigente
    • Experiencia de usuario y flujo de trabajoLos hábitos a los que los usuarios avanzados no van a renunciar
    • Líneas base de rendimientoTiempos de las transacciones que importan, antes de mover nada
    • Destinos alternativosMás de un destino, comparados lado a lado

    Quién compra cambia el énfasis

    Un fabricante de software

    Proteger la hoja de ruta.

    La cadencia de liberaciones, lo que notarán los clientes y un equipo que sigue entregando mientras la plataforma cambia.

    Una empresa

    No cambiar nada que vean los usuarios.

    Comportamiento idéntico, capacitación mínima y una transición que nadie note.

    Un integrador

    Trazar los límites con claridad.

    Un alcance fijo, dependencias conocidas y una frontera limpia entre su trabajo y el nuestro.

    Un equipo que lo hace por su cuenta

    Prepararlos y luego hacerse a un lado.

    Las herramientas, una revisión de preparación y una segunda opinión sobre el plan.

    Cuando es un portafolio, no una aplicación

    La decisión se toma una aplicación a la vez, sin perder de vista el conjunto.

    1. 1

      Inventariar todo

      Tamaño, lenguajes, responsables y dependencias de cada aplicación, incluidas las que nadie admite tener a cargo.

    2. 2

      Mapear lo compartido

      El código compartido suele ser una parte grande del total. Cambia el orden de todo, así que se mapea antes de calificar nada.

    3. 3

      Hacer tres preguntas

      Qué tan única es para el negocio, qué tan rápido debe cambiar y qué tan sólido es el código. En ese orden.

    4. 4

      Decidir el destino

      Migrar, reescribir, reemplazar o mantener. No hacer nada es una respuesta legítima, siempre que tenga fecha.

    5. 5

      Ordenar las olas

      Primero el código compartido, el trabajo más largo arrancado temprano y el resto en paralelo hasta donde lo permita la capacidad de pruebas.

    El panel de arriba ejecuta los pasos tres a cinco sobre una muestra de ocho aplicaciones. Pruébelo usted.

    Cuatro reglas con las que evalúo

    En el orden en que suelen romperse.

    I

    No hay arranque antes de que el código funcione. Una evaluación que empieza sin código que compile y sin fuentes completas gasta su presupuesto esperando.

    II

    El primer relato es una hipótesis. Cuando el código contradice a la reunión, gana el código y el plan cambia.

    III

    Alinee los objetivos antes de la primera sesión: los de la empresa, los de cada parte interesada y los de la propia evaluación. De lo contrario, el informe responde la pregunta equivocada.

    IV

    Confirme antes de ponerle precio. El cliente aprueba el inventario y los hallazgos, así la estimación descansa sobre hechos que ambas partes aceptan.

    Cómo ha cambiado el método

    La misma disciplina, aplicada cada vez a una pregunta más amplia.

    1. 2014

      Primero el código

      Conteo de líneas, mapeo de controles y esfuerzo por fase. La pregunta era cómo convertir.

    2. 2017

      Las personas en la sala

      Fortalezas junto a los riesgos, escritas para quienes convivirían con el resultado.

    3. 2023

      Un solo estándar

      Una sola estructura de informe, la preparación para la automatización medida en vez de prometida y cada supuesto por escrito.

    4. 2025

      Modernización, no conversión

      Varias opciones de destino lado a lado, transformación de código asistida por IA donde no existe herramienta, y seguridad y cumplimiento mapeados.

    Para leer más (en inglés)
    15
    Años liderando modernización de cara al cliente
    38
    Empresas Fortune 500 asesoradas
    20M+
    Líneas de código evaluadas
    8
    Tecnologías de origen, de VB6 a Informix 4GL

    Dos maneras de usar esto

    El mismo método, sin importar de qué lado de la mesa esté usted.

    Si está modernizando

    Envíeme la lista

    Las aplicaciones que está evaluando, aunque sea una lista aproximada con tamaños y lenguajes. Usted recibe por escrito mi lectura de dónde miraría primero, haya o no algo después.

    Si está contratando

    Pídame que defienda cualquier paso

    Elija un paso o una regla de esta página y pregúnteme qué pasa cuando alguien se lo salta. Treinta minutos bastan para saber si así es como quiere que se haga el trabajo.