Seu projeto funciona. O que ele revela sobre você como profissional?

Como apresentar sua contribuição, explicar suas decisões e mostrar o que você verificou em um projeto de estudo.

Imagine que você terminou um projeto de estudo, publicou o código no GitHub e colocou o link no currículo. A aplicação abre normalmente, as telas estão organizadas e as funcionalidades que você planejou estão funcionando.

No README, você descreveu as tecnologias utilizadas e incluiu algumas imagens da aplicação.

Até aqui, tudo bem. Mas quando alguém acessa esse repositório, consegue entender o que você realmente fez? Quais decisões tomou durante o desenvolvimento? O que aprendeu e como verificou se a aplicação estava funcionando?

Essas são algumas das coisas que procuro entender quando olho um projeto de alguém que está começando na área.

Um projeto simples pode render uma conversa técnica interessante. Já vi muita gente preocupada em adicionar mais funcionalidades ao portfólio quando poderia aproveitar melhor o que já desenvolveu, explicando as escolhas que fez e os problemas que encontrou.

Vamos usar um exemplo fictício para entender como trabalhar essa apresentação.

Comece explicando o problema

Imagine uma pessoa que trabalha no atendimento de uma empresa e está aprendendo desenvolvimento web. Para praticar, ela resolveu criar uma aplicação que permite cadastrar chamados, acompanhar o status e filtrar os registros por categoria.

Ao publicar o projeto, escreveu a seguinte descrição:

Sistema de chamados desenvolvido com HTML, CSS e JavaScript. Permite cadastrar, listar e filtrar registros.

A descrição está correta, mas eu gostaria de saber um pouco mais. Por que escolheu desenvolver esse sistema? Ele resolve algum problema que conhece do trabalho? É um protótipo ou foi pensado para uso real?

Uma descrição mais interessante seria:

Criei um protótipo para praticar a organização de chamados por categoria e status. Usei dados fictícios inspirados em situações de atendimento. A aplicação funciona localmente, sem contas de usuário ou integração com sistemas da empresa.

Percebe a diferença? Agora consigo entender de onde veio a ideia, qual era o objetivo do exercício e quais são os limites da aplicação.

Você não precisa inventar uma empresa atendida, dizer que resolveu um problema comercial ou apresentar resultados que nunca mediu.

Se o projeto foi desenvolvido para fins de estudo, diga isso. O contexto ajuda quem avalia a entender se as escolhas técnicas fazem sentido para o que você pretendia aprender.

O que você realmente desenvolveu?

Essa é uma parte que considero especialmente importante.

Muitos projetos de portfólio começam a partir de cursos, tutoriais ou exercícios propostos por professores. Não vejo problema nisso. O que eu gostaria de conhecer é a participação da pessoa no desenvolvimento.

Vamos imaginar que nosso sistema de chamados começou com um tutorial de cadastro de listagem de registros.

Durante o exercício, a pessoa percebeu que poderia aproximar a aplicação de uma situação que conhecia do atendimento. Acrescentou categorias, criou filtros por status e implementou uma validação para impedir o cadastro de chamados sem descrição.

Isso merece aparecer na apresentação.

Ela poderia escrever:

O projeto começou a partir de um tutorial de cadastro e listagem. Depois, acrescentei filtros combinados por categoria e status e uma validação para impedir o envio de chamados sem descrição.

Com essa informação, quem acessa o repositório consegue distinguir o que veio da referência original e o que foi desenvolvido depois.

Se o trabalho foi feito em grupo, eu seguiria a mesma lógica. Em vez de escrever apenas que a equipe desenvolveu uma aplicação, explicaria quais funcionalidades ficaram sob sua responsabilidade e em quais decisões participou.

E quando você usou IA?

Hoje, ferramentas de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → também fazem parte do processo de desenvolvimento de muita gente que está aprendendo. É natural que apareçam nos projetos de estudo.

O cuidado que eu teria é com a forma de apresentar essa participação.

