Depois de muitos anos trabalhando com desenvolvimento de software, uma coisa ficou clara para mim: método e conhecimento técnico ajudam — e muito — mas sozinhos não resolvem tudo.

No artigo anterior, falei sobre o MAP (Método, Antecipação e Planejamento) como uma forma de evitar o improviso e trabalhar com intenção. E continuo acreditando nisso.

Mas existe uma camada anterior ao método que, se não estiver bem resolvida, faz qualquer processo falhar — seja ele ágil, tradicional ou híbrido.

Essa camada é formada por duas coisas simples de dizer, mas difíceis de praticar: postura de liderança e comunicação interpessoal.

E isso fica ainda mais evidente quando falamos de equipes remotas e distribuídas.

O problema pode não estar apenas no processo

É comum ver times adotando Scrum, Kanban ou qualquer outra metodologia esperando que isso resolva os problemas do projeto.

Mas, na prática, o que acontece muitas vezes é:

- Reuniões frequentes, mas pouco produtivas;

- Decisões que não ficam claras;

- Desalinhamento entre time técnico e negócio;

- Retrabalho constante.

Ou seja: o método está lá — mas o projeto continua sofrendo.

Isso acontece porque processo nenhum substitui comportamento.

Liderança não é cargo — é postura

Quando falo em liderança aqui, não estou falando necessariamente de um gerente ou coordenador. Estou falando de comportamento no dia a dia.

É a pessoa que:

- assume responsabilidade quando algo sai do esperado

- organiza a informação quando tudo está confuso

- ajuda o time a tomar decisões com mais clareza

- evita que problemas pequenos virem grandes

Sem isso, qualquer método vira apenas um conjunto de rituais vazios — o que normalmente chamo de “sopa de letrinhas”. Daily, planning, sprint, review: tudo acontecendo, mas sem uma evolução clara. Quando não há postura de liderança, o processo existe, mas o projeto não se sustenta.

Comunicação não é reunião — é clareza contínua

Isso é fato: comunicação é a base de qualquer projeto. Mas não é só falar — é garantir que a mensagem seja entendida da forma correta. Aqui existe um erro comum: achar que comunicação é sinônimo de reunião. Principalmente em times remotos, isso fica ainda mais evidente.

Você pode ter várias reuniões por semana, canais ativos no Slack ou Teams, pilhas de documentos no Drive e, mesmo assim, enfrentar desalinhamentos no time. Isso acontece porque boa comunicação não é quantidade de encontros, mas sim clareza e constância.

Aqui estão alguns sintomas de comunicação que podem melhorar:

- Decisões que só existem “na cabeça” de alguém, ou que são unilaterais;

- Requisitos interpretados de formas diferentes e não discutidos com o time;

- Dúvidas que ficam sem esclarecimento;

- Silêncio diante de riscos ou problemas, esperando que alguém perceba.

O maior problema é que a “bomba” não explode no começo, mas aparece depois em forma de especificação errada, retrabalho, atraso ou desgaste no time. Problemas de comunicação não quebram o projeto imediatamente — mas cobram juros ao longo do tempo, muitas vezes passando despercebidos até que seja tarde.

O desafio maior: Equipes Remotas X Distribuídas

Neste ponto temos dois cenários: o time trabalhando em um mesmo espaço físico x time trabalhando de forma remota e distribuída. O trabalho é o mesmo, as demandas também. Mesmo assim, a dinâmica de comunicação e troca de ideias muda completamente.

Vejamos então o que acontece com a equipe que trabalha presencialmente:

- Muitos problemas ainda são “corrigidos” informalmente, com aquela conversa rápida no corredor, passando na mesa do colega ou durante o café.

- Dúvidas são tiradas no momento, sem precisar marcar uma reunião ou abrir um canal de comunicação.

- Ajustes são feitos com base na percepção do time e na troca de ideias que acontece naturalmente.

Com a equipe remota, a dinâmica é outra:

- A comunicação precisa ser mais intencional, porque não existe o “olho no olho” para perceber o que ficou implícito.

- As conversas informais precisam ser substituídas por momentos planejados de troca de ideias, para evitar que o time fique com dúvidas ou perceba riscos, mas não saiba como falar sobre isso.

- O silêncio, que em um time presencial pode ser preenchido com a percepção do ambiente, toma uma proporção maior e pode se tornar um risco real, porque ninguém sabe o que está acontecendo na cabeça do colega.

