Um pequeno problema no pedido de um cliente revelou uma das maiores exigências de construir produtos digitais: cuidar do que acontece no uso real.
Era sábado, depois das dez da noite, quando fui acordado por causa de um tomate.
Um cliente não conseguia retirar o ingrediente de um lanche no aplicativo do Madero. Ele acionou o suporte do Madero. O suporte acionou o diretor, que acionou a minha equipe, que me acionou. A dificuldade percorreu esse caminho até conseguirmos resolver o problema daquela pessoa.
Para quem olha de fora, pode parecer uma mobilização enorme por causa de um tomate. Para mim, esse episódio ajuda a explicar por que gosto tanto desse projeto.
Aquela pessoa não virou simplesmente um número.
A qualidade aparece nos detalhes de uso
Muita gente me diz que gosta do aplicativo do Madero e o considera uma referência entre os aplicativos de delivery. Eu prefiro observar o que existe por trás dessa percepção.
O aplicativo não precisa de muita firula para cumprir seu papel. Seu valor está em permitir que a pessoa escolha o que quer, personalize o pedido e compre com facilidade.
Só que entregar essa experiência exige atenção constante ao produto.
Retirar um ingrediente pode parecer um detalhe pequeno durante uma apresentação de funcionalidades. Para o cliente que quer fazer aquele pedido, é uma necessidade concreta. Se ele não consegue, o aplicativo deixou de atender ao que precisava naquele momento.
É nesse nível de detalhe que percebo a exigência da equipe do Madero. A experiência não é avaliada apenas pela quantidade de recursos disponíveis, mas pela tranquilidade com que uma pessoa consegue concluir uma tarefa simples.
O trabalho continua depois de resolver o atendimento
No caso daquele sábado, identificamos a causa raiz e aplicamos a correção no release seguinte.
Mas resolver o problema de uma pessoa era apenas a primeira parte. Existe também uma exigência de documentação sempre que acontece um incidente: explicar o que gerou a falha, como ela foi resolvida e por que a correção deve impedir que volte a acontecer.
Esse processo obriga a equipe a compreender o incidente e justificar a solução adotada. O aprendizado fica registrado e pode orientar o trabalho seguinte.
Resolver a dificuldade de um cliente é necessário. Usar aquele episódio para melhorar a experiência dos próximos amplia o valor do atendimento.
Com o tempo, essa disciplina vai refinando o produto: uma dificuldade identificada, uma causa compreendida, uma correção aplicada. Depois outra. E outra.
O uso real sempre encontra alguma coisa
Por mais cuidadoso que seja o planejamento, o uso real revela situações que não aparecem em uma reunião, em um protótipo ou em uma demonstração.
É quando milhares de pessoas escolhem produtos diferentes, usam aparelhos diferentes, mudam de ideia no meio do pedido e tentam concluir uma tarefa em condições que a equipe não imaginou completamente.
Isso não significa que um produto foi mal planejado. Significa que software é uma experiência viva. A qualidade não é uma condição alcançada uma vez e mantida para sempre; é uma prática de observação, correção e evolução.
Evoluir também é aperfeiçoar o que já existe
Em projetos de tecnologia, é fácil preencher a agenda com novas funcionalidades. Sempre existe uma ferramenta para incorporar, uma tela para redesenhar ou uma ideia interessante para colocar no planejamento.
A experiência com o Madero me faz valorizar também o esforço dedicado ao que já está nas mãos do cliente.
O fluxo que precisa ficar mais claro. A personalização que deveria funcionar sem dificuldade. O problema que apareceu em um atendimento e merece ser entendido até a causa.
Essa evolução pode ser pouco chamativa em uma demonstração, mas faz diferença quando alguém abre o aplicativo para pedir um lanche.
Para mim, o básico bem feito exige essa disposição de voltar ao produto e aperfeiçoá-lo continuamente. Não é falta de ambição. É uma forma mais séria de respeitar quem usa o que construímos.
Uma referência para quem desenvolve aplicativos
Como fundador da Alphacode, gosto de participar de projetos que nos exigem esse cuidado. A qualidade depende das escolhas de desenvolvimento, mas também da atenção que a empresa dedica ao que acontece depois que o aplicativo chega ao cliente.
O episódio do tomate ficou na minha memória porque tornou essa postura muito concreta. Havia uma pessoa tentando fazer um pedido, e a dificuldade dela mereceu atenção, investigação e uma correção no produto.
Quando penso no que faz um aplicativo ser bom, penso também nisso: na capacidade de tratar uma pequena fricção como informação importante, e não como um caso isolado que pode ser esquecido assim que o atendimento termina.
Na sua empresa, o que acontece com a dificuldade relatada por um único cliente?
Até onde ela consegue chegar dentro do produto?