Imagine que você pediu a uma IA que sugerisse o código de filtragem de chamados. A primeira versão funcionava com uma categoria por vez, mas você precisou adaptá-la para combinar a categoria e o status.

Uma descrição possível seria:

Usei IA para gerar uma primeira versão do filtro. Adaptei a lógica para combinar categoria e status e conferi os resultados usando registros de teste.

Essa explicação permite conversar sobre o que você fez depois de receber a sugestão.

Eu não vejo necessidade de documentar cada prompt utilizado. Prefiro entender o que a pessoa conseguiu avaliar, modificar e verificar.

E existe um cuidado importante: se você ainda não entende uma parte do código gerado, volte a ela antes de apresentar aquela implementação como algo que domina.

Isso também vale para códigos copiados de tutoriais, por exemplo, os encontrados no Stack Overflow de contribuições de outras pessoas.

Explique uma decisão técnica

Uma lista de tecnologias indica quais ferramentas você usou, mas diz pouco sobre as escolhas feitas durante o desenvolvimento.

No nosso exemplo, a pessoa decidiu manter os dados no navegador para concentrar o exercício na construção do formulário e na implementação dos filtros.

Foi uma escolha razoável para aquele objetivo. Ao mesmo tempo, ela trouxe limitações: os registros não ficam disponíveis para uma equipe e não há armazenamento compartilhado entre usuários.

Eu explicaria assim:

Nesta versão, mantive os dados localmente para concentrar o estudo na interface e nas regras de filtragem. Se o sistema fosse utilizado por uma equipe, precisaria implementar um armazenamento compartilhado e controlar o acesso aos registros.

É uma decisão simples, mas abre espaço para conversar sobre persistência de dados, backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → e autenticação, mesmo que esses recursos ainda não façam parte do projeto.

E nem toda decisão precisa envolver arquitetura.

Pense no que acontece quando alguém seleciona uma categoria e um status que não têm chamados correspondentes.

Você poderia simplesmente deixar a lista vazia. Mas também poderia exibir uma mensagem informando que nenhum registro foi encontrado e permitir que a pessoa altere os filtros.

Por que escolheu uma dessas opções?

Eu gosto desse tipo de exemplo porque mostra uma preocupação com o comportamento da aplicação que vai além de implementar apenas a funcionalidade principal.

Escolha uma ou duas decisões que realmente precisou tomar. Explique as alternativas que considerou e por que seguiu determinado caminho. Se encontrar uma limitação, pode mencioná-la também.

Não é necessário transformar uma decisão simples em uma discussão sofisticada sobre arquitetura de software.

Como você verificou que funciona?

Há uma diferença entre mostrar a aplicação funcionando e explicar como você conferiu o comportamento dela.

Uma demonstração em vídeo pode mostrar o cadastro de um chamado e o uso dos filtros. Mas eu também gostaria de saber o que acontece quando alguém tenta cadastrar uma descrição vazia ou combina filtros que não retornam resultados.

No nosso protótipo, alguns cenários merecem atenção:

• Tentar cadastrar um chamado sem descrição e verificar se a validação impede o cadastro.
• Selecionar uma categoria e um status para verificar se ambos os filtros são aplicados corretamente.
• Escolher uma combinação sem resultados e conferir a mensagem exibida.
• Abrir a aplicação em uma tela pequena para observar o comportamento do formulário e da listagem.

Você pode registrar esses cenários no README, indicando o resultado esperado e o que observou durante a execução.

Crie testes automatizados, mostre onde estão e explique o que verificam. Se fez testes manuais, diga que foram manuais. Não há motivo para apresentar uma verificação como algo diferente do que realmente foi feito.

Imagine que, durante os testes, você encontrou um problema: ao combinar categoria e status, um chamado que não atendia a nenhum dos dois critérios continuava aparecendo na lista.

Você investigou o filtro, identificou uma condição incorreta, fez a alteração e repetiu o cenário para conferir a correção.

