A primeira vez que alguém usou meu sistema

Existe um momento muito interessante na vida de qualquer projeto.

Não é quando você termina uma funcionalidade.

Não é quando o deploy dá certo.

Nem quando você resolve aquele bug que estava te incomodando há dias.

É quando outra pessoa usa o software pela primeira vez.

Desenvolver e usar são coisas diferentes

Quando passamos semanas ou meses trabalhando em um projeto, acabamos conhecendo cada detalhe dele.

Sabemos onde cada botão está.
Sabemos quais ações devem ser realizadas.
Sabemos o caminho correto para chegar a cada funcionalidade.

Na prática, nos tornamos especialistas no nosso próprio sistema.

E isso cria uma ilusão perigosa:

acreditar que aquilo que é óbvio para nós também será óbvio para outras pessoas.

O usuário sempre encontra algo que você não viu

Uma das experiências mais curiosas no desenvolvimento de software é observar alguém utilizando uma aplicação pela primeira vez.

Muitas vezes o código está correto.

Não existem erros.

Não existem falhas aparentes.

Mas em poucos minutos começam a surgir situações como:

• dúvidas sobre o que fazer;
• dificuldade para encontrar uma funcionalidade;
• interpretações diferentes daquilo que foi planejado;
• expectativas que não haviam sido consideradas.

E isso acontece porque usuários não enxergam o sistema da mesma forma que quem o desenvolveu.

Nem todo problema é um bug

Quando pensamos em problemas de software, normalmente imaginamos erros técnicos.

Mas alguns dos feedbacks mais valiosos não têm relação com código.

Eles têm relação com experiência.

Um nova funcionalidade.
Uma informação que não está clara.
Um fluxo que exige cliques desnecessários.

São situações que dificilmente aparecem durante o desenvolvimento porque o criador do sistema já conhece todas as respostas.

O melhor teste nem sempre é automatizado

Testes automatizados são importantes.

Testes manuais também.

Mas existe um tipo de validação que muitas vezes é subestimado:

Ver uma pessoa real utilizando aquilo que você construiu.

Em poucos minutos, é possível descobrir problemas que passaram despercebidos durante semanas.

Não porque o software está quebrado.

Mas porque pessoas diferentes interagem com ele de formas diferentes.

Um aprendizado que tive em um projeto pessoal

Recentemente tive a oportunidade de observar não apenas uma pessoa, mas diversas pessoas utilizando um projeto que desenvolvi inicialmente para estudos.

A experiência foi interessante porque várias sugestões surgiram rapidamente.

Nenhuma delas envolvia grandes mudanças técnicas.

E justamente por isso foram tão valiosas.

Elas mostraram diferenças entre:

• aquilo que eu imaginava que seria útil;
• aquilo que realmente ajudava quem estava utilizando o sistema.

Foi um lembrete importante de que software é feito para usuários, não para desenvolvedores.

Talvez seja por isso que projetos públicos são tão valiosos

Quando um projeto fica restrito ao computador do desenvolvedor, boa parte desses aprendizados nunca acontece.

Mas quando ele passa a ser utilizado por outras pessoas, surgem novos desafios:

• usabilidade;
• comunicação;
• feedback;
• manutenção;
• evolução do produto.

E é nesse momento que muitos projetos deixam de ser apenas exercícios técnicos.

Então...

Uma das formas mais rápidas de aprender sobre software não é escrever mais código.

É permitir que outras pessoas utilizem aquilo que você já construiu.

Porque, quase sempre, elas enxergarão coisas que você nunca percebeu.

E muitas vezes os melhores aprendizados surgem exatamente dessas descobertas.