Corrida tecnológica: por que os setores de negócios e engenharia precisam planejar juntos
0
0
Em preparação para o Tech Race Summit 2026, Sergey Katsukevich, diretor de Tecnologia da SOFTSWISS, compartilha insights sobre o equilíbrio crucial entre crescimento dos negócios e escalabilidade da engenharia na indústria de jogos.
Opinião: Todas as operadoras querem lançar produtos mais rapidamente, entrar em novos mercados com agilidade e lançar novos recursos antes da concorrência.
As equipes de engenharia querem exatamente a mesma coisa. A diferença é que elas também são responsáveis por garantir que a plataforma ainda funcione seis meses depois.
Essa diferença de perspectiva cria uma das maiores tensões dentro das empresas de tecnologia. O setor de negócios naturalmente se concentra no crescimento e na velocidade. A engenharia precisa considerar a escalabilidade, a confiabilidade e o que acontece após o lançamento.
Em preparação para o Tech Race Summit 2026, Sergey Katsukevich, diretor de Tecnologia da SOFTSWISS, compartilha cinco coisas que operadoras e provedores frequentemente deixam passar ao planejar o trabalho de suas equipes de tecnologia.
1. Lançamentos rápidos geralmente criam plataformas lentas
“O mundo empresarial sempre quer as coisas rápidas, de alta qualidade e baratas. Mas você só pode escolher duas dessas três características.”
Uma premissa comum no desenvolvimento de produtos é que a primeira versão só precisa funcionar. O resto pode sempre ser adicionado posteriormente. A lógica parece bastante razoável: lance uma primeira versão agora, a segunda terá apenas algumas alterações.
Do ponto de vista da engenharia, raramente funciona dessa forma. Uma funcionalidade que parece uma pequena atualização em um planejamento estratégico pode se transformar em uma reformulação cara, exigindo uma reconstrução do zero.
Essa tensão não é resultado de uma falha de planejamento. É a negociação central que todo CTO gerencia. Em uma startup, aceitar um risco de 30% de que o sistema falhe amanhã é uma troca racional. Em uma plataforma consolidada que lida com dinheiro real em mercados regulamentados, não é. Quanto mais cedo essa distinção for explicitada e acordada, menor será o custo futuro.
2. A escalabilidade começa muito antes da chegada do primeiro cliente
“Lançar para cinco jogadores por hora é fácil. Lançar para milhares em vários mercados é onde a disciplina de engenharia faz a diferença.”
“Por que vocês não conseguem lidar com um milhão de usuários?” é uma pergunta que as equipes de engenharia ouvem com mais frequência do que deveriam. A premissa por trás disso é que escalabilidade é uma configuração — algo que você ativa quando necessário.
Para os engenheiros, a pergunta mais pertinente surge bem antes: “Sabíamos que eventualmente precisaríamos de um milhão de usuários?”
A escalabilidade é uma decisão arquitetônica tomada desde o início. Se for negligenciada, surgem problemas quando novos requisitos continuam aparecendo um após o outro. Mais mercados. Mais métodos de pagamento. Mais integrações. Mais tráfego. Cada um deles acarreta implicações de carga que nunca aparecem no briefing.
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ão de engenharia – “o que este sistema precisa suportar, em que escala e sob quais condições?” – precisa fazer parte da mesma conversa.
Se a necessidade de escalabilidade surgir após a conclusão do desenvolvimento, isso acontecerá no pior momento possível.
3. A dívida técnica eventualmente se transforma em dívida comercial
“Os negócios e a tecnologia geralmente são otimizados para coisas diferentes.”
A dívida técnica é frequentemente tratada como uma questão de engenharia, embora seja, na verdade, uma decisão de negócios.
É difícil tomar essa decisão no momento. Nada está visivelmente quebrado e o sistema está funcionando. O argumento de investir tempo de engenharia em algo que não altera a funcionalidade do produto raramente prevalece em uma discussão sobre o planejamento estratégico.
O que altera esse cálculo é o momento. Um atalho tomado para cumprir um prazo de lançamento ou uma correção aplicada sob pressão de prazo parecem administráveis isoladamente. Na realidade, são apenas custos adiados.
De repente, os lançamentos de atualizações ficam mais lentos. Os bugs se tornam mais difíceis de corrigir. Cada nova mudança depende de algo antigo e frágil por baixo. Como resultado, uma simples solicitação de recurso leva três meses em vez de três semanas.
Por fim, a empresa precisa aprovar um grande projeto de reconstrução que poderia ter sido evitado com investimentos constantes ao longo do tempo.
A dívida técnica nunca desaparece. Ela simplesmente espera.
4. Tecnologia obsoleta é um risco, não apenas um inconveniente
“As ferramentas evoluem a cada poucos meses, e as pessoas precisam se sentir à vontade para abandonar o que acabaram de construir e migrar para soluções melhores sem dificuldades.”
“Se funciona, por que mudar?” é uma pergunta razoável com uma resposta irracional.
Sistemas legados funcionam – até que deixam de funcionar. O problema não é que eles falhem repentinamente, mas sim que se tornam progressivamente mais difíceis de manter. Cada vez menos engenheiros sabem como trabalhar com eles, o que atrasa as atualizações de segurança e complica a integração.
Uma das conversas mais difíceis que os líderes de engenharia têm com a área de negócios é explicar por que a tecnologia precisa de investimento, mesmo quando nada parece estar quebrado.
As questões comerciais fazem sentido: “Isso tornará a plataforma mais rápida?” ou “Isso aumentará a receita?”
Às vezes, a resposta honesta é não. Mas o verdadeiro benefício é a redução do risco futuro. A tecnologia antiga limita a conectividade da nova tecnologia. Ela cria dependências que bloqueiam as decisões de produto.
A melhor forma de apresentar esse argumento ao mundo empresarial é reformulá-lo, passando de uma abordagem de melhoria técnica para uma de gestão de riscos. Assim, a pergunta muda de “o que ganhamos com isso?” para “o que evitamos?”.
5. Ótimos produtos precisam de tempo para pesquisa
“O gargalo não é mais como construir algo, mas sim o que exatamente construir.”
Grandes empresas de tecnologia investem pesadamente em pesquisa. O Google mantém laboratórios dedicados à exploração de ideias que podem nunca chegar aos usuários. A OpenAI dedicou mais de 5 anos à pesquisa fundamental antes que o ChatGPT se tornasse um produto global.
Experimentos bem-sucedidos tendem a definir linhas de produtos inteiras anos depois.
Empresas menores olham para esse modelo e presumem que ele não se aplica a elas. Departamentos de pesquisa são vistos como um luxo, algo para empresas com recursos de sobra. O resultado é que as equipes de engenharia passam a maior parte do tempo na entrega de resultados e pouco tempo explorando novas possibilidades.
As equipes que experimentam aprendem mais rápido e identificam oportunidades mais cedo. E quando uma nova tecnologia deixa de ser interessante e se torna essencial – como aconteceu com a IA nos últimos dois anos – elas já estão preparadas.
O tempo dedicado à pesquisa é tempo gasto protegendo a empresa da estagnação. As equipes de tecnologia constroem mais do que software. Elas constroem a capacidade da empresa de se adaptar.
Quer explorar essas questões com as pessoas que estão encontrando soluções? O Tech Race Summit 2026 acontece em 10 de setembro em Varsóvia. A programação inclui mais de 30 palestrantes da AWS, Google, Oracle, Cloudflare e outras empresas. Compre seus ingressos em techracesummit.com.
Em preparação para o Tech Race Summit 2026, Sergey Katsukevich, diretor de Tecnologia da SOFTSWISS, compartilha insights sobre o equilíbrio crucial entre crescimento dos negócios e escalabilidade da engenharia na indústria de jogos.
Opinião: Todas as operadoras querem lançar produtos mais rapidamente, entrar em novos mercados com agilidade e lançar novos recursos antes da concorrência.
As equipes de engenharia querem exatamente a mesma coisa. A diferença é que elas também são responsáveis por garantir que a plataforma ainda funcione seis meses depois.
Essa diferença de perspectiva cria uma das maiores tensões dentro das empresas de tecnologia. O setor de negócios naturalmente se concentra no crescimento e na velocidade. A engenharia precisa considerar a escalabilidade, a confiabilidade e o que acontece após o lançamento.
Em preparação para o Tech Race Summit 2026, Sergey Katsukevich, diretor de Tecnologia da SOFTSWISS, compartilha cinco coisas que operadoras e provedores frequentemente deixam passar ao planejar o trabalho de suas equipes de tecnologia.
1. Lançamentos rápidos geralmente criam plataformas lentas
“O mundo empresarial sempre quer as coisas rápidas, de alta qualidade e baratas. Mas você só pode escolher duas dessas três características.”
Uma premissa comum no desenvolvimento de produtos é que a primeira versão só precisa funcionar. O resto pode sempre ser adicionado posteriormente. A lógica parece bastante razoável: lance uma primeira versão agora, a segunda terá apenas algumas alterações.
Do ponto de vista da engenharia, raramente funciona dessa forma. Uma funcionalidade que parece uma pequena atualização em um planejamento estratégico pode se transformar em uma reformulação cara, exigindo uma reconstrução do zero.
Essa tensão não é resultado de uma falha de planejamento. É a negociação central que todo CTO gerencia. Em uma startup, aceitar um risco de 30% de que o sistema falhe amanhã é uma troca racional. Em uma plataforma consolidada que lida com dinheiro real em mercados regulamentados, não é. Quanto mais cedo essa distinção for explicitada e acordada, menor será o custo futuro.
2. A escalabilidade começa muito antes da chegada do primeiro cliente
“Lançar para cinco jogadores por hora é fácil. Lançar para milhares em vários mercados é onde a disciplina de engenharia faz a diferença.”
“Por que vocês não conseguem lidar com um milhão de usuários?” é uma pergunta que as equipes de engenharia ouvem com mais frequência do que deveriam. A premissa por trás disso é que escalabilidade é uma configuração — algo que você ativa quando necessário.
Para os engenheiros, a pergunta mais pertinente surge bem antes: “Sabíamos que eventualmente precisaríamos de um milhão de usuários?”
A escalabilidade é uma decisão arquitetônica tomada desde o início. Se for negligenciada, surgem problemas quando novos requisitos continuam aparecendo um após o outro. Mais mercados. Mais métodos de pagamento. Mais integrações. Mais tráfego. Cada um deles acarreta implicações de carga que nunca aparecem no briefing.
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ão de engenharia – “o que este sistema precisa suportar, em que escala e sob quais condições?” – precisa fazer parte da mesma conversa.
Se a necessidade de escalabilidade surgir após a conclusão do desenvolvimento, isso acontecerá no pior momento possível.
3. A dívida técnica eventualmente se transforma em dívida comercial
“Os negócios e a tecnologia geralmente são otimizados para coisas diferentes.”
A dívida técnica é frequentemente tratada como uma questão de engenharia, embora seja, na verdade, uma decisão de negócios.
É difícil tomar essa decisão no momento. Nada está visivelmente quebrado e o sistema está funcionando. O argumento de investir tempo de engenharia em algo que não altera a funcionalidade do produto raramente prevalece em uma discussão sobre o planejamento estratégico.
O que altera esse cálculo é o momento. Um atalho tomado para cumprir um prazo de lançamento ou uma correção aplicada sob pressão de prazo parecem administráveis isoladamente. Na realidade, são apenas custos adiados.
De repente, os lançamentos de atualizações ficam mais lentos. Os bugs se tornam mais difíceis de corrigir. Cada nova mudança depende de algo antigo e frágil por baixo. Como resultado, uma simples solicitação de recurso leva três meses em vez de três semanas.
Por fim, a empresa precisa aprovar um grande projeto de reconstrução que poderia ter sido evitado com investimentos constantes ao longo do tempo.
A dívida técnica nunca desaparece. Ela simplesmente espera.
4. Tecnologia obsoleta é um risco, não apenas um inconveniente
“As ferramentas evoluem a cada poucos meses, e as pessoas precisam se sentir à vontade para abandonar o que acabaram de construir e migrar para soluções melhores sem dificuldades.”
“Se funciona, por que mudar?” é uma pergunta razoável com uma resposta irracional.
Sistemas legados funcionam – até que deixam de funcionar. O problema não é que eles falhem repentinamente, mas sim que se tornam progressivamente mais difíceis de manter. Cada vez menos engenheiros sabem como trabalhar com eles, o que atrasa as atualizações de segurança e complica a integração.
Uma das conversas mais difíceis que os líderes de engenharia têm com a área de negócios é explicar por que a tecnologia precisa de investimento, mesmo quando nada parece estar quebrado.
As questões comerciais fazem sentido: “Isso tornará a plataforma mais rápida?” ou “Isso aumentará a receita?”
Às vezes, a resposta honesta é não. Mas o verdadeiro benefício é a redução do risco futuro. A tecnologia antiga limita a conectividade da nova tecnologia. Ela cria dependências que bloqueiam as decisões de produto.
A melhor forma de apresentar esse argumento ao mundo empresarial é reformulá-lo, passando de uma abordagem de melhoria técnica para uma de gestão de riscos. Assim, a pergunta muda de “o que ganhamos com isso?” para “o que evitamos?”.
5. Ótimos produtos precisam de tempo para pesquisa
“O gargalo não é mais como construir algo, mas sim o que exatamente construir.”
Grandes empresas de tecnologia investem pesadamente em pesquisa. O Google mantém laboratórios dedicados à exploração de ideias que podem nunca chegar aos usuários. A OpenAI dedicou mais de 5 anos à pesquisa fundamental antes que o ChatGPT se tornasse um produto global.
Experimentos bem-sucedidos tendem a definir linhas de produtos inteiras anos depois.
Empresas menores olham para esse modelo e presumem que ele não se aplica a elas. Departamentos de pesquisa são vistos como um luxo, algo para empresas com recursos de sobra. O resultado é que as equipes de engenharia passam a maior parte do tempo na entrega de resultados e pouco tempo explorando novas possibilidades.
As equipes que experimentam aprendem mais rápido e identificam oportunidades mais cedo. E quando uma nova tecnologia deixa de ser interessante e se torna essencial – como aconteceu com a IA nos últimos dois anos – elas já estão preparadas.
O tempo dedicado à pesquisa é tempo gasto protegendo a empresa da estagnação. As equipes de tecnologia constroem mais do que software. Elas constroem a capacidade da empresa de se adaptar.
Quer explorar essas questões com as pessoas que estão encontrando soluções? O Tech Race Summit 2026 acontece em 10 de setembro em Varsóvia. A programação inclui mais de 30 palestrantes da AWS, Google, Oracle, Cloudflare e outras empresas. Compre seus ingressos em techracesummit.com.