Eu colocaria esse registro no projeto.

Ele permite entender como você investigou um problema e o que fez para verificar a solução. Dependendo da conversa, pode até ser mais interessante do que demonstrar uma funcionalidade que já estava funcionando desde o início.

Também não precisa afirmar que a aplicação está isenta de erros. Basta mostrar o que você verificou e reconhecer o que ainda não foi testado.

Vamos melhorar a apresentação do projeto

Lembra da descrição inicial?

Sistema de chamados desenvolvido com HTML, CSS e JavaScript. Permite cadastrar, listar e filtrar registros.

Depois de documentar o que foi desenvolvido, as decisões tomadas e as verificações realizadas, poderíamos apresentar o mesmo projeto desta forma:

Protótipo de estudo para organizar chamados fictícios por categoria e status, desenvolvido com HTML, CSS e JavaScript.

Comecei com um tutorial de cadastro e listagem e acrescentei filtros combinados e validação do formulário. Mantive o armazenamento local para concentrar a prática na interface.

Conferi manualmente o cadastro com campos vazios, as combinações de filtros e o comportamento quando não existem resultados. Durante os testes, corrigi um problema na aplicação simultânea dos filtros.

O próximo passo é criar testes automatizados para as regras de filtragem.

O exemplo continua sendo fictício. A ideia é mostrar como informações sobre o desenvolvimento podem melhorar a apresentação de um projeto sem precisar acrescentar funcionalidades.

Eu usaria essa descrição como introdução do README e deixaria o restante do arquivo para explicar como executar a aplicação, apresentar uma demonstração e documentar as decisões que merecem mais detalhes.

Também conferiria os links. Parece um detalhe pequeno, mas um repositório com instruções incompletas ou uma demonstração que não abre dificulta bastante a avaliação.

Quem chega ao projeto pode querer experimentar a aplicação ou ir diretamente ao código. É bom conseguir fazer as duas coisas sem precisar adivinhar por onde começar.

Revise um projeto que você já tem

Antes de começar outro projeto para colocar no portfólio, eu escolheria um dos que você já desenvolveu e faria uma revisão.

Estas são as cinco perguntas que usaria:

1. Problema: o que eu queria resolver ou aprender ao desenvolver essa aplicação?
2. Contribuição: o que veio de um tutorial, de outra pessoa ou de IA, e o que eu desenvolvi ou modifiquei?
3. Decisões: qual escolha técnica consigo explicar e quais limitações ela trouxe?
4. Verificação: quais cenários testei, como o fiz e onde posso mostrar os resultados?
5. Próximo passo: o que faz sentido melhorar e como vou verificar se a mudança funcionou?

Talvez você consiga responder algumas delas sem abrir o editor. Para outras, será necessário voltar ao código, executar a aplicação ou consultar o histórico de commits.

Eu faria esse exercício antes de reescrever o README. Às vezes, durante a revisão, você descobre que existe uma funcionalidade que nunca testou direito ou uma decisão que tomou seguindo um tutorial sem entender muito bem o motivo.

É uma boa oportunidade para estudar aquela parte.

Depois de atualizar a descrição, peça para alguém ler e explicar o que entendeu sobre sua participação no projeto. Se a pessoa não conseguir identificar o que você desenvolveu ou quais decisões tomou, provavelmente ainda há alguma informação que precisa ficar mais clara.

Se você também está trabalhando sua apresentação profissional, pode usar o Kit Marca Pessoal Tech v6.5, meu material gratuito com exercícios para organizar seu posicionamento e apresentar projetos com mais contexto.

Eu começaria por um único repositório. Escolheria aquele que conheço melhor, revisaria a documentação e tentaria explicar suas principais decisões como faria em uma conversa técnica.

Se durante essa conversa surgir uma pergunta que você ainda não sabe responder, anote. Pode ser justamente o próximo assunto que vale a pena estudar.