Para garantir comunicação clara e time alinhado, mesmo à distância, é preciso:

- O implícito precisa virar explícito;

- O informal precisa virar intencional;

- O silêncio passa a ser um risco real que precisa ser tratado com cuidado.

Neste ponto, as duas equipes tem um ponto crítico que vira ouro quando prestamos atenção: escutar.

Escuta ativa e troca de ideias: agora vai?

Com todo o tempo de experiência que eu tenho, posso dizer que o maior desafio de comunicação não é falar — é ouvir. E ouvir de verdade, com atenção e intenção. Digo isso depois de ter ouvido, durante uma discussão sobre o que dava ou não dava pra ser feito, uma frase de um dos meus professores que ficou marcada na minha memória: “Tu precisa ser um péssimo programador e um razoável analista e, além de tudo, ouvir muito mais do que falar. Lembra disso”. Escutei isso quando tinha uns 18 ou 19 anos. E isso é algo que eu levo comigo até hoje, porque é a pura verdade.

Em resumo, comunicação não é só falar bem — é ouvir de verdade. E isso vale para todos: desenvolvedores, áreas (negócio, produto, técnico) e stakeholders.

Algumas situações comuns que acontecem quando não se pratica escuta ativa:

- o solicitante explica o problema, mas o time entende só a parte técnica, sem captar o contexto completo;

- o desenvolvedor percebe um risco, mas não o expõe, esperando que alguém mais perceba ou que o problema se resolva sozinho;

- alguém discorda, mas prefere não entrar em conflito e “deixa por isso mesmo”.

O que acontece quando não se pratica a escuta ativa?

O resultado disso é previsível: decisões frágeis e problemas que aparecem durante todo o ciclo de vida do projeto. A escuta ativa muda esse cenário, porque traz:

- Validação de entendimento (“foi isso que você quis dizer?”)

- Abertura de espaço para discordância

- Possibilidades quando se incentiva perguntas antes da execução

- Tratar ideias como construção coletiva, não disputa

Veja bem: bons projetos ou features não nascem de ideias individuais — mas da troca consistente entre as pessoas.

Expandindo o MAP: método também é sobre pessoas

No artigo anterior, eu apresentei o MAP como um modelo para desenvolvimento de software. Vejamos então como podemos expandir esse conceito para o comportamento do time.

M — Método (de interação)

Não é só como o código é escrito — é como o time se comunica. Observe que isso não é só sobre o processo, mas sobre como as pessoas interagem — e isso impacta diretamente a qualidade do projeto. Para que o método seja efetivo, é preciso ter clareza sobre:

- Como decisões são registradas?

- Onde as informações importantes ficam?

- Existe um padrão de comunicação?

Sem isso, o método vira um ritual vazio. E embora cada pessoa pense, interprete e aja de forma diferente, isso não é algo que se controla — é algo que se direciona. Para tanto, é preciso comunicação clara e um ambiente onde as pessoas se sintam seguras para falar, discordar e contribuir. No fim das contas, o método é tão bom quanto a forma como as pessoas o utilizam.

A — Antecipação (de problemas humanos)

A antecipação não pode ser apenas técnica, mas também humana. Antecipar problemas de comunicação, conflitos ou sobrecarga é tão importante quanto antecipar bugs. Para isso, é preciso perceber:

- Quando alguém está sobrecarregado;

- Quando algo não ficou claro;

- Se existe um conflito não resolvido.

Perceber isso evita retrabalho, desgaste e perda de confiança.

P — Planejamento (de comunicação)

Aqui, planejamento significa definir como a informação circula. Basicamente envolve:

- Quem precisa saber o quê

- Quando comunicar

- O que precisa ser registrado

Aqui vem aquela frase clássica que gera problemas:

“Depois a gente alinha”

Na prática, esse “depois” quase sempre vira problema. Se as definições não ficam claras e o “depois” muda, voltar atrás custa caro — gera desordem, ruído e distorção. A informação não registrada se perde, e isso cria um efeito dominó de problemas que aparecem quando o projeto já está em andamento.

O custo invisível da má comunicação

Diferente de um bug, problemas de comunicação não aparecem em logs e são mais complicados de resolver. Mesmo assim, a má comunicação tem um custo bem visível com efeitos claros:

- Retrabalho constante;

