Introdução
Olá, meu nome é Felipe Nascimento, e atualmente sou engenheiro de software no Nubank. Gostaria de compartilhar com vocês algumas das lições valiosas que aprendi nos últimos três anos. São conselhos que eu daria ao Felipe do passado e que podem ser úteis para você na sua jornada profissional.
Sempre haverá Casos de Uso Peculiares
Começo com este ponto, pois os chamados “corner cases” são desafiadores. Para quem não sabe, são situações que ocorrem nos limites das regras de negócio de um produto, e você deve estar preparado para elas. Por exemplo, ao desenvolver uma API para cadastro de veículos, você pode assumir que só existem carros de 2 e 4 portas no Brasil. No entanto, é possível que algum dos 100 milhões de clientes tenha um carro com 1 ou 3 portas. Portanto, nunca subestime seus usuários. Esses casos, mesmo que raros, podem afetar seriamente a experiência do cliente e prejudicar a reputação da empresa. Ao trabalhar em um projeto de empréstimo com carros como garantia, observei que alguns clientes tentavam cadastrar caminhões ou até mesmo motos, além de, em alguns casos, tentarem usar veículos de terceiros.
Não se Apega a um Projeto ou Produto
Este foi um dos conselhos mais difíceis de aprender. Trabalhar em uma empresa grande permite que você experimente diversos produtos. Se os usuários não gostarem ou não utilizarem um produto, não faz sentido continuar a desenvolvê-lo, pois o custo de manutenção não trará retorno. Projetos que não se encaixam mais no escopo do seu time podem ser transferidos, ou um novo squad pode ser criado para aquele segmento. Então, por mais interessante que um projeto pareça, não se apegue a ele. Use as experiências como oportunidades para crescer e evoluir, tanto tecnicamente quanto em suas habilidades interpessoais. Ao final de cada projeto, recapitulo tudo o que fiz, reflito sobre o que poderia ter sido diferente, identifico os sucessos e vejo como poderia melhorar as entidades, criar algo reutilizável e otimizar minhas habilidades de produto. Perguntas como "Por que priorizamos isso?" e "Por que essa tarefa é prioritária?" devem ser feitas com frequência. Lembre-se: "Você não é apenas um codificador; seu papel como desenvolvedor vai além de escrever código."
Aprenda a Balancear a Dívida Técnica com o Valor do Produto
Essa habilidade é essencial. Às vezes, queremos apenas testar um produto ou tela com o cliente, e o esforço necessário para criar algo "robusto" pode não valer a pena. Em certas situações, um código menos performático pode ser aceitável temporariamente. Dívida técnica é quando algo precisa ser refatorado, há um bug que afeta uma pequena porcentagem de clientes ou um fluxo de código que não está performando bem. Ela existe e precisa ser gerida com cuidado.
Saiba o Valor das Suas Entregas
Nunca se esqueça de que você é o dono da sua carreira. É importante saber o valor que seu trabalho gera, inclusive monetariamente, para a empresa. Acompanhar resultados, como o número de acessos a uma plataforma ou a taxa de conversão de um produto, traz satisfação e fornece dados para a liderança avaliar seu trabalho. Esses resultados são fundamentais para promoções, pois só se é promovido fazendo um bom trabalho.
É Difícil Conquistar um Cliente e Fácil Perdê-lo
Um bug ou uma experiência ruim pode facilmente afastar um cliente do seu produto ou empresa. Uma introdução mal projetada em um aplicativo pode fazer com que um cliente desista antes mesmo de começar a usá-lo. O cliente deve ser o foco das suas melhorias, e você nunca deve subestimar o impacto de um bug, que pode diminuir drasticamente a taxa de conversão. Às vezes, o time de Business Analytics não compreende a causa do problema, que pode ser algo tão simples quanto um botão que não funciona ou uma tela de transação que não carrega corretamente.
Saiba Dividir as Entregas
Tenha versões que entreguem valor tanto para o cliente quanto para a liderança. Seu manager quer ver progresso, e é essencial ter escopos bem definidos para que você possa lançar e aprender com cada iteração. Com versões definidas, há mais clareza nos prazos de entrega, deixando seu gestor mais tranquilo ao saber exatamente quando o projeto será entregue.
Não Subestime a Observabilidade
A observabilidade é crucial. Como mencionei na dica anterior, uma experiência negativa pode custar um cliente. Sem alertas de latência, erros ou logs, como você saberá que há um problema? A saúde do sistema, incluindo CPU e memória, deve estar sempre monitorada. Aprenda a diferenciar os tipos de erros e utilize as ferramentas disponíveis, como Grafana, Splunk e Sentry, para garantir que o serviço está funcionando adequadamente.
Entenda o Conceito de MVP
Um dos maiores erros das equipes de produto é não definir corretamente o Produto Mínimo Viável (MVP). MVP significa criar a versão mais básica de um produto que ainda satisfaça os requisitos essenciais, testando assim uma hipótese. Trabalhe juntamente com sua equipe para determinar o que é realmente necessário na fase inicial, evitando o desenvolvimento excessivo que não foi validado como necessário.
Aprenda a Equilibrar o Escopo Técnico
Lembre-se das dívidas técnicas que mencionei anteriormente. Elas podem se acumular e prejudicar o time no futuro. Assegure-se de que uma parte das tarefas do time seja voltada para melhorar esses pontos, mesmo que não gerem valor direto para o usuário. Se não fizer isso, a dívida técnica acabará cobrando seu preço.
Considere o Custo de NÃO Desenvolver
Deixei o melhor para o final. Cada projeto ou produto deve se justificar, ou seja, precisa ser lucrativo. É importante participar das discussões iniciais sobre custos e viabilidade. Por que desenvolver algo que não atende ao perfil dos clientes, incorrendo em custos de desenvolvimento e manutenção? Participe dessas discussões e use dados para fundamentar sua opinião, como estudos de caso que mostrem que um produto pode não ser adequado para os clientes atuais, ou que a melhoria de um fluxo existente possa trazer mais valor.
SOCIAL SHARE CARD GENERATOR