Tech Race: Por qué los departamentos de negocios e ingeniería deben planificar juntos
Antes de la Tech Race Summit 2026, Sergey Kastsukevich, director de tecnología de SOFTSWISS, comparte sus ideas sobre el equilibrio fundamental entre el crecimiento empresarial y la escalabilidad de la ingeniería en la industria del juego.
Opinión.- Todo operador quiere lanzar sus productos más rápido, entrar rápidamente en nuevos mercados y presentar nuevas funciones antes que la competencia.
Los equipos de ingeniería quieren exactamente lo mismo. La diferencia es que ellos también son responsables de garantizar que la plataforma siga funcionando seis meses después.
Esa diferencia de perspectiva genera una de las mayores tensiones dentro de las empresas tecnológicas. El área comercial, naturalmente, se enfoca en el crecimiento y la velocidad. El área de ingeniería debe considerar la escalabilidad, la confiabilidad y lo que sucederá después del lanzamiento.
Antes de la Tech Race Summit 2026, Sergey Kastsukevich, director de tecnología de SOFTSWISS, comparte cinco aspectos que los operadores y proveedores suelen pasar por alto al planificar el trabajo de sus equipos de tecnología.
1. Los lanzamientos rápidos suelen dar lugar a plataformas lentas
«El mundo de los negocios siempre quiere que las cosas sean rápidas, de alta calidad y baratas. Pero solo puedes elegir dos de las tres».
Una suposición común en el desarrollo de productos es que la primera versión solo tiene que funcionar. El resto siempre se puede agregar más adelante. La lógica parece bastante razonable: lanzar una primera versión ahora; la segunda solo tendrá unos pocos cambios.
Desde una perspectiva de ingeniería, rara vez funciona así. Una característica que parece una pequeña actualización en una hoja de ruta puede convertirse en un rediseño costoso, que requiera reconstruir el sistema desde cero.
Esta tensión no es un fallo de planificación. Es la negociación fundamental que todo director técnico (CTO) debe manejar. En una startup, aceptar un riesgo del 30 por ciento de que el sistema falle mañana es una compensación racional. En una plataforma madura que maneja dinero real en mercados regulados, no lo es. Cuanto antes se haga explícita y se acuerde esa distinción, menos costará más adelante.
2. La escalabilidad comienza mucho antes de que llegue el primer cliente
«Lanzar un servicio para cinco jugadores por hora es fácil. Lanzarlo para miles de usuarios en múltiples mercados es donde la disciplina de ingeniería cobra importancia».
«¿Por qué no pueden simplemente manejar un millón de usuarios?» es una pregunta que los equipos de ingeniería escuchan con más frecuencia de la que deberían. La suposición detrás de ella es que la escalabilidad es un ajuste, algo que se activa cuando es necesario.
Para los ingenieros, la pregunta más importante surge mucho antes: «¿Sabíamos que, con el tiempo, necesitaríamos un millón de usuarios?»
La escalabilidad es una decisión arquitectónica que se toma desde el principio. Si se pasa por alto, surgen problemas cuando los nuevos requisitos aparecen uno tras otro: más mercados, más métodos de pago, más integraciones, más tráfico. Cada uno de ellos conlleva implicaciones de carga que nunca aparecen en el resumen del proyecto.
Los equipos de tecnología deben gestionar estas expectativas sin esperar a que se les pregunte. Cuando un cliente o una parte interesada interna describe lo que quiere construir, la pregunta de ingeniería —«¿qué debe manejar este sistema, a qué escala y en qué condiciones?»— debe formar parte de la misma conversación.
Si la necesidad de escalabilidad surge después de que el desarrollo se haya completado, ocurre en el peor momento posible.
3. La deuda técnica acaba convirtiéndose en deuda empresarial
«Los negocios y la tecnología suelen buscar optimizar aspectos diferentes».
La deuda técnica suele tratarse como un problema de ingeniería, aunque en realidad se trata de una decisión de negocios.
Esta decisión es difícil de tomar en el momento. No hay nada que falle a simple vista y el sistema sigue funcionando. El argumento a favor de invertir tiempo de ingeniería en algo que no cambia la funcionalidad del producto rara vez prevalece en una discusión sobre la hoja de ruta.
Lo que cambia ese cálculo es el momento. Un atajo que se toma para cumplir con una fecha de lanzamiento o un parche que se aplica bajo la presión de un plazo parece algo manejable por sí solo. En realidad, solo son costos pospuestos.
De repente, los lanzamientos se ralentizan. Los errores se vuelven más difíciles de corregir. Cada nuevo cambio depende de algo antiguo y frágil que subyace debajo. Como resultado, una solicitud de función sencilla tarda tres meses en lugar de tres semanas.
Con el tiempo, la empresa tiene que aprobar un gran proyecto de reconstrucción que se podría haber evitado mediante una inversión constante a lo largo del tiempo.
La deuda técnica nunca desaparece. Simplemente espera.
4. La tecnología obsoleta es un riesgo, no solo un inconveniente
«Las herramientas evolucionan cada pocos meses, y las personas deben sentirse cómodas al dejar atrás lo que acaban de crear y pasar a soluciones mejores sin dificultades».
«Si funciona, ¿por qué cambiarlo?» es una pregunta razonable con una respuesta irrazonable.
Los sistemas heredados funcionan… hasta que dejan de hacerlo. El problema no es que fallen de repente, sino que se vuelven cada vez más difíciles de mantener. Cada vez son menos los ingenieros que saben cómo trabajar con ellos, lo que retrasa las actualizaciones de seguridad y complica la integración.
Una de las conversaciones más difíciles que los líderes de ingeniería tienen con el equipo de negocios es explicar por qué la tecnología necesita inversión, incluso cuando nada parece estar fallando.
Las preguntas del equipo de negocios tienen sentido: «¿Esto hará que la plataforma sea más rápida?» o «¿Aumentará los ingresos?».
A veces, la respuesta honesta es no. Pero el beneficio real es reducir el riesgo futuro. La tecnología obsoleta limita a qué se puede conectar la tecnología nueva. Crea dependencias que bloquean las decisiones sobre los productos.
La forma de presentar este argumento al equipo de negocios es replantearlo, pasando de la mejora técnica a la gestión de riesgos. Entonces, la pregunta cambia de «¿qué ganamos?» a «¿qué evitamos?».
5. Los productos excelentes requieren tiempo para la investigación
«El cuello de botella ya no es cómo construir algo, sino qué construir exactamente».
Las grandes empresas tecnológicas invierten mucho en investigación. Google cuenta con laboratorios especializados que exploran ideas que tal vez nunca lleguen a los usuarios. OpenAI dedicó más de cinco años a la investigación fundamental antes de que ChatGPT se convirtiera en un producto global.
Los experimentos que dan resultado suelen definir líneas completas de productos años más tarde.
Las empresas más pequeñas observan ese modelo y asumen que no se aplica a ellas. Los departamentos de investigación se perciben como un lujo, algo para empresas con recursos de sobra. El resultado es que los equipos de ingeniería dedican la mayor parte de su tiempo a la entrega de productos y muy poco a la exploración.
Los equipos que experimentan aprenden más rápido y detectan oportunidades antes. Y cuando una nueva tecnología pasa de ser interesante a ser esencial —como ha sucedido con la IA en los últimos dos años—, ya están preparados.
El tiempo dedicado a la investigación es tiempo invertido en proteger al negocio de quedarse estancado. Los equipos de tecnología construyen más que software. Construyen la capacidad de la empresa para adaptarse.
¿Quieres explorar estas cuestiones con las personas que las están resolviendo? La Tech Race Summit 2026 se llevará a cabo el 10 de septiembre en Varsovia. El programa incluye a más de 30 ponentes de AWS, Google, Oracle, Cloudflare y otras empresas. Consigue tus boletos en techracesummit.com.
