El ciclo de un despliegue FDE: de discovery a producción (con plantillas)

Saber qué es un FDE está bien; saber cómo trabaja es lo que te diferencia en una entrevista y en tu primer proyecto. Esta guía recoge un método en seis fases, con las preguntas, los entregables y las señales de alerta de cada una. No es el proceso oficial de ninguna empresa: es una síntesis práctica que puedes adaptar.

Cómo usar esta guía. Si estás preparando entrevistas, léela entera: los casos de decomposition siguen casi exactamente estas fases. Si ya trabajas como FDE, copia las plantillas y ajústalas a tu empresa.

La idea que lo ordena todo

Un despliegue no termina cuando el código funciona, sino cuando el cliente obtiene un resultado medido y puede mantenerlo sin ti. Cada fase existe para reducir un riesgo concreto:

Las duraciones son orientativas y varían muchísimo según el cliente y el producto.

Fase 0. Preparación

Antes de la primera reunión:

• Lee lo que se ha firmado o prometido: contrato, propuesta, notas del equipo comercial. Lo que el cliente cree que ha comprado es tu punto de partida.
• Haz un mapa de personas: quién paga (sponsor), quién usará la solución, quién puede bloquearla (IT, seguridad, legal, comité de empresa) y quién conoce de verdad el proceso.
• Pide acceso pronto. Cuentas, VPN y permisos sobre datos son el cuello de botella número uno de casi cualquier despliegue enterprise.

Fase 1. Discovery

Objetivo: entender el problema real, no el que viene escrito en la petición.

Preguntas que funcionan

Negocio

• ¿Qué pasa si no hacemos nada en los próximos seis meses?
• ¿Cómo sabremos dentro de tres meses que esto ha sido un éxito? ¿Quién lo va a juzgar?
• ¿Cuánto cuesta hoy este proceso, en horas, dinero o errores?

Proceso

• Enséñame cómo lo haces hoy, paso a paso, con un caso real.
• ¿Cuál es el caso más habitual? ¿Y el más raro que te encontraste el mes pasado?
• ¿Dónde se atasca? ¿Qué parte haces a mano aunque «no debería»?

Datos y sistemas

• ¿Dónde viven los datos? ¿Quién es su responsable? ¿Con qué frecuencia cambian?
• ¿Puedo ver 20 ejemplos reales, incluidos los difíciles?
• ¿Qué sistemas tendríamos que leer o escribir? ¿Tienen API?

Riesgos y restricciones

• ¿Hay datos personales o sensibles? ¿Qué dice el equipo de protección de datos?
• ¿Qué no puede fallar nunca? ¿Qué pasa si la solución se equivoca?
• ¿Quién tiene que dar el visto bueno para salir a producción?

Técnicas

• Observar antes de preguntar. Media hora viendo trabajar a alguien vale más que tres reuniones.
• Pedir ejemplos, no opiniones. «Normalmente tardamos mucho» no sirve; «este expediente tardó once días por esto» sí.
• Separar síntoma, causa y deseo. «Queremos un chatbot» es un deseo; «los agentes tardan 8 minutos en encontrar la póliza» es una causa medible.

Entregable: mapa del problema

Una página con el proceso actual, los puntos de dolor cuantificados, los datos disponibles y entre tres y cinco casos de uso candidatos.

Señales de alerta: nadie sabe decir cómo se mide el éxito; el sponsor no ha hablado con quienes usarán la solución; «los datos los tenemos» pero nadie te los enseña.

Fase 2. Acotar el primer entregable

Objetivo: elegir lo mínimo que demuestra valor y ponerlo por escrito.

Prioriza los casos de uso con cuatro criterios: impacto (cuánto valor si sale bien), viabilidad (¿es técnicamente posible con lo que hay?), datos (¿existen y puedo acceder a ellos?) y sponsor (¿hay alguien con poder que lo quiera de verdad?). Si falla uno de los cuatro, no es el primer caso de uso.

Plantilla: documento de alcance de una página

Problema: [qué duele, a quién y cuánto cuesta hoy]
Usuarios: [quién lo usará y con qué frecuencia]
Alcance: [qué hará la primera versión, en 3-5 puntos]
Fuera de alcance: [lo que NO haremos ahora, explícitamente]
Métrica de éxito: [una métrica principal + línea base actual + objetivo]
Datos y sistemas: [fuentes, accesos necesarios, responsables]
Riesgos: [técnicos, de datos, de adopción, regulatorios]
Plan: [hitos semanales hasta la primera versión en producción]
Responsables: [quién decide en el cliente, quién en nuestro equipo]

La sección «Fuera de alcance» es la más importante. Te protege a ti, al cliente y a la relación.

Fase 3. Construir y evaluar

Objetivo: demostrar que funciona con datos reales, no en una demo.

Tres principios:

1. Datos reales desde el primer día. Un prototipo con datos inventados no te dice nada.
2. Evaluar antes de enseñar. Antes de la primera demo, ten un conjunto de casos con la respuesta esperada y mide. Así la conversación pasa de «parece que va bien» a «acierta en 41 de 50; fallos en estos tres tipos de caso».
3. Iterar cada semana con el usuario. Una demo corta cada semana, con casos reales y fallos incluidos, genera más confianza que una gran demo al final.

