Tudo começou com um lançamento reluzente. A Google acabara de revelar as funcionalidades multimodais do Gemini–uma tecnologia que parecia suficientemente promissora para poder resolver os problemas de interação entre humanos e navegadores. A equipa de engenharia calculou que seria uma experiência rápida e de baixo risco.
Uma equipa experimentou-a. Depois, outra. E depois, uma terceira.
Mas, embora o conceito fosse entusiasmante, a ferramenta em si ainda não estava propriamente pronta. Estava numa fase inicial, não estava preparada para produção e, definitivamente, não era adequada ao caso de utilização da equipa.
“Era uma distração que poderia facilmente ter feito descarrilar o progresso das prioridades existentes se não tivéssemos travado a tempo,” recorda Anand Sainath, responsável pela engenharia e cofundador da 100x, que tomou a decisão de interromper a integração.
Outros não tiveram tanta sorte. Para muitas equipas, a perseguição da “próxima grande novidade” foi lentamente sequestrando o roteiro do produto. O que restou foi uma coleção de ferramentas inacabadas e prioridades negligenciadas– algo a que Sainath chama o custo silencioso do síndrome do objeto brilhante.
Mas afinal, o que é o síndrome do objeto brilhante?
O síndrome do objeto brilhante (SOS) ocorre quando as equipas se deixam desviar por novas ferramentas, estruturas ou tecnologias, frequentemente à custa das prioridades existentes.
“Quando surge uma nova tecnologia, como acontece atualmente com a IA, o mercado entusiasma-se com as suas aplicações. Pode haver pressão para acompanhar a tendência e manter-se à frente da concorrência,” afirma Raju Malhotra, CPTO da Certinia.
É nessa altura que a ferramenta ou a estrutura “brilhante” começa a infiltrar-se nos seus planos e “afasta a engenharia do trabalho que realmente importa hoje aos clientes.”
A história da Evernote preenche todos os requisitos do cartão de bingo do síndrome do objeto brilhante. Tinha todos os ingredientes certos: utilizadores fiéis, um produto sólido e um nicho bem definido. Em vez de reforçar as suas funcionalidades principais, a empresa expandiu-se para produtos físicos e lançou funcionalidades de produto inacabadas, como o Work Chat.
O produto tornou-se inchado, o desempenho deteriorou-se e os utilizadores partiram para ferramentas mais simples, como o Notion e o Google Keep. Em 2022, a Evernote foi adquirida e, no início de 2023, a maioria dos seus funcionários foi despedida.
O SOS nem sempre termina em falência ou despedimentos, mas quase sempre faz descarrilar o ímpeto ao:
- Atrasar as entregas do projeto: Mudanças frequentes para novas tecnologias a meio de um projeto podem perturbar o planeamento, interromper os ciclos de execução e introduzir um âmbito excessivo e não planeado. Foi exatamente o que aconteceu com o projeto Virtual Case File do FBI. Após cinco anos e $170 million gastos, o projeto foi abandonado, em parte porque a instável articulação entre a burocracia e o negócio continuava a quebrar o ritmo de entrega.
- Aumentar os custos de engenharia: Sem uma estrutura para avaliar novas tecnologias, as decisões motivadas pelo objeto brilhante resultam frequentemente em excesso de ferramentas, dívida técnica e custos elevados de desenvolvimento de software. As equipas chegam mesmo a investir tempo em protótipos que nunca são lançados ou, pior ainda, que são implementados e depois reescritos.
- Prejudicar a produtividade dos programadores: Cada nova ferramenta implica uma nova curva de aprendizagem, mais erros e mais “testes rápidos” que raramente permanecem rápidos. Isto dispersa os engenheiros, reduz a produtividade até 40% e conduz à fadiga e a uma constante resolução de problemas– energia que poderia ter sido dedicada à criação das funcionalidades principais do produto.
- Erodir a confiança das partes interessadas: O SOS também transmite o sinal errado aos líderes empresariais. Quando as prioridades mudam com demasiada frequência e os prazos derrapam, a direção executiva pode começar a questionar a capacidade da engenharia para entregar resultados. Quando a confiança se perde, é difícil recuperá-la.
Evite arrepender-se do objeto brilhante: 3 perguntas de bom senso para a sua equipa
Já sabe o tipo de caos que o síndrome do objeto brilhante pode causar na sua equipa. Então, como determinar se essa nova biblioteca, SDK ou serviço vale a pena–antes de lhe consumir tempo e concentração? Os nossos especialistas têm algumas verificações essenciais:
- É uma “camada de adaptação” ou um “remendo”?
Sainath: o filtro ao lidar com novas ferramentas ou tecnologias é simples: isto resolve algo que importa a longo prazo ou é apenas um remendo?
“Um remendo limita-se a disfarçar casos extremos menores ou a cobrir limitações de curto prazo. Mas é provável que a próxima versão do modelo resolva isso de qualquer forma. E então aquilo que construiu fica instantaneamente desatualizado.”
Está mais interessado em criar camadas de adaptação–camadas limpas sobre modelos fundacionais que acrescentam utilidade real através do design, dos fluxos de trabalho ou do contexto.
“O termo LLM camada de encapsulamento foi usado de forma quase depreciativa no início, mas, fundamentalmente, muitos produtos valiosos são construídos sobre tecnologia subjacente,” comenta Sainath. “Vejam o Cursor. Pode-se argumentar que é apenas uma camada de encapsulamento, mas proporciona um valor significativo e direcionado.”
Na sua perspetiva, as soluções provisórias são distrações que podem facilmente transformar-se em objetos brilhantes. As camadas de encapsulamento bem concebidas, por outro lado, podem tornar-se produtos essenciais.
- O que estamos a escolher não construir?
Segundo Malhotra, acompanhar aquilo que a equipa decide não construir é tão importante como aquilo que chega ao roteiro. “Impede-nos de perseguir funcionalidades que podem parecer boas numa demonstração, mas que, na realidade, não melhoram o trabalho diário,” afirma.
Mesmo quando a equipa não tem confiança de que algo está pronto para uma implementação mais ampla, continua a testá-lo com os primeiros utilizadores. “Isso permite-nos obter feedback sem perturbar o roteiro.”
- Qual é o valor para o negócio?
Para o vice-presidente de engenharia da Customer.io, Paul Senechko, compreender o valor para o negócio subjacente aos esforços de engenharia é o primeiro e mais importante filtro. Se uma nova ferramenta ou sistema não servir nenhum dos dois, afirma, provavelmente não é o momento certo para o implementar.
“O princípio de liderança da nossa empresa é sermos especialistas nos clientes,” explica Senechko. “Usamos este princípio para orientar o nosso investimento em tecnologia, garantindo que construímos tendo em conta o cliente e o negócio.”
Para manter a sua equipa focada no essencial, Senechko baseia-se em algumas perguntas simples, mas poderosas: Quanto nos custa isto em termos de tempo e recursos? Isto melhora o nosso produto? Ajudará os nossos clientes a ter mais sucesso?
Sainath acrescenta a sua própria perspetiva, com aquilo a que chama perguntas do tipo “e se”: “O que acontece se a tecnologia subjacente ficar 10 vezes melhor? O nosso produto melhora inerentemente ou torna-se subitamente irrelevante?”
Também analisa o esforço necessário para concretizar essas melhorias: “Iremos beneficiar automaticamente desses ganhos ou será necessária uma grande rearquitetura para os acompanhar?”
Explorar estes cenários com a sua equipa pode ajudá-lo a tomar uma decisão, quer seja dar prioridade a esse novo e apelativo conjunto tecnológico, quer seja manter o que já está a funcionar.
À prova da Síndrome do Objeto Brilhante no seu roteiro (sem matar a inovação)
Quando uma nova tecnologia entusiasmante falha, é preciso encará-la com algum ceticismo e equilibrar a inovação com o progresso real.
Eis como os CTOs gerem o FOMO e mantêm as suas equipas focadas no essencial e concentradas:
- Defina critérios de saída para os projetos antes de começar
Muitos testes tecnológicos “exploratórios” transformam-se em projetos paralelos de longa duração, com um âmbito cada vez maior e dívida técnica recorrente, sobretudo porque ninguém define como ou quando terminam. Se não houver responsabilidade atribuída, um calendário ou critérios de sucesso, será apenas uma questão de tempo até a Síndrome do Objeto Brilhante levar todo o projeto ao fracasso. Para evitar isso, trate cada teste tecnológico como uma funcionalidade de produto: com âmbito definido, duração limitada, responsável atribuído e orientado por um verdadeiro caso de utilização.
Como explica Senechko: “Aplique a casos de utilização pequenos, mas reais, e avance a partir daí. Assim que decidimos experimentar novas tendências, certificamo-nos de identificar um espaço pequeno ou bem delimitado onde possamos testar e verificar se funcionam. Desta forma, podemos experimentar e adquirir experiência real com a tecnologia antes de fazer uma grande aposta nela.”
Envolva um avaliador de várias áreas (EM + PM + engenheiro sénior) para uma avaliação objetiva e crie um calendário estruturado que inclua:
- Duração máxima: limite a 2 iterações (+1 de margem) para o manter simples e testável
- Marcos de avançar/não avançar com condições de saída: defina um momento de revisão explícito em que a equipa decide se deve continuar, iterar ou parar (mais de 10% das compilações falharam ou falta de integração com a ferramenta de CI/CD).
Senechko sugere ainda que as equipas experimentem iniciativas com tempo fixo e âmbito variável, nas quais a sua equipa define inicialmente a “disponibilidade” de tempo que está disposta a dedicar e procura apresentar o resultado mais valioso dentro desse período. “Isto permitiu-nos inovar e falhar rapidamente quando essas novas direções não parecem estar a conduzir no sentido certo.”
- Utilize métricas para medir o sucesso
Depois de compreender a viabilidade técnica e a carga de trabalho de engenharia, defina o que significa ter sucesso. Essa é a diferença entre uma implementação disciplinada e um projeto SOS cujo âmbito se foi alargando. Crie um modelo que meça o sucesso em várias dimensões:
- Pessoas: aumento da produtividade dos programadores, aumento das horas de trabalho focado
- Processos e fluxos de trabalho: menor duração do conjunto de testes, redução das taxas de regressão, fluxos de implementação mais simples, redução do tempo de colocação no mercado
- Experiência do cliente: melhor desempenho das páginas, menos reclamações sobre a UX, melhoria dos tempos de resposta
- Desempenho do sistema: computação mais rápida, custos de infraestrutura mais baixos, menos incidentes ou reversões
- Conheça os seus clientes
“Manter o rumo depende de sermos honestos sobre onde é criado o valor para o cliente,” afirma Malhotra. “As tendências podem parecer empolgantes, mas podem rapidamente tornar-se distrações se não ajudarem diretamente os clientes a trabalhar melhor ou mais depressa.”
Esse princípio manifesta-se na forma como muitas equipas associam agora os departamentos de produto e engenharia à equipa de sucesso do cliente para acompanhamento no terreno. Alguns engenheiros participam em chamadas de suporte, sessões de integração ou reuniões de acompanhamento com clientes para receber comentários reais e sem filtros. Ouvir em primeira mão o que confunde os utilizadores, o que falha e o que é elogiado promove a empatia e pode até aperfeiçoar a definição de prioridades nas equipas de engenharia.
Mas ouvir, por si só, não é suficiente. Para identificar onde os clientes enfrentam realmente dificuldades, complemente os comentários qualitativos com telemetria do produto. É provável que a sua ferramenta de análise (PostHog, Amplitude, Heap) esteja a ser subutilizada para esse fim. Comece a acompanhar a forma como os utilizadores realmente interagem com o produto: ao nível dos cliques, dos controlos de ativação, dos ciclos de navegação e dos caminhos de erro.
Associe estes dados comportamentais aos pedidos de suporte para identificar padrões. Uma funcionalidade está a ser ignorada por ser difícil de encontrar? Os utilizadores não conseguem concluir fluxos de trabalho críticos? Use estes sinais de elevada relevância como gatilhos para projetos-piloto centrados no cliente.
Com o tempo, criará organicamente um formulário de “voz do cliente” com os problemas, os comentários, a satisfação e os obstáculos recorrentes dos clientes, que passam das equipas de sucesso para as decisões de produto e engenharia.
Foi o mesmo sistema que a equipa de Senechko utilizou para dar prioridade ao trabalho com base no valor mensurável para o cliente: “Um grande volume de clientes e requisitos de baixa latência levaram a nossa equipa a inventar soluções que as técnicas disponíveis no mercado não conseguiam concretizar. Investir na nossa plataforma técnica faz parte do ADN da nossa empresa, uma vez que vimos os benefícios dessa decisão para os clientes e para o negócio.”
Em última análise, o verdadeiro progresso da engenharia resultará da conceção de novas capacidades que ampliem aquilo que já funciona, e não da criação de soluções à sua volta ou da adição de algo completamente novo. É assim que as equipas evoluem sem comprometer sistemas comprovados.
“Inovação não tem de significar disrupção. Deve reforçar aquilo que já funciona e ajudar os clientes a avançar mais depressa com menos esforço,” resume Malhotra.
Quer mais informações como esta? Subscreva o boletim informativo do The CTO Club.
