[PITCH]: Como eu transformei minha briga com QA e usuários em um produto SaaS · sideantunes

Opa, e aí, pessoal, tudo bem? Hoje é meu primeiro post aqui no tabnews 🚀 e neste post eu quero contar um pouco de como minhas frustrações resolvendo bugs reportados por usuários e QA me fizeram criar o Logaflow.

Mas antes de falar sobre o Logaflow, eu quero contextualizar vocês um pouco sobre o problema ~~doido da po*a~~ que me fez tirar essa solução do papel.

O problema que originou o Logaflow

Se você é dev, com toda a certeza do mundo eu posso afirmar que você já deve ter passado pela seguinte situação:

Um cliente do projeto que você atua reporta um bug.
Esse report chega na sua board do Jira (ou qualquer outro gerenciador de tarefas) somente com um título e talvez ~~mas muito talvez mesmo~~ um print do bug.

E aí começa o seu teste de paciência...

Pois você só tem um card dizendo que aconteceu X problema com o cliente e você que se vire para arrumar.

Se você tiver sorte, você logo irá saber o que houve com o usuário, porém, na maioria dos casos, sabemos que não é assim!. E que, na real, você vai:

Pegar esse card priorizado.
Tentar replicar o problema que aconteceu com o usuário.

Para depois disso, você começar a trabalhar na solução do mesmo.

E isso se realmente o problema puder ser replicado, pois sabemos que muitas vezes os problemas ocorrem porque o "usuário não sabe usar a ferramenta".

E esse foi só um dos primeiros dos muitos casos que acontecem no nosso dia-a-dia...

Um outro caso muito comum, que já testou a paciência de MUITOS DEVs é este:

O QA do seu time vai testar as features da sprint.
Encontra uma porrada de problemas.
Cria os cards para você.
Porém, esquece de descrever como replicar o problema...

Daí, quando você pega um dos cards para corrigir...

O bug NÃO ACONTECE COM VOCÊ.

Eu sei, eu sei, isso é de tirar qualquer um do sério...

Com esses tipos de situações, você acaba tendo que aumentar o número de reuniões em seu calendário para poder refinar cards que já deveriam estar refinados.

E isso me fez me perguntar:

Pow, não existe nenhuma solução que ajude meu QA, a evidenciar os bugs que ele encontrou, junto com o fluxo que ele seguiu de forma simples? 🤔🤔🤔

A meia solução

Depois de me fazer essa pergunta eu saí em busca de uma ferramenta que ajudasse pelo menos o pessoal do meu time a reportar os problemas de forma simples.

O que eu queria era uma solução que:

Conseguisse de alguma forma gravar o passo a passo para replicar um problema.
Conseguisse me mostrar, além dos logs do console, as requests feitas durante aquele fluxo em que o bug ocorreu.
Informações de ambiente do usuário, como navegador, sistema operacional, tamanho de tela, etc. Para que eu possa saber em que contexto o problema que ele reportou aconteceu.

Uma ferramenta dessa iria agilizar e muito meu lado, eu pularia todo o estresse de busca de informações e iria diretamente para a correção do problema!

E depois de procurar bastante, eu acabei encontrando uma ferramenta chamada https://jam.dev, que fazia tudo isso com maestria... Porém, nem tudo são flores...

O jam.dev era mágico, mas tinha um problema que o tornava inviável no meu time... Ele era uma extensão do Chrome...

Nada contra as extensões do Chrome, porém, para o problema que a jam.dev visa resolver, isso acaba levantando várias dúvidas de limitações:

E se alguém do meu time encontrar um problema e não estiver usando Chrome? 🤔
E o usuário? Como que eu vou pedir para o usuário instalar uma extensão, para que se caso aconteça um problema, ele me reporte através dela? 🤔
Só funciona para Chrome. E os outros browsers? 🤔
E para mobile? Os browsers mobile não têm extensões 🤔.
E se o pessoal não quiser instalar a extensão? 🤔

Até porque a extensão do jam.dev fica injetando scripts que são necessários para o funcionamento, em todas as abas que ele tem acesso...

O pessoal de segurança não iria deixar essa aplicação ser usada tão facilmente.

Bem, depois de encontrar esses problemas que o jam.dev iria me trazer, eu tive duas opções:

Deixar isso de lado e voltar ao meu estresse com bugs reportados sem informações pelos clientes. E trocar socos com o QA, para que ele não se esqueça de descrever o fluxo nos cards abertos por ele.
Fazer um Jam.dev melhorado.

Obviamente eu escolhi a segunda opção, até porque eu via um produto muito promissor na minha frente que resolvia um problema que eu mesmo estava sentindo a dor.

Então, para construir este produto, eu levantei 3 pontos importantes que minha solução deveria seguir:

A ferramenta tem que ser simples tanto para o usuário, quanto para meu time reportar bugs.
Esses reports devem vir com informações que acelerem o processo de debug, para que eu não perca tempo tentando descobrir o que houve (Como logs, replays, requests, ambiente e etc).
Não pode ser uma extensão. Pois isso limitaria o uso por usuários, dificultaria a entrada dentro de empresas e também não iria funcionar em navegadores mobile.

O início do Logaflow

Com os pontos definidos, a primeira coisa que eu fiz foi buscar uma forma de validar a idéia. Porque se eu quisesse transformar isso em um produto, eu deveria saber logo de início se alguém iria pagar por ele.

Para fazer isso, eu comecei definindo o público-alvo dessa solução:

QAs (sentem a dor por conta dos atritos com os devs)
Desenvolvedores (sentem a dor por conta do estresse que a falta de informação causa)
PO e donos de negócios (pois se um cliente reporta um problema, ele quer que esse problema seja corrigido rapidamente. A falta de informação causa atraso na correção e assim deixa o cliente mais pistola com o produto, podendo ocorrer até o famoso abandono da solução)

Com as personas definidas, eu criei um form no Google Forms, entrei em vários grupos de desenvolvedores, QAs e indie hackers para divulgar a idéia e conseguir pessoas para entrarem na wait list.

O resultado do forms foi um sucesso! E acabei descobrindo que a maioria dos interessados eram pessoas que possuíam Software Houses:

pie title Área dos interessados
"Software House" : 5
"Gestor de time" : 3
"QA" : 4
"Desenvolvedor - Front-end": 2
"Desenvolvedor - Full-stack": 6
"Founder": 1

Com esses dados em mãos, eu pude considerar a idéia validada, pois eu vi que tinha demanda (afinal, o jam.dev já contava com mais de 100k de usuários, mesmo sendo uma extensão que só funciona no Chrome). Vi que tinham pessoas interessadas em usar a solução que eu tinha proposto, então já poderia meter a mão na massa.

Nasce o Logaflow

Com todos os pontos anteriores validados, eu só precisei meter a mão na massa! Comecei definindo o banco de dados, depois a linguagem que eu usaria para back-end, o que eu usaria no front, nas libs, etc...

Bem, essa parte merece um post à parte, então vou deixar para detalhar ela melhor um pouco mais pra frente hehehe.

No final, fiquei 2 mêses codando o produto que eu chamei de Logaflow.

Loga vem de log e flow de fluxo 💬

O Logaflow acabou se tornando uma ferramenta de gerenciamento de feedback, que, além disso, vem com o bônus de que cada feedback recebido vem com informações importantes que contextualizam a pessoa que enviou o feedback. Como:

Logs do console e de requisições que foram feitas até 1 minuto antes do feedback ser enviado.
Replay de até 1 minuto das últimas ações da pessoa que enviou (o que ajuda a entender o fluxo que ele seguiu).
Informações de ambiente (se é no Chrome, no Edge, no navegador do iPhone ou do Android, tamanho da tela, etc...)
Coleta de feedback para além de só bugs (assim o Logaflow pode ajudar também na evolução do produto, não sendo mais necessário o uso de outra ferramenta para isso).
Integração via webhooks (imagina o quanto de automação dá para fazer com cada feedback que seu projeto receber 🤔🚀).
Uma fuck**g tela Kanban para você e seu time poderem acompanhar o status de cada feedback 🚀🚀🚀

E tudo isso sem usar extensão! Pois, por ser um widget, você pode instalá-lo em qualquer projeto seu, então, seu cliente não precisa instalar nada!. Além de ter pacotes específicos para integrar em suas aplicações front-end (como Next, React, Angular, etc).

Eu resumi bastante a história do Logaflow, pois foram muitos desafios até o produto chegar ao estágio que está hoje.

Então hoje você não precisa mais passar por esse estresse. Mostre Logaflow para seu time, tenho certeza que eles e seus usuários vão adorar 🚀🚀🚀

Irei trazer um post específico falando sobre as tecnologias que utilizei, como consegui o primeiro cliente assinante e outros assuntos que ajudem vocês a tirarem do papel suas ideias. Então, se puderem deixar suas dúvidas aí nos comentários, talvez eu crie até um post específico para elas.

Eu sou muito ativo la no twitter, onde trago updates rapidos sobre meus projetos. Caso queiram seguir, meu arroba é itscodetunes

Ahhhhh, eu criei um canal no YouTube onde irei criar conteúdo voltado para programadores que querem construir seus próprios produtos. Logo menos vou estar postando em video a história do Logaflow la, e quem sabe comemorando os 1k de assinantes. 🚀🚀