FinTechSep 9, 202610 min de lectura

Contratar ingenieros o traer un socio técnico: cómo calcular el coste de ambas vías

Equipos de ingenieríaTerminal de tradingModelos de entregaPropiedad del código
Error al cargar la imagen

Tienes la idea de producto de un terminal de trading, presupuesto y ningún equipo de ingeniería. Contratar uno y contratar a un socio para que lo construya no son dos precios de lo mismo: reparten el tiempo, el conocimiento y el riesgo de otra manera. Esto es lo que te cobra cada vía, lo que tiene que haber en el traspaso y lo que tienes en la mano el día en que el trabajo se detiene.

Tienes la idea de un terminal de trading, presupuesto para él y ningún equipo de ingeniería. La pregunta que viene después casi siempre se plantea como una comparación de precios: cuánto cuesta contratar ingenieros y cuánto cuesta que una empresa lo construya y te lo entregue.

Ese planteamiento esconde la decisión. Las dos vías terminan con código que funciona. Se diferencian en cuándo existe la primera versión utilizable, quién entiende el sistema un año después, qué pasa cuando se va una persona clave y qué tienes en la mano si el trabajo se detiene.

La respuesta corta: compara las dos vías por cuatro cosas y no por la tarifa - el tiempo hasta una versión que puedas poner delante de un trader, dónde vive el conocimiento del sistema, qué sobrevive a una marcha y qué te pertenece el día en que el trabajo se detiene. Una vía que gana en tarifa y pierde en las cuatro es la más cara.

Las dos vías producen código; se diferencian en dónde vive el conocimiento

Un terminal de trading no es un solo sistema. Es una ruta de datos de mercado, una ruta de entrada de órdenes, verificaciones de riesgo pre-trade, conectividad con venues o brókers, estado de posiciones y cuentas, una pantalla que debe seguir redibujándose mientras el libro se mueve, y un back office que lo concilia todo tras el cierre.

Cuando contratas, no compras ese sistema. Construyes la organización que lo va a producir, y el conocimiento de cómo funciona parte de cero y se acumula en las cabezas de las personas que empleas. Es un activo mientras se quedan y es todo el riesgo cuando no.

Cuando contratas a un socio, compras un sistema más un historial de decisiones que ya existe en otro sitio. El conocimiento parte de un nivel más alto y el primer día está fuera de tu empresa. Que llegue a entrar es una cláusula del contrato y una práctica de trabajo, no algo que ocurra solo.

Conviene ser concreto sobre qué significa aquí el conocimiento del sistema, porque no es el código fuente:

  • Por qué el esquema de secuenciación es el que es, y qué fallo rechaza que un esquema más simple aceptaría
  • Qué comportamientos del venue sortea la capa de conectividad, y de qué incidente salió cada solución alternativa
  • El orden en que se ejecutan las verificaciones de riesgo, y qué hace el sistema cuando una de ellas no responde a tiempo
  • El procedimiento de recuperación cuando el feed de datos de mercado tiene un gap y hay que reconstruir el libro a mitad de sesión
  • Qué pruebas son estructurales y cuáles solo parecen cobertura
  • Cuál es la ruta de despliegue en una mañana volátil, y quién tiene permiso para ejecutarla

Nada de eso vive en un repositorio por defecto. Vive en una persona hasta que un proceso lo obliga a pasar al papel, sea esa persona tu empleado o un ingeniero del socio.

La primera versión utilizable se decide antes del primer commit

La vía de contratar tiene delante una cola que el presupuesto no elimina. Escribes un puesto que puedas defender técnicamente, buscas candidatos en un mercado donde escasean los ingenieros de trading, entrevistas por competencias que dentro de tu empresa nadie sabe aún evaluar, esperas los preavisos y luego pasas el primer tramo viendo cómo un equipo nuevo discute sobre una arquitectura en vez de construirla.

La vía del socio empieza por el alcance en lugar de por la búsqueda de gente, y de ahí viene la diferencia de tiempo. Lo que no elimina es el trabajo que solo tú puedes hacer: decidir para qué sirve el terminal, qué instrumentos y qué venues importan primero, y quiénes son los primeros usuarios.

Y una parte del calendario no pertenece a ninguna de las dos vías. Estos elementos van a su propio ritmo, sin importar quién escriba el código:

  • El alta con el bróker o el venue, y el papeleo que hay detrás
  • Pruebas de conformidad en el entorno de pruebas del venue, en ventanas que fija el venue y no tú
  • Las licencias de datos de mercado, que deciden qué puedes mostrar y a quién puedes redistribuirlo
  • Sincronización de reloj, pistas de auditoría y el registro documental que exija tu regulador
  • Que los primeros usuarios estén dispuestos a enrutar órdenes reales por un sistema que es nuevo
  • Tus propias decisiones de producto, sobre todo las dos que se contradicen entre sí

