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.
También ofrezco · Análisis de portafolio de software
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.
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.
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.
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.
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.
No hay arranque hasta que el código compile y se ejecute, los objetivos coincidan y las personas correctas estén agendadas.
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.
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.
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.
El cliente confirma los hallazgos antes de ponerle precio a nada. Después vienen el informe y las opciones.
Todos los clientes reciben el núcleo. Los módulos adicionales entran solo cuando la primera llamada o el primer escaneo indican que importan.
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.
No cambiar nada que vean los usuarios.
Comportamiento idéntico, capacitación mínima y una transición que nadie note.
Trazar los límites con claridad.
Un alcance fijo, dependencias conocidas y una frontera limpia entre su trabajo y el nuestro.
Prepararlos y luego hacerse a un lado.
Las herramientas, una revisión de preparación y una segunda opinión sobre el plan.
La decisión se toma una aplicación a la vez, sin perder de vista el conjunto.
Tamaño, lenguajes, responsables y dependencias de cada aplicación, incluidas las que nadie admite tener a cargo.
El código compartido suele ser una parte grande del total. Cambia el orden de todo, así que se mapea antes de calificar nada.
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.
Migrar, reescribir, reemplazar o mantener. No hacer nada es una respuesta legítima, siempre que tenga fecha.
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.
En el orden en que suelen romperse.
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.
El primer relato es una hipótesis. Cuando el código contradice a la reunión, gana el código y el plan cambia.
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.
Confirme antes de ponerle precio. El cliente aprueba el inventario y los hallazgos, así la estimación descansa sobre hechos que ambas partes aceptan.
La misma disciplina, aplicada cada vez a una pregunta más amplia.
Conteo de líneas, mapeo de controles y esfuerzo por fase. La pregunta era cómo convertir.
Fortalezas junto a los riesgos, escritas para quienes convivirían con el resultado.
Una sola estructura de informe, la preparación para la automatización medida en vez de prometida y cada supuesto por escrito.
Varias opciones de destino lado a lado, transformación de código asistida por IA donde no existe herramienta, y seguridad y cumplimiento mapeados.
El mismo método, sin importar de qué lado de la mesa esté usted.
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.
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.