- Decisões inconsistentes;

- Desalinhamento com a equipe (e os stakeholders);

- Perda de confiança no time;

- Desgaste emocional e frustração.

A longo prazo, isso custa muito mais caro do que qualquer problema técnico.

Sou um Líder, o que posso fazer para melhorar?

Como líder, gerente de equipe ou mesmo gerente de projeto, algumas atitudes simples fazem muita diferença na rotina do time, como:

- Tornar explícito o que está implícito;

- Perguntar mais do que assumir;

- Registrar decisões importantes;

- Contextualizar, não apenas distribuir tarefas;

- Trazer problemas cedo, não quando já viraram urgência;

- Incentivar a troca de ideias, não a disputa de opiniões;

- Evitar atropelos e decisões unilaterais;

- Mostrar que a liderança é sobre servir o time, não mandar nele.

Fora essas atitudes, talvez a principal ideia seja aprender que ter um posto de liderança não significa falar mais, mas também garantir que todos entendam melhor e, acima de tudo, que você escute os membros do seu time.

Conclusão

Por fim, podemos ver que o MAP continua sendo uma base sólida, inclusive quando aplicado à comunicação humana e gestão de equipes. Ele é um modelo que traz consistência, robustez e direção para o trabalho, mas não é uma fórmula mágica que resolve todos os problemas do projeto. Ele é um guia, mas a execução depende de como as pessoas se comportam, se comunicam e se relacionam dentro do time.

Na prática, tudo depende das pessoas. O método é importante, mas é apenas uma parte do que faz um projeto funcionar. Comportamento, comunicação e liderança são fatores decisivos para o sucesso ou fracasso. Não esqueça: a maior falha está em não ouvir, não em não falar. E isso pode ser praticado e melhorado por todos, sejam líderes ou membros da equipe, para criar um ambiente mais saudável, produtivo e alinhado.

Para saber mais

Depois de escrever esse artigo com as minhas impressões pessoais, achei interessante incluir algumas fontes para sua leitura futura, caso queira se aprofundar nos temas de comunicação, liderança, metodologias e equipes.

Vale a leitura!

- Digital Communication Challenges in agile teams: a proposed Framework
https://periodicos.uninove.br/gep/article/view/28572

- Comunicação e coordenação em equipes virtuais de desenvolvimento distribuído de software
https://unichristus.emnuvens.com.br/gestao/article/view/4998

- Os desafios da gestão de equipes remotas com metodologias ágeis: uma revisão sistemática da literatura sobre aspectos humanos e técnicos
https://journal.scientificsociety.net/index.php/sobre/article/view/1171

- A comunicação em projetos de TI: uma análise comparativa das equipes de sistemas e de negócios
https://repositorio.usp.br/item/001626578

- E-Liderança no Setor Público Brasileiro: A Influência da Qualidade da Comunicação no Comprometimento e Desempenho das Equipes
https://periodicos.ufv.br/apgs/article/view/14827

No ecossistema acadêmico brasileiro, o Qualis CAPES é o principal sistema de classificação de periódicos para a avaliação da produção científica. No entanto, consultar essas classificações manualmente durante a navegação em plataformas como Google Acadêmico ou portais de revistas pode ser um processo moroso e repetitivo.

O REx (Researcher Explorer) nasce para resolver esse problema, integrando os indicadores Qualis diretamente na experiência de navegação do pesquisador. Esta extensão automatiza a identificação de ISSNs e fornece uma comparação visual instantânea entre os períodos 2017–2020 e 2021–2024.

Funcionalidades Chave

A seguir estão detalhadas as funcionalidades chave do REx, com foco principal na detecção de informações e experiência do usuário:

1. Detecção Inteligente e Validação

A extensão não apenas busca por padrões de texto; ela utiliza expressões regulares (Regex) para identificar potenciais ISSNs e aplica o algoritmo de dígito verificador para garantir que apenas códigos válidos sejam destacados. Isso evita falsos positivos em números aleatórios que seguem o formato XXXX-XXXX.

O REx marca os ISSNs com um ícone que exibe as informações da publicação quando o mouse fica pausado sobre ele em uma caixa de diálogo popover, que conta comm um botão de cópia rápida para copiar as informações da publicação e os índices Qualis.

2. Acessibilidade e Inclusão

O REx foi projetado para ser acessível a todos os usuários. A interface agora conta com:

• Navegação por Teclado: Todos os marcadores e botões são acessíveis via Tab.
• Suporte a Leitores de Tela: Implementação completa de Roles ARIA e etiquetas descritivas para garantir que usuários com deficiência visual possam consumir as informações do Qualis.
• Contraste Aprimorado: Cores e tipografia ajustadas para conformidade com padrões WCAG, garantindo legibilidade em diferentes condições.

3. Comparação Histórica

Um dos grandes diferenciais do REx é a exibição simultânea das classificações de dois períodos distintos, permitindo que o pesquisador visualize a evolução ou mudanças nos critérios de avaliação do periódico ao longo do tempo, especialmente em período de transição de classificações.

Arquitetura Técnica

Para garantir performance e uma experiência fluida, a extensão foi desenvolvida utilizando tecnologias modernas de Web Extensions:

Manifest V3 e Service Workers

Seguindo os padrões mais recentes do Google Chrome, a extensão utiliza o Manifest V3. O processamento pesado, como a consulta ao banco de dados, é delegado a um Background Service Worker, mantendo a interface do usuário rápida e responsiva.

Sincronização de Dados Remotos

A base de dados do Qualis contém milhares de registros. Para garantir que o pesquisador tenha sempre acesso às classificações mais recentes sem sobrecarregar o pacote da extensão, o REx utiliza um sistema de carregamento remoto. No primeiro uso e em atualizações, os dados JSON são buscados em um servidor seguro e persistidos no IndexedDB local. Isso mantém a extensão extremamente leve e permite buscas instantâneas totalmente offline após a sincronização inicial.

MutationObserver: Suporte a Páginas Dinâmicas

Sites modernos carregam conteúdo de forma assíncrona (infinite scroll). O REx utiliza a API MutationObserver para monitorar mudanças no DOM e processar novos ISSNs assim que eles aparecem na tela, sem a necessidade de recarregar a página.

O REx em ação

Veja a extensão em funcionamento durante uma simples busca no Google:

Baixe e Instale a Extensão

Para baixar e instalar a extensão, utilize o link abaixo. Por enquanto a extensão está disponível apenas para o Microsoft Edge, mas aguardando publicação para o Mozilla Firefox e o Google Chrome.

• Edge: REx: Research Explorer — Disponível no link: https://microsoftedge.microsoft.com/addons/detail/rex-research-explorer/kbndipndbinamljgflgkcakeaknplbfb
• Mozilla Firefox: REx: Research Explorer — Disponível em: https://addons.mozilla.org/pt-BR/firefox/addon/rex-researcher-explorer/
• Google Chrome — Disponível em: https://chromewebstore.google.com/detail/rex-research-explorer/ijacjhjbdoilgolpkaplhmmhnnkchoch

Conclusão

A extensão REx: Researcher Explorer transforma a maneira como pesquisadores interagem com indicadores de qualidade científica. Ao unir automação, performance local e um design focado na experiência do usuário, a ferramenta reduz a fricção na avaliação de veículos de publicação e artigos publicados, permitindo que o foco permaneça no que realmente importa: a pesquisa científica.

Originally published at https://www.linkedin.com.

Depois de muitos anos desenvolvendo sistemas, ensinando e acompanhando projetos de perto, eu cheguei a uma constatação: a maioria dos problemas chave em software não é técnica. Não é falta de framework, nem linguagem errada, e também não é “tecnologia defasada”.

Geralmente o que falta é algo como uma direção clara, um mapa para ser seguido. Pensando nisso, criei uma organização mental para projetos que eu chamo de MAP — Método, Antecipação e Planejamento.

Desde então, tento aplicar esse modelo mental nos projetos em que me envolvo, desde o planejamento e também na minha rotina diária.

Neste artigo, vou falar especificamente sobre software, mas pode servir para construir outras coisas também. Ficou curioso? Eu explico melhor cada uma das “letras” a seguir:

M — Método: como construir

Método não é burocracia. É ter um jeito padrão de trabalhar, para facilitar as atividades, sejam elas diárias ou no curso de um projeto inteiro.

Quando não existe método:

• cada feature vira um experimento;
• cada bug vira uma surpresa;
• cada vez que entra um novo desenvolvedor na equipe, ele sofre para entender o sistema.

Quando existe método:

• decisões se repetem menos;
• o código fica mais previsível;
• o time ganha ritmo.

