Em prepara\u00e7\u00e3o para o Tech Race Summit 2026, Sergey Katsukevich, diretor de Tecnologia da SOFTSWISS, compartilha insights sobre o equil\u00edbrio crucial entre crescimento dos neg\u00f3cios e escalabilidade da engenharia na ind\u00fastria de jogos.<\/p>\n\n\n\n\n\n\n\n
Opini\u00e3o: Todas as operadoras querem lan\u00e7ar produtos mais rapidamente, entrar em novos mercados com agilidade e lan\u00e7ar novos recursos antes da concorr\u00eancia.<\/p>\n\n\n\n
As equipes de engenharia querem exatamente a mesma coisa. A diferen\u00e7a \u00e9 que elas tamb\u00e9m s\u00e3o respons\u00e1veis \u200b\u200bpor garantir que a plataforma ainda funcione seis meses depois.<\/p>\n\n\n\n
Essa diferen\u00e7a de perspectiva cria uma das maiores tens\u00f5es dentro das empresas de tecnologia. O setor de neg\u00f3cios naturalmente se concentra no crescimento e na velocidade. A engenharia precisa considerar a escalabilidade, a confiabilidade e o que acontece ap\u00f3s o lan\u00e7amento.<\/p>\n\n\n\n
Em prepara\u00e7\u00e3o para o Tech Race Summit 2026<\/a>, Sergey Katsukevich<\/strong>, diretor de Tecnologia da SOFTSWISS,<\/a> compartilha cinco coisas que operadoras e provedores frequentemente deixam passar ao planejar o trabalho de suas equipes de tecnologia.<\/p>\n\n\n\n \u201cO mundo empresarial sempre quer as coisas r\u00e1pidas, de alta qualidade e baratas. Mas voc\u00ea s\u00f3 pode escolher duas dessas tr\u00eas caracter\u00edsticas.\u201d<\/p>\n\n\n\n Uma premissa comum no desenvolvimento de produtos \u00e9 que a primeira vers\u00e3o s\u00f3 precisa funcionar. O resto pode sempre ser adicionado posteriormente. A l\u00f3gica parece bastante razo\u00e1vel: lance uma primeira vers\u00e3o agora, a segunda ter\u00e1 apenas algumas altera\u00e7\u00f5es.<\/p>\n\n\n\n Do ponto de vista da engenharia, raramente funciona dessa forma. Uma funcionalidade que parece uma pequena atualiza\u00e7\u00e3o em um planejamento estrat\u00e9gico pode se transformar em uma reformula\u00e7\u00e3o cara, exigindo uma reconstru\u00e7\u00e3o do zero.<\/p>\n\n\n\n Essa tens\u00e3o n\u00e3o \u00e9 resultado de uma falha de planejamento. \u00c9 a negocia\u00e7\u00e3o central que todo CTO gerencia. Em uma startup, aceitar um risco de 30% de que o sistema falhe amanh\u00e3 \u00e9 uma troca racional. Em uma plataforma consolidada que lida com dinheiro real em mercados regulamentados, n\u00e3o \u00e9. Quanto mais cedo essa distin\u00e7\u00e3o for explicitada e acordada, menor ser\u00e1 o custo futuro.<\/p>\n\n\n\n \u201cLan\u00e7ar para cinco jogadores por hora \u00e9 f\u00e1cil. Lan\u00e7ar para milhares em v\u00e1rios mercados \u00e9 onde a disciplina de engenharia faz a diferen\u00e7a.\u201d<\/p>\n\n\n\n “Por que voc\u00eas n\u00e3o conseguem lidar com um milh\u00e3o de usu\u00e1rios?” \u00e9 uma pergunta que as equipes de engenharia ouvem com mais frequ\u00eancia do que deveriam. A premissa por tr\u00e1s disso \u00e9 que escalabilidade \u00e9 uma configura\u00e7\u00e3o \u2014 algo que voc\u00ea ativa quando necess\u00e1rio.<\/p>\n\n\n\n Para os engenheiros, a pergunta mais pertinente surge bem antes: “Sab\u00edamos que eventualmente precisar\u00edamos de um milh\u00e3o de usu\u00e1rios?”<\/p>\n\n\n\n A escalabilidade \u00e9 uma decis\u00e3o arquitet\u00f4nica tomada desde o in\u00edcio. Se for negligenciada, surgem problemas quando novos requisitos continuam aparecendo um ap\u00f3s o outro. Mais mercados. Mais m\u00e9todos de pagamento. Mais integra\u00e7\u00f5es. Mais tr\u00e1fego. Cada um deles acarreta implica\u00e7\u00f5es de carga que nunca aparecem no briefing.<\/p>\n\n\n\n As equipes de tecnologia precisam gerenciar essas expectativas sem esperar que lhes perguntem. Quando um cliente ou stakeholder interno descreve o que deseja construir, a quest\u00e3o de engenharia \u2013 \u201co que este sistema precisa suportar, em que escala e sob quais condi\u00e7\u00f5es?\u201d \u2013 precisa fazer parte da mesma conversa.<\/p>\n\n\n\n Se a necessidade de escalabilidade surgir ap\u00f3s a conclus\u00e3o do desenvolvimento, isso acontecer\u00e1 no pior momento poss\u00edvel.<\/p>\n\n\n\n \u201cOs neg\u00f3cios e a tecnologia geralmente s\u00e3o otimizados para coisas diferentes.\u201d<\/p>\n\n\n\n A d\u00edvida t\u00e9cnica \u00e9 frequentemente tratada como uma quest\u00e3o de engenharia, embora seja, na verdade, uma decis\u00e3o de neg\u00f3cios.<\/p>\n\n\n\n \u00c9 dif\u00edcil tomar essa decis\u00e3o no momento. Nada est\u00e1 visivelmente quebrado e o sistema est\u00e1 funcionando. O argumento de investir tempo de engenharia em algo que n\u00e3o altera a funcionalidade do produto raramente prevalece em uma discuss\u00e3o sobre o planejamento estrat\u00e9gico.<\/p>\n\n\n\n O que altera esse c\u00e1lculo \u00e9 o momento. Um atalho tomado para cumprir um prazo de lan\u00e7amento ou uma corre\u00e7\u00e3o aplicada sob press\u00e3o de prazo parecem administr\u00e1veis \u200b\u200bisoladamente. Na realidade, s\u00e3o apenas custos adiados.<\/p>\n\n\n\n De repente, os lan\u00e7amentos de atualiza\u00e7\u00f5es ficam mais lentos. Os bugs se tornam mais dif\u00edceis de corrigir. Cada nova mudan\u00e7a depende de algo antigo e fr\u00e1gil por baixo. Como resultado, uma simples solicita\u00e7\u00e3o de recurso leva tr\u00eas meses em vez de tr\u00eas semanas.<\/p>\n\n\n\n Por fim, a empresa precisa aprovar um grande projeto de reconstru\u00e7\u00e3o que poderia ter sido evitado com investimentos constantes ao longo do tempo.<\/p>\n\n\n\n A d\u00edvida t\u00e9cnica nunca desaparece. Ela simplesmente espera.<\/p>\n\n\n\n \u201cAs ferramentas evoluem a cada poucos meses, e as pessoas precisam se sentir \u00e0 vontade para abandonar o que acabaram de construir e migrar para solu\u00e7\u00f5es melhores sem dificuldades.\u201d<\/p>\n\n\n\n “Se funciona, por que mudar?” \u00e9 uma pergunta razo\u00e1vel com uma resposta irracional.<\/p>\n\n\n\n Sistemas legados funcionam \u2013 at\u00e9 que deixam de funcionar. O problema n\u00e3o \u00e9 que eles falhem repentinamente, mas sim que se tornam progressivamente mais dif\u00edceis de manter. Cada vez menos engenheiros sabem como trabalhar com eles, o que atrasa as atualiza\u00e7\u00f5es de seguran\u00e7a e complica a integra\u00e7\u00e3o.<\/p>\n\n\n\n Uma das conversas mais dif\u00edceis que os l\u00edderes de engenharia t\u00eam com a \u00e1rea de neg\u00f3cios \u00e9 explicar por que a tecnologia precisa de investimento, mesmo quando nada parece estar quebrado.<\/p>\n\n\n\n As quest\u00f5es comerciais fazem sentido: “Isso tornar\u00e1 a plataforma mais r\u00e1pida?” ou “Isso aumentar\u00e1 a receita?”<\/p>\n\n\n\n \u00c0s vezes, a resposta honesta \u00e9 n\u00e3o. Mas o verdadeiro benef\u00edcio \u00e9 a redu\u00e7\u00e3o do risco futuro. A tecnologia antiga limita a conectividade da nova tecnologia. Ela cria depend\u00eancias que bloqueiam as decis\u00f5es de produto.<\/p>\n\n\n\n A melhor forma de apresentar esse argumento ao mundo empresarial \u00e9 reformul\u00e1-lo, passando de uma abordagem de melhoria t\u00e9cnica para uma de gest\u00e3o de riscos. Assim, a pergunta muda de “o que ganhamos com isso?” para “o que evitamos?”.<\/p>\n\n\n\n \u201cO gargalo n\u00e3o \u00e9 mais como construir algo, mas sim o que exatamente construir.\u201d<\/p>\n\n\n\n Grandes empresas de tecnologia investem pesadamente em pesquisa. O Google mant\u00e9m laborat\u00f3rios dedicados \u00e0 explora\u00e7\u00e3o de ideias que podem nunca chegar aos usu\u00e1rios. A OpenAI dedicou mais de 5 anos \u00e0 pesquisa fundamental antes que o ChatGPT se tornasse um produto global.<\/p>\n\n\n\n Experimentos bem-sucedidos tendem a definir linhas de produtos inteiras anos depois.<\/p>\n\n\n\n Empresas menores olham para esse modelo e presumem que ele n\u00e3o se aplica a elas. Departamentos de pesquisa s\u00e3o vistos como um luxo, algo para empresas com recursos de sobra. O resultado \u00e9 que as equipes de engenharia passam a maior parte do tempo na entrega de resultados e pouco tempo explorando novas possibilidades.<\/p>\n\n\n\n As equipes que experimentam aprendem mais r\u00e1pido e identificam oportunidades mais cedo. E quando uma nova tecnologia deixa de ser interessante e se torna essencial \u2013 como aconteceu com a IA nos \u00faltimos dois anos \u2013 elas j\u00e1 est\u00e3o preparadas.<\/p>\n\n\n\n O tempo dedicado \u00e0 pesquisa \u00e9 tempo gasto protegendo a empresa da estagna\u00e7\u00e3o. As equipes de tecnologia constroem mais do que software. Elas constroem a capacidade da empresa de se adaptar.<\/p>\n\n\n\n Quer explorar essas quest\u00f5es com as pessoas que est\u00e3o encontrando solu\u00e7\u00f5es? O Tech Race Summit 2026 acontece em 10 de setembro em Vars\u00f3via. A programa\u00e7\u00e3o inclui mais de 30 palestrantes da AWS, Google, Oracle, Cloudflare e outras empresas. Compre seus ingressos em techracesummit.com.<\/p>\n","protected":false},"excerpt":{"rendered":" Em prepara\u00e7\u00e3o para o Tech Race Summit 2026, Sergey Katsukevich, diretor de Tecnologia da SOFTSWISS, compartilha insights sobre o equil\u00edbrio crucial entre crescimento dos neg\u00f3cios e escalabilidade da engenharia na ind\u00fastria de jogos.<\/p>\n","protected":false},"author":688,"featured_media":56082,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"is_press_release":false,"is_interview":false,"is_opinion":true,"focusai_summary":"Sergey Katsukevich, CTO da SOFTSWISS, aborda a tens\u00e3o cr\u00edtica entre a velocidade de lan\u00e7amento de produtos e a escalabilidade da engenharia na ind\u00fastria de iGaming. Ele destaca que a busca por lan\u00e7amentos r\u00e1pidos pode comprometer a estabilidade da plataforma, a escalabilidade deve ser uma decis\u00e3o arquitet\u00f4nica inicial e a d\u00edvida t\u00e9cnica inevitavelmente se transforma em d\u00edvida comercial, impactando diretamente as operadoras e provedores.","focusai_entities":"Sergey Katsukevich, SOFTSWISS, Tech Race Summit 2026","focusai_location":"","focusai_target_profile":"ceo_executive (1.0), regulator (0.7), compliance_legal (0.7), operator_casino (1.0), product_ux (0.9), tech_data (1.0), payments_fraud_aml (0.8), investor_analyst (1.0), supplier_vendor (1.0), journalist_researcher (0.9)","focusai_suggestions":[{"label":"Mitigar D\u00edvida T\u00e9cnica?","query":"Quais s\u00e3o as estrat\u00e9gias eficazes para CTOs e l\u00edderes de neg\u00f3cios mitigarem a d\u00edvida t\u00e9cnica em plataformas de iGaming consolidadas, sem comprometer a inova\u00e7\u00e3o e a velocidade de mercado?"},{"label":"Escalabilidade em Novos Mercados?","query":"Como as operadoras e fornecedores podem integrar proativamente a escalabilidade em sua arquitetura desde o in\u00edcio, especialmente ao planejar a expans\u00e3o para m\u00faltiplos mercados regulamentados com requisitos de carga variados?"}],"footnotes":""},"categories":[1828],"tags":[45,406],"class_list":["post-56078","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-opiniao","tag-industria-de-jogos","tag-softswiss"],"_links":{"self":[{"href":"https:\/\/focusgn.com\/brasil\/wp-json\/wp\/v2\/posts\/56078","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/focusgn.com\/brasil\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/focusgn.com\/brasil\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/focusgn.com\/brasil\/wp-json\/wp\/v2\/users\/688"}],"replies":[{"embeddable":true,"href":"https:\/\/focusgn.com\/brasil\/wp-json\/wp\/v2\/comments?post=56078"}],"version-history":[{"count":3,"href":"https:\/\/focusgn.com\/brasil\/wp-json\/wp\/v2\/posts\/56078\/revisions"}],"predecessor-version":[{"id":56091,"href":"https:\/\/focusgn.com\/brasil\/wp-json\/wp\/v2\/posts\/56078\/revisions\/56091"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/focusgn.com\/brasil\/wp-json\/wp\/v2\/media\/56082"}],"wp:attachment":[{"href":"https:\/\/focusgn.com\/brasil\/wp-json\/wp\/v2\/media?parent=56078"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/focusgn.com\/brasil\/wp-json\/wp\/v2\/categories?post=56078"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/focusgn.com\/brasil\/wp-json\/wp\/v2\/tags?post=56078"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}1. Lan\u00e7amentos r\u00e1pidos geralmente criam plataformas lentas<\/h2>\n\n\n\n
2. A escalabilidade come\u00e7a muito antes da chegada do primeiro cliente<\/h2>\n\n\n\n
3. A d\u00edvida t\u00e9cnica eventualmente se transforma em d\u00edvida comercial<\/h2>\n\n\n\n
4. Tecnologia obsoleta \u00e9 um risco, n\u00e3o apenas um inconveniente<\/h2>\n\n\n\n
5. \u00d3timos produtos precisam de tempo para pesquisa<\/h2>\n\n\n\n