Así que la comparación honesta no es una carrera entre dos fechas de entrega. Es la pregunta de qué vía pone menos cosas fuera de tu control por delante del trabajo, y cuál empieza antes las partes en las que sí influyes.

Qué hace cada vía cuando se va una persona clave

Haz la misma pregunta a las dos vías. Si el ingeniero que escribió el handler de datos de mercado deja de trabajar el lunes, qué pasa el martes, y qué pasa en el trimestre siguiente.

En un equipo pequeño que has contratado, la respuesta suele depender de un solo nombre. Los equipos iniciales concentran el conocimiento por diseño: una persona es dueña del hot path, otra de la conectividad, y el roadmap se reorganiza en silencio en torno a quien sigue ahí. Con un socio depende de si más de un ingeniero de su lado ha leído el código, y de si tu contrato lo exige.

Ninguna de las dos estructuras es segura por sí misma. Un socio con un único ingeniero en tu cuenta está tan expuesto como un equipo interno de dos personas, y la defensa es idéntica en ambos casos: conocimiento escrito mientras se crea, y no reconstruido después.

  • Una nota de diseño por subsistema que indique qué hace, qué se niega a hacer deliberadamente y qué lo rompe
  • Registros de decisiones con las alternativas que se consideraron, guardados en el repositorio junto al código que explican
  • Pruebas que reproducen una sesión capturada, de modo que un fallo se reproduce exactamente en lugar de discutirse
  • Al menos dos personas que hayan integrado cambios en cada ruta crítica - una regla de dotación de personal, no de documentación
  • Un runbook para cada incidente que realmente ha ocurrido, escrito la misma semana en que ocurrió
  • Una ruta de despliegue y rollback que cualquier ingeniero de guardia puede ejecutar sin despertar a nadie para pedir una contraseña

Una prueba de aceptación que sirve para cualquiera de las dos vías: toma a un ingeniero que nunca ha visto el sistema, dale la documentación y una máquina limpia, y pídele que levante el terminal en un entorno de pruebas y coloque una orden. Todo lo que tenga que preguntarle a una persona es conocimiento que todavía no posees.

El traspaso es un entregable con prueba de aceptación, no un correo al final

La palabra traspaso cubre dos hechos muy distintos. Uno es una transferencia de archivos. El otro es la transferencia de la capacidad de seguir adelante sin las personas que lo construyeron, y solo por el segundo merece la pena pagar.

Escribe el segundo en el alcance como una lista de artefactos, cada uno con su prueba de aceptación. Una lista razonable tiene este aspecto:

  • Repositorios con su historia completa, no un archivo del estado final - en la historia es donde está el razonamiento
  • Una build que un ingeniero nuevo reproduce en una máquina limpia siguiendo los pasos escritos, sin configuración local no documentada
  • Infraestructura descrita como código, junto con los entornos que produce y en qué se diferencian
  • Los secretos en tu poder, con un procedimiento de rotación que se ha ejecutado al menos una vez, no solo descrito
  • Runbooks de despliegue y rollback, ejecutados por tu lado mientras el socio mira y no dice nada
  • Monitorización, umbrales de alerta y una línea por alerta que explique qué significa y qué hacer al respecto
  • Especificaciones de protocolo y de mensajes para cada conexión externa, incluidos los campos que usas y los que ignoras
  • La suite de pruebas, más una demostración de pruebas fallando a propósito, para que veas qué detectan
  • Un periodo acordado en el que tus ingenieros hacen los cambios y el socio solo los revisa

Un traspaso que nunca se ha ensayado es un plan, no un entregable. Ensáyalo a mitad de la construcción, no después de la factura final, y el ensayo es sencillo: tus ingenieros despliegan un cambio y lo revierten mientras quienes escribieron el sistema miran.

La propiedad es una cuestión distinta del traspaso, y se cierra en el contrato antes de empezar el trabajo, no se descubre al final. Nuestra respuesta cabe en una frase, y no la acortamos en ninguna versión de ningún documento.

El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables. Esa excepción es la parte que hay que leer con lupa con cualquier socio, el nuestro incluido: pregunta cuáles son los componentes reutilizables, en qué términos los sigues usando, si el sistema compila sin nada que no puedas reconstruir por ti mismo, y qué pasa con esos componentes si la colaboración entre los dos termina.

Entre las dos respuestas hay tres formatos

La pregunta suele plantearse como algo binario - contratar un equipo o entregarle todo a otro. En la práctica la mayoría de los proyectos quedan entre esos dos polos, y esa posición puede cambiar a medida que el sistema madura.

Tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. Así describimos nuestra parte, y la diferencia entre los tres no es la factura - es quién lleva el plan, quién lleva las prioridades y quién responde por el resultado.

  • Entrega completa: el socio se encarga del plan, del orden de los trabajos y del resultado; tú te encargas de las decisiones de producto y de la aceptación. Encaja en una primera versión con un alcance que puedes definir y sin equipo que gestionar todavía
  • Equipo dedicado: tu backlog y tus prioridades, su gente trabajando en tu producto y en nada más. Encaja en la etapa en la que el alcance se mueve más rápido de lo que tolera un plan fijo
  • Ingenieros integrados en tu equipo: tu proceso, tu code review, sus especialistas en las rutas donde un error sale caro - la ruta de órdenes, la conectividad con los venues, el procedimiento de recuperación
  • Los tres son pasos más que opciones excluyentes. Un proyecto puede empezar como entrega completa y terminar con dos ingenieros dentro de un equipo que contrataste mientras se escribía el sistema

Ese último punto disuelve buena parte de la pregunta inicial. La versión más sólida de la vía del socio contempla tu propio equipo desde el principio: contratas contra un sistema que ya existe, tus entrevistas se apoyan en el código que el candidato va a mantener, y lo primero que lee alguien recién incorporado es un registro de decisiones y no un repositorio en blanco.

Calcula el coste de ambas vías, incluido lo que nunca aparece en una factura

Comparar tarifas es el número menos útil de esta decisión, porque las dos vías te facturan en unidades distintas. Pon ambas listas una al lado de la otra y calcula su coste con honestidad.

La vía de contratar te cobra por:

  • El tiempo de reclutamiento, y el coste de una contratación equivocada en un mercado de especialistas donde el error se descubre tarde
  • Costes de empleador, equipamiento, licencias y las suscripciones de datos de mercado que un entorno de desarrollo necesita antes de producir nada
  • Atención de gestión - alguien tiene que dirigir el equipo, y al principio ese alguien sueles ser tú
  • La primera decisión de arquitectura tomada dos veces, una de ellas mal, que es el precio normal de un equipo que aprende un dominio sobre tu proyecto
  • Capacidad que sobrevive a la construcción, cuando un equipo dimensionado para construir es mayor de lo que exige el mantenimiento
  • Una obligación permanente que sigue haya o no un roadmap claro este trimestre

La vía del socio te cobra por:

  • Una tarifa que incluye especialistas que por tu cuenta nunca mantendrías ocupados a tiempo completo, como un ingeniero que ya ha depurado un protocolo a nivel de sesión
  • La coordinación a través de una frontera, que es trabajo real y se paga en especificaciones escritas y no en conversaciones de pasillo
  • Una dependencia que dura exactamente lo que el traspaso siga sin probarse
  • El riesgo de que los componentes reutilizables sean estructurales de formas que nadie dejó por escrito, y por eso la cláusula de propiedad hay que leerla antes de firmar
  • El coste de especificar: un socio es tan preciso como las decisiones que le entregas

Después calcula el coste de las salidas, porque las dos vías tienen una. La vía de contratar termina reduciendo un equipo que construiste, y el conocimiento se va en esas cabezas. La vía del socio termina con un traspaso que ensayaste o no ensayaste, y la distancia entre esos dos finales es el riesgo de la vía.

Antes de firmar nada, pasa las dos opciones por una sola pregunta: si esto se detuviera el viernes, ¿qué seguiríamos teniendo el lunes? Respóndela en artefactos - repositorios, entornos reproducibles, documentación y personas capaces de reconstruir el sistema a partir de ellos -, porque las intenciones no sobreviven a una marcha y los artefactos sí.

Lo que amBrain puede sustentar públicamente: llevamos construyendo software desde 2019 en Ereván, Armenia, con los hot paths escritos en Rust, construimos el terminal de trading Spectre Trade, y un mini-exchange que construimos funciona en producción en la colocación de MOEX. Si estás sopesando contratar frente a trabajar con un socio para un terminal propio, lleva la lista de traspaso de arriba a la primera conversación y pide a quien tengas enfrente, nosotros incluidos, que la responda línea por línea.

¿Tiene un diseño así sobre la mesa?

Traiga su arquitectura actual y el modo de fallo que le preocupa, y lo repasaremos juntos en media hora.

Artículos relacionados

Error al cargar la imagen
FinTech
Sep 9, 202610 min de lectura

Datos de mercado L2 bajo ráfagas: gaps de secuencia, recuperación y fan-out a cientos de sesiones

Leer artículo
Error al cargar la imagen
FinTech
Sep 8, 20269 min de lectura

Diseñar un matching engine en Rust: prioridad precio-tiempo sin pausas de GC

Leer artículo
Error al cargar la imagen
FinTech
Sep 8, 20268 min de lectura

Verificaciones de riesgo pre-trade dentro de la ruta de la orden

Leer artículo