Modelo de trabajo
Qué es un forward deployed engineer y cuándo lo necesitas
Un forward deployed engineer es un ingeniero que trabaja dentro de la operación del cliente en lugar de recibir requerimientos desde fuera. Observa el proceso real, escribe el código y lo deja funcionando en producción. El modelo se extendió en compañías de software que descubrieron que sus productos no fallaban por falta de capacidad técnica, sino porque nadie había traducido la realidad del cliente en configuración, datos e integraciones.
Sebastián Arango
Fundador de LogVox
31 de julio de 20268 min de lectura
En síntesis
- El forward deployed engineer construye dentro del contexto del cliente, no desde un documento de requerimientos.
- Se diferencia de la consultoría en que entrega sistema funcionando, no recomendaciones.
- Es el modelo adecuado cuando el problema todavía no está bien definido y el proceso real difiere del documentado.
01
Qué hace exactamente un forward deployed engineer
El término viene del inglés forward deployed, usado para describir a alguien destacado en el terreno en lugar de en la sede central. Aplicado a la ingeniería, describe un perfil que combina desarrollo de software con trabajo directo sobre el problema del cliente: pasa tiempo con las personas que ejecutan el proceso, identifica dónde se pierde la información y construye el sistema que lo resuelve.
La diferencia no está en la habilidad técnica sino en dónde ocurre la definición del problema. Un equipo de desarrollo tradicional recibe una especificación y la implementa. Un forward deployed engineer produce esa especificación mientras observa, y la corrige cada vez que la realidad contradice lo que se había supuesto. Por eso el rol solo funciona cuando la misma persona puede decidir y programar: separar ambas cosas devuelve el proyecto al ciclo lento de requerimiento, estimación y entrega.
Observa el proceso real
Trabaja junto al equipo que ejecuta la operación para ver qué ocurre, no qué dice el manual que ocurre.
Define mientras construye
Convierte fricciones observadas en alcance, y ajusta el alcance cuando aparece evidencia nueva.
Integra con lo que ya existe
Conecta el sistema con las herramientas, los datos y los permisos que la empresa ya usa.
Entrega funcionando
El resultado es un sistema en producción con un responsable dentro de la empresa, no un informe.
02
Por qué apareció este rol en proyectos de IA
La inteligencia artificial hizo visible un problema que ya existía: la distancia entre una capacidad genérica y una capacidad útil para una empresa concreta. Un modelo de lenguaje puede redactar, clasificar y decidir, pero no sabe qué significa “cliente activo” en esa empresa, qué descuentos están autorizados ni en qué sistema vive el catálogo vigente.
Ese conocimiento rara vez está documentado. Vive repartido entre las personas que ejecutan el proceso y solo aparece cuando alguien pregunta por un caso específico. Un pliego de requerimientos escrito desde fuera captura la versión oficial del proceso; el trabajo dentro de la operación captura las excepciones, que suelen ser donde el proyecto se cae.
El riesgo típico de un proyecto de IA no es que el modelo falle, sino que resuelva correctamente un problema que nadie tenía.
03
Frente a consultoría y fábrica de software
Cada modelo resuelve una necesidad distinta. La comparación no busca descartar los otros, sino aclarar cuándo rinde cada uno. Una empresa con el problema bien definido y el alcance cerrado suele estar mejor con una fábrica de software.
| Aspecto | Consultoría o fábrica | Forward deployed |
|---|---|---|
| Punto de partida | Un requerimiento o diagnóstico entregado | El proceso observado en funcionamiento |
| Quién define el alcance | Se acuerda antes y se controla por cambios | Se refina durante la construcción con evidencia |
| Entregable | Informe, recomendación o desarrollo especificado | Sistema conectado y operando |
| Contacto con la operación | Reuniones de levantamiento y validación | Trabajo continuo junto al equipo dueño del proceso |
| Cuándo rinde | El problema y el alcance ya están claros | El problema todavía se está descubriendo |
| Riesgo principal | Construir bien la solución equivocada | Alcance difuso si no se fija un resultado verificable |
04
Cuándo conviene este modelo
Hay señales bastante claras de que un proyecto necesita ingeniería desplegada y no una especificación cerrada. Suelen aparecer juntas.
El proceso documentado no es el real
El equipo trabaja con excepciones, atajos y criterios que no están escritos en ningún procedimiento.
Nadie sabe formular el requerimiento
La empresa reconoce la fricción pero no puede traducirla a una especificación técnica sin ayuda.
El conocimiento está disperso
La información necesaria vive en conversaciones, hojas de cálculo y varios sistemas sin una fuente única.
Se necesita evidencia rápida
La decisión de invertir depende de ver el mecanismo funcionando sobre datos reales, no de una propuesta.
05
Cuándo no es el modelo adecuado
El modelo tiene un costo real: exige acceso a la operación, tiempo del equipo del cliente y tolerancia a que el alcance se ajuste durante el camino. Si la empresa necesita un precio cerrado contra una especificación fija, este no es el formato correcto y conviene decirlo antes de empezar.
Tampoco tiene sentido cuando el problema ya está resuelto por un producto estándar. Construir a la medida algo que un SaaS existente cubre añade mantenimiento sin añadir ventaja. La primera pregunta honesta de un proyecto es si hace falta construir.
06
Cómo aplica LogVox este modelo
LogVox trabaja así en los proyectos de LogVox Technology y en los primeros pilotos con Mawo. El recorrido empieza por un diagnóstico de la operación, sigue con un proceso delimitado y termina con un sistema que la empresa puede dirigir, con permisos, aprobaciones y evidencia de lo que ocurrió.
- 01
Diagnóstico de la operación
Se identifica dónde vive el conocimiento, qué conversaciones activan procesos y cuál es el primer resultado que conviene demostrar.
- 02
Un recorrido delimitado
Se elige un proceso con dueño, reglas explicables y un resultado verificable, no una transformación completa.
- 03
Construcción conectada
El sistema se integra con las herramientas y los datos donde la operación ya sucede, con permisos mínimos.
- 04
Entrega dirigible
La empresa recibe la capacidad funcionando, con contrato de autoridad, trazabilidad y una ruta de expansión.
07
Preguntas frecuentes
- ¿Qué es un forward deployed engineer?
- Es un ingeniero que trabaja dentro de la operación del cliente en lugar de recibir requerimientos desde fuera: observa el proceso real, define el alcance mientras construye y deja el sistema funcionando en producción. Combina desarrollo de software con el trabajo de traducir la realidad del negocio en configuración, datos e integraciones.
- ¿Cuál es la diferencia entre un forward deployed engineer y un consultor?
- El consultor entrega diagnóstico y recomendaciones; el forward deployed engineer entrega un sistema operando. La diferencia práctica está en quién define el alcance: el consultor lo acuerda antes y lo controla por cambios, mientras que el forward deployed engineer lo refina durante la construcción cada vez que la operación contradice lo que se había supuesto.
- ¿Cómo se dice forward deployed engineer en español?
- No existe una traducción establecida. Se usan expresiones como ingeniero de despliegue, ingeniero desplegado en cliente o ingeniería embebida en la operación. En la práctica el término suele mantenerse en inglés incluso en equipos hispanohablantes, igual que ocurrió con product manager o site reliability engineer.
- ¿Cuándo necesita una empresa un forward deployed engineer?
- Cuando el proceso documentado no coincide con el real, nadie dentro de la empresa puede formular el requerimiento técnico, el conocimiento está disperso entre conversaciones y sistemas, o la decisión de invertir depende de ver el mecanismo funcionando sobre datos reales. Si el problema y el alcance ya están claros, una fábrica de software suele ser más eficiente.
- ¿Por qué este rol se volvió común en proyectos de inteligencia artificial?
- Porque un modelo de IA aporta capacidad genérica, pero el valor aparece al conectarlo con el contexto específico de una empresa: qué significa cada dato, qué está autorizado y dónde vive la información vigente. Ese conocimiento rara vez está documentado, así que capturarlo exige trabajar dentro de la operación y no desde un pliego de requerimientos.