O NevaBridge não começou como produto. Começou como a nossa própria dor – milhares de relatórios de erro vagos, numa plataforma que nós próprios operamos. Por isso construímos a camada que faz as perguntas certas, antes de um ticket chegar a um programador.
A equipa por trás do NevaBridge também opera o Calendall, um popular sistema de gestão de clientes e marcação de horários para salões. Todas as semanas chegavam pedidos de clientes por e-mail, chat e tickets de apoio: perguntas, ideias de funcionalidades e relatórios de erro. Cada um tinha de ser lido, compreendido e encaminhado para o sítio certo. E quando era um relatório de erro? Os nossos programadores quase sempre tinham de pedir esclarecimentos. Que browser? Que ecrã? Em que carregaste exatamente antes de deixar de funcionar?
Os relatórios não eram maus. Eram apenas incompletos. E cada pedido de esclarecimento custava tempo, contexto e paciência de ambos os lados. Medimo-lo: 44% de todos os relatórios de erro precisavam de pelo menos uma ronda de esclarecimento antes de um programador sequer poder começar. Alguns precisavam de três ou quatro rondas.
Procurámos uma ferramenta que resolvesse este problema na origem. Um fluxo de trabalho que faz as perguntas certas antes de o ticket chegar ao programador. Não encontrámos nenhuma.
Por isso construímo-la nós próprios. O que começou como uma ferramenta interna para a nossa própria equipa de apoio tornou-se o NevaBridge.
de todos os relatórios de erro precisavam de pelo menos um esclarecimento antes de um programador poder começar
mais tempo até à primeira resolução em relatórios incompletos
Não tentámos construir um produto. Tentámos resolver a nossa própria dor. O NevaBridge existe porque mais ninguém resolveu este problema para equipas como a nossa.
A nossa equipa fundadora construiu e operou a plataforma onde vivemos este problema pela primeira vez. Lidámos com milhares de interações de apoio, fizemos nós próprios a triagem de centenas de relatórios de erro e sentimos na pele a dor dos tickets vagos. Não lemos este ponto de dor num relatório de mercado. Vivemo-lo durante semanas, ao longo de anos.
Quando começámos a desenvolver o NevaBridge, trouxemos para a equipa um CTO que conhecia o mesmo padrão do outro lado. Como Senior Software Engineer na AWS, esteve durante anos do lado de quem recebe relatórios de erro incompletos, mesmo numa empresa com alguns dos processos de engenharia mais maduros do setor. O problema não era exclusivo nosso. Era estrutural.
Esta combinação molda o NevaBridge. Um lado da equipa sabe o que significa operar um produto, falar com clientes e proteger o apoio do ruído. O outro lado sabe o que um programador realmente precisa para começar um issue – e quão caro fica quando essa informação falta. Não porque pedir esclarecimentos demore, mas porque cada pergunta é reenviada, espera horas ou dias por uma resposta, e o programador já está há muito a trabalhar noutra coisa. O NevaBridge nasce na interseção das duas perspetivas.
a operar uma plataforma SaaS com utilizadores reais e volume de apoio real
a desenvolver software enterprise, de startups ao setor público até ao papel de Senior Engineer na AWS.
Não construímos a partir da teoria. Construímos a partir de milhares de conversas reais, tickets reais e frustração real de ambos os lados da entrega.
O NevaBridge está numa fase inicial. Estamos a construir o primeiro módulo: relato interno de erros. Um membro da equipa descreve um problema em linguagem natural. O NevaBridge analisa o que existe, deteta o que falta, faz perguntas de seguimento específicas e cria um ticket estruturado, pronto para o programador, no vosso gestor de issues.
Não é um chatbot genérico montado sobre um formulário. O NevaBridge funciona em três níveis. À partida, já sabe o que os programadores normalmente precisam num relatório de erro – construído a partir da nossa própria experiência a desenvolver produtos, a trabalhar com clientes-piloto e a analisar gestores de issues open-source. Além disso, podem alimentá-lo com a vossa própria documentação de produto e conversas anteriores sobre erros, para que aprenda a vossa terminologia, as vossas funcionalidades e os vossos issues conhecidos. E podem criar modelos de relatório próprios, a par do nosso modelo inicial já comprovado. O NevaBridge escolhe o adequado para cada conversa.
É esta combinação que transforma uma frase vaga num ticket em que um programador pode trabalhar de imediato – sem uma única pergunta de seguimento.
Começamos onde a dor é maior. Os relatórios de erro são o ponto onde a lacuna entre o que as pessoas dizem e o que os programadores precisam é maior. Fazer esta única coisa bem é a base para tudo o que se segue.
Usamo-lo nós próprios, todos os dias. E procuramos equipas que conheçam a mesma dor.
módulo em produção, deliberadamente focado
perguntas de seguimento necessárias quando é o NevaBridge a escrever o ticket
Preferimos entregar agora um módulo que resolve um problema real do que deixar as equipas à espera até os três estarem prontos.