Dessa forma, temos código enxuto, padronizado e mais fácil de manter.

Sendo assim, o método responde a uma pergunta simples, mas poderosa: “Qual é a nossa forma padrão de desenvolver software?”

A — Antecipação: pensar antes do problema virar uma bagunça em produção

Podemos dizer que antecipação é experiência aplicada com calma. Digamos que é mais importante procurar antecipar algumas questões do que esperar que elas apareçam. Ao fazer isso diariamente, é possível encontrar bugs só dando uma passada de olhos no código, enquanto se antecipa as próximas etapas.

Também se resume a olhar um requisito obtido e pensar:

• isso vai crescer?
• isso vai mudar?
• quem vai manter isso daqui a um ano?
• o que acontece quando o volume de dados dobra?

Antecipar não é tentar prever o futuro. É aceitar que o software com certeza vai mudar e se preparar para isso. Afinal de contas, outra coisa que costumo dizer é que um software é praticamente um “organismo vivo”, porque muda de acordo com as necessidades do ambiente e do usuário e se adapta.

Então, podemos dizer que antecipação reduz surpresa. E surpresa, em se tratando de software, quase sempre custa caro.

P — Planejamento: decidir antes de virar urgência

Vamos para a última etapa, mas não menos importante: Planejar é tomar decisões cedo, quando elas ainda são baratas.

Planejamento, na essência, se resume a definir:

• o que entra agora
• o que fica para depois
• o que conscientemente não será feito

Planejamento evita aquele clássico:

“Depois a gente refatora” “Depois a gente pensa nisso”

Spoiler: esse “depois” quase nunca chega, e quando há urgência de execução, algumas coisas deixadas para “depois”, cobram seu preço.

Por que o MAP funciona tão bem em software

Projetos problemáticos costumam ter o mesmo padrão:

• código sem método ou desorganizado (se está funcionando, está “certo”);
• decisões tomadas em cima da hora (para apagar “incêndios”);
• planejamento reativo.

O MAP cria equilíbrio:

• Método traz consistência
• Antecipação traz robustez
• Planejamento traz direção

Essa forma de pensar, é claro, não elimina os problemas de projeto, mas transforma o caos em decisões conscientes.

Conclusão

O MAP não é sobre escrever mais documentação ou seguir mais processos. É sobre trabalhar com intenção. É sobre menos heroísmo. menos esforço em apagar incêndios, e software que envelhece bem e evolui da forma como deveria ser, se adaptando às necessidades do usuário e mudanças no ambiente, quando acontecem.

Por fim, se você trabalha com desenvolvimento de software, talvez o maior ganho não esteja na próxima tecnologia — mas na forma como a gente pensa antes de começar a escrever código. Por mais demorada que a fase de planejamento seja, ela é crucial para a evolução dos seus projetos.

Originally published at https://www.linkedin.com.

Vamos começar com uma verdade meio desconfortável: listar várias tecnologias no portfólio não faz ninguém entender o que você realmente faz ou conhece, afinal de contas os frameworks e tecnologias vêm e vão, mas os problemas reais continuam aparecendo.

Depois de vários anos trabalhando com ensino na área de computação e ajudando a desenvolver sistemas institucionais, apps mobile e projetos de vários tamanhos e de relevância para a resolução de diversas situações, aprendi uma coisa:

Portfólio bom conta história técnica.

Dito isso, vamos entender o que é preciso para estruturar um bom portfólio profissional.

Currículo conta onde você trabalhou. Portfólio mostra como você pensa.

O currículo normalmente responde:

• Onde você trabalhou?
• Qual era seu cargo?
• Por quanto tempo você ficou em cada empresa?
• Quais tecnologias você utilizou em cada uma?
• Qual a sua formação?

O portfólio, por sua vez, deveria responder:

• Que problemas apareceram?
• O que você fez quando deu errado?
• Por que escolheu essa solução e não outra?
• Qual o impacto da sua solução?

Então, vejamos: se quem está lendo precisa “imaginar” o que você faz, pode ser que tenha algo faltando.

A primeira tela decide tudo (em uns 10 segundos)

Quem abre seu portfólio deve estar se perguntando:

Esse dev resolve que tipo de problema?

Se essa resposta não aparece rápido, a aba fecha.

Vamos pegar o meu portfolio como exemplo, onde deixo claro logo de início:

• Com que tipo de tecnologias eu trabalho? Full Stack & Mobile
• Quais tipos de sistema são minha especialidade? Sistemas institucionais e corporativos
• O que mais posso entregar? Apps Flutter integrados com APIs reais

Até aqui, nada de outro mundo: Quem é do público certo continua lendo. Quem não é, segue adiante.

Projetos: Prefira o contexto à quantidade

Você não precisa mostrar tudo que já fez desde o começo da idade da pedra. Você pode escolher três a seis projetos bem explicados , que ganham fácil de uma lista infinita sem contexto.

Pense como se estivesse explicando pra outro dev durante aquela pausa pro café:

• Qual era o problema?
• Quem usava isso?
• O que caiu no seu colo resolver?
• Que decisões técnicas você tomou?
• Funcionou? Por quê?

Exemplos reais

Separe um exemplo para cada uma das categorias com as quais se identifica mais ou deseja atuar. Procure falar de cada uma delas de forma detalhada, mas sem dar muitos spoilers, digamos assim. Veja os exemplos:

1. Sistema Institucional: ERP institucional que evoluiu por mais de 10 anos. Veja bem, não é sobre “fiz um sistema”, é sobre manter algo vivo, usável e sustentável por uma década.
2. Migração e melhoria contínua: Fale sobre o projeto e ressalte sobre sua atuação nele. Trocando em miúdos, o trabalho de migração geralmente significa modificar e não quebrar nada, melhorar o que era possível e deixar tudo organizado para facilitar para o restante da equipe.
3. Apps Flutter (Android e iOS): Deixe claras as funcionalidades com as quais trabalhou e técnicas utilizadas. Veja o exemplo: Trabalhei com integração com APIs, arquitetura organizada e decisões pensadas para crescer.

Em resumo, uma boa descrição das suas decisões técnicas diz muito mais do que uma simples lista de tecnologias separadas por vírgula no topo do seu site ou perfil profissional.

Prints são legais, mas decisões técnicas são melhores

Veja bem, tela bonita chama atenção, mas uma decisão técnica bem explicada gera confiança.

Sempre que der, explique:

• Por que usou a tecnologia A e não a tecnologia B
• Por que motivo usou determinada arquitetura
• Como organizou camadas, serviços e integrações
• Como pensou em manutenção futura (sim, ela sempre chega)

Quem contrata precisa saber que você resolve problemas, não se você só replica layout ou algo que já está lá.

Organize tecnologias como gente grande

Em vez de uma lista infinita de palavras que só geram ruído, agrupe por domínio, como no exemplo:

• Mobile: Flutter (Android & iOS)
• Backend: PHP (CodeIgniter, Laravel), APIs REST
• Arquitetura: Clean Architecture, MVC
• Integrações: autenticação, JWT, serviços externos
• Manutenção: refatoração, migração, melhoria contínua e correções

Isso mostra um certo grau de maturidade profissional. E ninguém precisa adivinhar nada.

Artigos Técnicos: O pulo do gato

Um bom artigo técnico mostra três coisas:

1. o que você realmente sabe
2. o que você pensa, e como pensa
3. que você sabe explicar

Não precisa ser tratado acadêmico, apenas contar o que deu certo, o que não deu e o que você aprendeu no processo.

Spoiler: isso diferencia muito para quem se interessa em contratar você para um trabalho, seja como CLT, PJ ou freelancer.

Portfolio não acaba: Evolui

Um portfolio deve ser tratado como um produto, ou seja, ele deve evoluir com o tempo. Assim como qualquer sistema real:

• o portfólio muda
• melhora
• acumula história

Cada projeto pode se transformar em:

• Estudo de caso
• Artigo
• algo maior

Trate seu portfólio e cada item dele como produto em evolução, não como tarefa concluída.

Portfólio bom não tenta impressionar com volume. É claro e objetivo, e procura transmitir a ideia:

“Esse profissional tem capacidade para resolver esse tipo de problema”.

Se você conseguir organizar seu portfolio de modo a transmitir esse tipo de mensagem, o resto flui. Tem dúvidas de como organizar seu portfolio? Procure conversar com outros profissionais, peça dicas e sugestões, mas lembre-se sempre que o portfolio deve refletir quem você é e o tipo de trabalho que você deseja realizar.

Originally published at https://www.linkedin.com.