Plantilla: plan de evaluación

Qué medimos: [p. ej., respuesta correcta, extracción completa, tono adecuado]
Conjunto de evaluación: [nº de casos, de dónde salen, quién valida las respuestas]
Cómo puntuamos: [exacto / rúbrica / revisión humana / modelo como juez + muestreo humano]
Umbral para producción: [p. ej., ≥ 90 % en casos comunes y 0 errores graves]
Casos críticos: [los que no pueden fallar nunca]
Cuándo se repite: [en cada cambio de prompt, modelo o datos]

Formato de la demo semanal (20 minutos)

1. Qué prometimos la semana pasada y qué hemos hecho (2 min).
2. Demo con casos reales, incluido uno que falla (8 min).
3. Métricas de evaluación y su evolución (3 min).
4. Decisiones que necesitamos del cliente (5 min).
5. Plan de la semana siguiente (2 min).

Fase 4. Llevar a producción

Objetivo: que la solución aguante el día a día del cliente sin que tú estés mirando.

Checklist antes de salir a producción

• Autenticación integrada con la del cliente (SSO) y permisos por rol.
• Datos personales tratados según el RGPD y lo acordado con el delegado de protección de datos.
• Revisado con el cliente si el caso de uso tiene obligaciones específicas en el Reglamento Europeo de IA.
• Secretos y credenciales fuera del código.
• Logs y trazas suficientes para reconstruir por qué la solución hizo lo que hizo.
• Monitorización y alertas: errores, latencia, coste y calidad.
• Plan B cuando la IA no sabe: escalado a una persona o respuesta segura.
• Límites de coste y de uso.
• Runbook: qué hacer si falla, a quién llamar y cómo volver atrás.
• Evaluación superada con el umbral acordado.
• Visto bueno formal de quien tiene que darlo (IT, seguridad, negocio).

Fase 5. Adopción e impacto

Objetivo: que la gente lo use y que el impacto se pueda demostrar.

• Forma a los usuarios con sus propios casos, no con una presentación genérica.
• Mide uso semanal y pregunta a quien no lo usa por qué.
• Compara contra la línea base de la fase 2. Sin línea base no hay impacto demostrable.

Plantilla: informe de impacto

Resumen en una frase: [p. ej., «el tiempo medio por expediente baja de 11 a 4 minutos»]
Métrica principal: línea base → hoy (periodo, nº de casos)
Adopción: usuarios activos / usuarios previstos, tendencia semanal
Calidad: resultados de la evaluación y errores detectados en producción
Coste: coste de operación frente al ahorro
Qué sigue: siguientes casos de uso propuestos

Fase 6. Traspaso y retorno al producto

Objetivo: que el cliente pueda seguir sin ti y que tu empresa aprenda de lo que has hecho.

Traspaso al cliente o al equipo de soporte

• Documentación de arquitectura, decisiones y limitaciones conocidas.
• Runbook probado por alguien que no seas tú.
• Responsables nombrados en el cliente para cada parte.
• Sesión de traspaso grabada.

Nota de campo para producto. Lo que resolviste a mano y probablemente se repetirá en otros clientes:

Contexto: [cliente, sector, caso de uso]
Qué faltaba en el producto: [funcionalidad, integración, configuración]
Cómo lo resolvimos: [solución de campo, con enlace al código]
¿Se repetirá?: [otros clientes con el mismo patrón]
Propuesta: [funcionalidad o cambio concreto]

Este último paso es el que convierte a un FDE en un multiplicador en lugar de un consultor caro.

Comunicación durante todo el proyecto

Un estado semanal corto, siempre el mismo día, evita la mayoría de sustos:

Estado: 🟢 / 🟡 / 🔴  (y por qué, en una frase)
Hecho esta semana: …
Próxima semana: …
Riesgos y bloqueos: … (quién puede desbloquearlo y para cuándo)
Decisiones que necesitamos: …

Escala pronto. Un riesgo comunicado con dos semanas de margen es un problema de planificación; comunicado el día de la entrega, es un problema de confianza.

Errores típicos

• Construir antes de entender: aparece en casi todas las entrevistas de decomposition y en casi todos los proyectos que fracasan.
• Enseñar demos sin evaluación: la primera vez que falla delante del sponsor se pierde la confianza.
• Aceptar alcance nuevo sin quitar nada.
• No medir la línea base al principio: luego es imposible demostrar el impacto.
• Ser el único que sabe cómo funciona la solución.

Siguiente paso

Practica estas fases con un caso en voz alta: es justo lo que te pedirán en la entrevista de decomposition.

Fuentes y lecturas

• Palantir: A Day in the Life of a Palantir Forward Deployed Software Engineer, sobre revisiones de código, despliegue y la vuelta al producto de las soluciones de campo.
• Insight Partners: Demystifying Forward Deployed Engineers, sobre trabajar por resultados y diseñar el rol para irse.
• Las plantillas son del FDE Club y puedes reutilizarlas libremente.