Un Forward Deployed Engineer (FDE) combina trabajo con los usuarios e implementación técnica. Aprende cómo se ejecuta un proceso, prueba decisiones con el equipo y adapta el software a esas condiciones. Para contratar este apoyo, me fijaría en las responsabilidades acordadas y en la capacidad de entregar, además del nombre del puesto.
La descripción de Atlassian sobre sus FDE ilustra el trabajo directo con clientes y el retorno de lo aprendido al producto. Ese programa pertenece a su plataforma. En mi caso, el encaje se concreta dentro de mis servicios de automatización e IA aplicada, sobre las herramientas y restricciones de tu empresa.
Cuándo encaja un FDE en tu empresa
Lo consideraría cuando las reglas están repartidas entre personas y sistemas, y hace falta observar el trabajo antes de cerrar el desarrollo. Por ejemplo: operaciones revisa una solicitud en una hoja, consulta otro sistema y devuelve una incidencia por correo. El requisito pendiente puede ser quién tiene autoridad para cambiar un estado, no qué modelo de IA elegir.
- Hay un proceso concreto y alguien del negocio puede resolver dudas y aceptar cambios.
- El equipo aporta ejemplos habituales, excepciones y acceso autorizado a las herramientas necesarias.
- La implementación requiere descubrir reglas con los usuarios y probarlas durante el desarrollo.
- Existe una persona o equipo que podrá recibir la operación del sistema.
Si una configuración de la herramienta actual resuelve el problema, empezaría por ella. Si no hay responsable, acceso o tiempo de los usuarios para revisar, dejaría esas dependencias resueltas antes de comprometer una entrega. La IA es opcional: algunas tareas necesitan reglas o una integración.
FDE, consultoría, desarrollo o CTO externo
Estas funciones se pueden solapar. Un consultor también puede implementar y un desarrollador también puede descubrir requisitos. Compararía el trabajo que cada propuesta asume:
| Necesidad principal | Apoyo que evaluaría | Qué dejar por escrito |
|---|---|---|
| Elegir una dirección o evaluar alternativas | Consultoría técnica | Diagnóstico, decisiones y si incluye implementación |
| Construir un alcance ya definido | Equipo o profesional de desarrollo | Requisitos, pruebas y responsable de aceptación |
| Descubrir y construir junto a operaciones | Ingeniería integrada / FDE | Acceso a usuarios, decisiones de proceso y entrega |
| Coordinar tecnología, equipo y prioridades continuas | CTO externo | Autoridad, dedicación y seguimiento del roadmap |
Si necesitas dirección para varios equipos o proyectos, consulta el alcance de CTO as a Service. Un encargo sobre un proceso no implica asumir toda la dirección tecnológica de la empresa.
Qué acordar antes de empezar
Usaría una ficha breve para delimitar el encargo. Debe permitir decidir si una petición nueva pertenece al trabajo contratado o necesita otra estimación:
- Proceso y frontera: disparador, salida útil, usuarios y pasos que siguen manuales.
- Decisiones: quién define las reglas, quién aprueba excepciones y quién acepta la entrega.
- Accesos: sistemas, entornos, datos autorizados y dependencias de otros proveedores.
- Evidencia inicial: ejemplos representativos, errores actuales y trabajo de revisión.
- Entregables: código, configuración, pruebas, documentación y formación que se incluyen.
- Cambios y continuidad: cómo se revisa el alcance, quién atiende incidencias y qué mantenimiento se contrata aparte.
Si la exploración puede cambiar mucho el presupuesto, separaría diagnóstico y construcción. El diagnóstico debe terminar con una decisión concreta: desarrollar una parte, configurar algo existente o aplazar. Elegir entre agentes y workflows viene después de entender ese límite.
Ejemplo hipotético: solicitudes de cambio de entrega
Imagina que operaciones recibe peticiones por correo y copia cambios a un sistema de reparto. Es un ejemplo de diseño, no un caso de cliente ni un resultado medido. Primero observaría cómo se identifica el pedido, quién autoriza el cambio y qué ocurre cuando ya está en ruta.
Una primera versión podría preparar una solicitud estructurada para revisión. Si falta el identificador o el estado impide el cambio, permanece pendiente. El responsable de operaciones valida las reglas; ingeniería construye la integración y registra la ejecución; la persona autorizada aprueba el cambio. Si la extracción necesita IA, la salida del modelo se valida antes de usarla.
Para revisar la entrega, reproduciría un pedido desconocido, una petición repetida, una autorización rechazada y una caída del sistema externo. Comprobaría que ningún caso produce un cambio silencioso y que el operador entiende cómo continuar. El alcance inicial puede excluir respuestas automáticas al cliente y cambios sin aprobación.
Costes y evidencia para decidir si continuar
El precio depende del tiempo de descubrimiento, integraciones, calidad de los datos, pruebas, despliegue y acompañamiento. También contaría el tiempo del equipo que explica y revisa el proceso, el uso de servicios externos y el mantenimiento posterior. No daría una cifra sin conocer esas condiciones.
Para comparar ofertas, utiliza la guía de presupuestos de software. Una propuesta que solo entrega un prototipo y otra que incluye operación y traspaso no cubren el mismo trabajo.
Antes de ampliar, contrastaría tareas completadas, errores, revisión pendiente y coste operativo con la situación inicial. El registro de ahorro y trabajo restante ayuda a separar capacidad recuperada de gasto realmente reducido. Contratar un FDE no garantiza rentabilidad; una decisión válida puede ser detener o simplificar el proyecto.
Cómo recibir un sistema que el equipo pueda operar
Pediría a la persona que lo recibe que ejecute un caso normal y resuelva una excepción siguiendo la documentación. Revisaría con ella:
- Acceso de la empresa al repositorio, configuración y cuentas de despliegue acordadas.
- Instrucciones para desplegar, parar el proceso y recuperar la versión anterior.
- Registro de ejecuciones, alertas y forma de localizar una solicitud fallida.
- Pruebas reproducibles, limitaciones conocidas y decisiones pendientes.
- Responsable operativo, canal de incidencias y alcance del soporte posterior.
El caso Adslyfy muestra paneles, workers, alertas y capturas para investigar comprobaciones. Es evidencia de ingeniería y visibilidad operativa; no demuestra ahorro por IA ni un encargo FDE para un cliente. Para tu proceso, habría que comprobar la entrega con tus propios casos.
Qué necesito para valorar tu proceso
Dentro de mi trabajo como CTO técnico y constructor de producto, puedo ayudarte a conectar el problema operativo con la implementación. Empezaría por una muestra anonimizada de entrada y salida, las herramientas actuales, una excepción frecuente y quién acepta el cambio.
Si quieres valorar ese alcance, cuéntame el proceso que necesitas resolver. Con esa información podemos decidir qué requiere descubrimiento, qué se puede construir y qué necesita seguir bajo control del equipo.