Como provar uma competência? Modelo de 6 níveis de evidência

A abordagem Skills First desloca a atenção dos rótulos formais para competências que uma pessoa consegue realmente demonstrar. Isso, porém, não resolve automaticamente a forma de as avaliar.

A OCDE descreve skills-first como uma abordagem em que as práticas de contratação e gestão de talento são adaptadas para avaliar pessoas com base em competências demonstradas. O relatório também aponta para a necessidade de ferramentas de avaliação e referenciais de competências adequados. [1]

Substituir uma secção "Education" por uma lista maior de "Skills" não é suficiente. Também precisamos de explicar melhor porque é que uma competência deve ser considerada credível.

Duas pessoas podem indicar exatamente a mesma competência e ter experiências práticas completamente diferentes.

Imaginemos dois especialistas que declaram:

Angular - avançado

A primeira pessoa concluiu um curso, criou alguns projetos próprios e conhece os mecanismos básicos do framework.

A segunda trabalhou durante três anos numa aplicação em produção, foi responsável pela arquitetura de parte do sistema, realizou migrações entre versões do Angular e consegue apontar resultados concretos desse trabalho.

Numa lista tradicional de competências, podem parecer muito semelhantes.

Só evidência colocada em contexto começa a mostrar a diferença real.

O modelo não foi criado para atribuir uma pontuação universal às pessoas. Diferentes profissões produzem diferentes tipos de evidência e nem todos os projetos podem ser mostrados publicamente.

O objetivo é responder a uma pergunta mais simples:

quão forte é o material que sustenta a apresentação credível de uma determinada competência?

O nível mais simples é a declaração do próprio utilizador.

Exemplos:

• Angular
• Figma
• SEO
• liderança de equipas
• negociação B2B

Esta informação é útil para pesquisa e descoberta, mas o seu valor como prova é limitado.

Ainda não sabemos:

• onde a competência foi utilizada,
• durante quanto tempo,
• em que escala,
• com que responsabilidade,
• com que resultado.

A declaração é o ponto de partida, não o fim da avaliação.

A evidência torna-se mais forte quando sabemos onde e em que contexto a competência foi utilizada.

Em vez de:

Angular

temos:

Angular utilizado durante 2 anos no desenvolvimento de uma aplicação SaaS para o setor da logística.

Isto ainda não demonstra a qualidade do trabalho, mas acrescenta contexto importante:

• um projeto real,
• período de utilização da competência,
• área de aplicação,
• natureza do ambiente.

Neste nível, a competência deixa de ser apenas uma etiqueta.

O nível seguinte surge quando a declaração e a experiência podem ser associadas a um artefacto real de trabalho.

Dependendo da profissão, pode ser:

• uma aplicação funcional,
• um excerto de código,
• um repositório,
• um design de interface,
• um protótipo,
• um relatório,
• uma análise,
• uma campanha,
• um artigo,
• documentação,
• um modelo financeiro,
• uma fotografia,
• um projeto técnico,
• uma gravação do trabalho realizado.

O artefacto responde a uma pergunta importante:

conseguimos ver algo que foi realmente criado com esta competência?

Isto não significa que um portfolio seja um teste formal de competências. Ainda assim, estudos sobre seleção de pessoal indicam que métodos diretamente ligados ao trabalho, como work samples e testes de conhecimento profissional, podem ser preditores úteis do desempenho. Os autores sublinham também que os resultados devem ser interpretados tendo em conta o contexto, o custo e as limitações de cada método. [2]

Mesmo um artefacto pode deixar sem resposta uma das perguntas mais difíceis:

o que fez exatamente esta pessoa?

Isto é particularmente importante em projetos de equipa.

Uma aplicação pode ter sido criada por 20 pessoas. Uma campanha pode ter envolvido uma equipa de 8. Um rebranding pode ter incluído uma agência, uma equipa interna de marketing e consultores externos.

Por isso, uma evidência mais forte é um estudo de caso que identifique a contribuição individual.

Um bom estudo de caso deve separar pelo menos:

• o problema ou objetivo,
• o âmbito global do projeto,
• a responsabilidade pessoal do especialista,
• as ações realmente executadas,
• as competências utilizadas,
• a colaboração com outras pessoas,
• o resultado.

Em vez de:

Criei uma plataforma de e-commerce.

é melhor:

Fui responsável pela arquitetura frontend, implementação do checkout e integração do fluxo de pagamento. O projeto foi realizado por uma equipa de cinco pessoas.

A segunda descrição é mais útil porque não atribui a uma pessoa o trabalho de toda a equipa.

A evidência torna-se ainda mais forte quando o trabalho conduz a um resultado concreto que pode ser descrito sem generalidades.

Exemplos:

Frontend
Redução do tempo de carregamento da vista principal de 4,2 s para 1,8 s.

UX
Redução do abandono do formulário de registo após a reformulação do fluxo.

Marketing
Redução do custo por lead mantendo uma qualidade de tráfego comparável.

Vendas
Abertura de um novo segmento de clientes e fecho de um número definido de contratos.

Operations
Redução de um processo de vários dias para algumas horas.

Nem todas as profissões podem ou devem apresentar resultados em percentagens ou valores monetários. Não se devem inventar métricas apenas para tornar um perfil mais impressionante.

A pergunta útil é:

o que mudou graças a este trabalho?

O nível mais forte do modelo aparece quando pelo menos parte da informação pode ser verificada independentemente da declaração do autor do perfil.

Pode incluir:

• um projeto público,
• um repositório com histórico de contribuições,
• uma publicação pública,
• participação confirmada num projeto,
• uma referência de cliente ou colega que possa ser publicada legalmente,
• um resultado que possa ser confirmado de forma independente,
• uma credencial oficial quando seja realmente relevante,
• outra fonte que confirme trabalho concreto.

Isto não significa que todos os projetos tenham de ser públicos.

Muitos projetos valiosos estão sujeitos a NDA, segredo comercial ou outras obrigações de confidencialidade.

Por isso, a falta de evidência pública não significa falta de competência.

Significa apenas um grau menor de verificabilidade independente.

Nível 1 - declaração
Angular.

Nível 2 - contexto
Angular utilizado durante 3 anos em aplicações SaaS.

Nível 3 - artefacto
Uma aplicação pública, repositório ou outra amostra de trabalho que possa ser mostrada.

Nível 4 - contribuição individual
Responsabilidade pela arquitetura de determinados módulos, componentes partilhados e migração da aplicação.

Nível 5 - resultado
Uma otimização reduziu o tempo de arranque do módulo principal de 4,2 s para 1,8 s. Os valores são ilustrativos.

Nível 6 - verificação
O resultado e a contribuição podem ser confirmados adicionalmente através de um projeto público, histórico de alterações, referência ou outra fonte independente.

Duas evidências no mesmo nível podem ter valor muito diferente. Cinco dimensões adicionais ajudam a interpretá-las.

1. Relevância - a evidência está realmente relacionada com a competência avaliada?

2. Atualidade - quando foi utilizada e quanto importa a recência nesse domínio?

3. Autoria e responsabilidade - sabemos o que a pessoa fez realmente?

4. Contexto - qual era a escala, complexidade, responsabilidade, recursos e condições de trabalho?

5. Verificabilidade - existe uma forma independente de confirmar pelo menos parte da informação?

Relevância

Um projeto em que uma tecnologia foi usada apenas de forma marginal é uma evidência mais fraca do que um projeto em que essa competência foi central.

Atualidade

A importância da recência depende da área. Em alguns domínios, experiência de há dez anos pode continuar muito valiosa. Noutros, ferramentas e práticas mudam tão rapidamente que a utilização recente é especialmente importante.

Autoria e responsabilidade

Quanto maiores forem o projeto e a equipa, mais importante é separar o resultado global da contribuição individual do especialista.

Contexto

O mesmo resultado pode ter peso diferente consoante a escala, os prazos, os recursos, a responsabilidade e a complexidade do problema.

Verificabilidade

A verificação independente nem sempre é possível nem deve ser sempre obrigatória. Quando existe uma fonte independente que confirma o resultado ou a contribuição, aumenta a credibilidade da evidência.

Uma pessoa pode executar muito bem a sua parte num projeto que acaba por falhar comercialmente.

Também pode participar num projeto muito bem-sucedido tendo pouca influência no resultado final.

Por isso, é útil separar três elementos:

1. Competência
A pessoa consegue executar determinado tipo de trabalho?

2. Contribuição
Por que parte foi realmente responsável?

3. Resultado
O que mudou em consequência desse trabalho?

A combinação destes elementos oferece uma visão mais completa.

Um certificado ou outra credencial formal pode ser uma evidência útil, mas o seu valor depende de o que confirma realmente e de como foi obtido.

Pode confirmar, por exemplo:

• conclusão de formação,
• obtenção de resultados de aprendizagem definidos,
• aprovação numa avaliação específica,
• conhecimento de uma norma,
• cumprimento de requisitos formais.

A Comissão Europeia descreve as microcredenciais como registos de resultados de aprendizagem adquiridos através de uma experiência de aprendizagem curta. A abordagem europeia enfatiza, entre outros aspetos, a transparência e a qualidade. [3]

Um certificado não deve ser automaticamente equiparado à prova de que alguém consegue executar de forma autónoma trabalho complexo num ambiente profissional real.

Uma credencial é, portanto, um dos possíveis elementos de evidência, cujo significado depende do contexto.

Não poder mostrar publicamente um projeto não deve apagar experiência valiosa.

Ao mesmo tempo, NDA, deveres de confidencialidade, segredo comercial, direitos de autor e regras de proteção de dados têm prioridade sobre a vontade de mostrar trabalho no portfolio.

O especialista deve descrever um projeto apenas na medida permitida pelos contratos, pela legislação aplicável e pelos direitos de outras pessoas e organizações. Retirar apenas o nome do cliente nem sempre é suficiente se os restantes dados permitirem identificar o projeto, cliente, tecnologia, resultados ou métodos confidenciais.

Quando a divulgação é permitida, pode ser possível descrever:

• o setor de forma suficientemente geral,
• a natureza do problema sem revelar informação confidencial,
• o papel e as responsabilidades próprias,
• as competências utilizadas,
• a escala do trabalho apenas até ao nível permitido,
• o tipo de resultado sem publicar dados protegidos,
• a abordagem de forma suficientemente geral.

Se houver dúvida sobre a possibilidade de publicar determinada informação, a opção mais segura é não a divulgar até verificar o contrato ou obter autorização do titular dos direitos.

Um sistema de evidência de competências não deve ser desenhado como se todas as profissões fossem desenvolvimento de software.

Um designer pode mostrar processo, decisões de design, protótipo e resultado.

Um developer pode mostrar produto, código, arquitetura ou âmbito técnico de responsabilidade.

Um profissional de marketing pode apresentar campanha, abordagem, responsabilidade e evolução dos resultados.

Um profissional de vendas pode descrever segmento, processo comercial, papel próprio e resultado sem revelar dados confidenciais de clientes.

Um Project Manager pode mostrar âmbito do projeto, organização do trabalho, limitações e influência na entrega.

Um fotógrafo pode apresentar trabalhos concluídos sem inventar KPI artificiais.

O modelo deve ser comum ao nível dos princípios e flexível quanto ao tipo de evidência.

1. Verifique onde a competência foi realmente utilizada.

2. Procure um artefacto de trabalho ou um exemplo concreto de execução.

3. Separe a contribuição do especialista do trabalho de toda a equipa.

4. Analise o resultado quando puder ser descrito de forma relevante.

5. Avalie a atualidade e a semelhança da experiência anterior com o problema que precisa de resolver.

6. Procure confirmação independente quando for possível e adequado.

Isto desloca a avaliação das palavras-chave do perfil para a correspondência real entre competências demonstradas e uma necessidade concreta.

O modelo serve para organizar informação e apoiar o julgamento humano. Não deve ser tratado como um veredicto automático sobre contratar, rejeitar alguém ou iniciar uma colaboração profissional.

Não é necessário ter evidência de nível 6 para cada competência.

É mais útil rever as competências mais importantes e perguntar:

• onde utilizei esta competência?
• que problema estava a resolver?
• o que fiz exatamente?
• tenho um artefacto desse trabalho?
• qual foi o resultado?
• posso descrevê-lo sem violar confidencialidade?
• uma pessoa ou fonte consegue confirmar a minha contribuição?

Só passar de:

Figma - avançado

para:

Desenhei o processo de onboarding de uma aplicação B2B e fui responsável por research, prototipagem, testes de usabilidade e pelo design system final

já melhora claramente a qualidade da informação disponível para quem consulta o perfil.

A abordagem Skills First só faz sentido quando a palavra "skill" representa mais do que mais uma etiqueta.

Se as competências forem uma das principais formas de descobrir e comparar especialistas, devem estar ligadas ao melhor contexto disponível:

experiência -> portfolio -> contribuição individual -> resultado -> verificabilidade.

Nem todas as competências chegarão ao nível mais alto, nem deveriam ter de chegar.

O objetivo não é criar burocracia obrigatória em torno de cada item do perfil.

O objetivo é permitir que especialistas expliquem porque é que uma competência deve ser considerada credível e ajudar quem procura expertise a tomar uma decisão mais informada.

1. Concreto em vez de declaração - mostre onde e como a competência foi utilizada.

2. Contribuição individual em vez do sucesso de toda a equipa - separe o seu trabalho do resultado da organização.

3. Resultado em vez de lista de tarefas - quando possível, mostre o que mudou graças ao trabalho.

4. Contexto em vez de um número isolado - uma métrica sem condições pode levar a conclusões erradas.

5. Verificação quando possível - confirmação independente reforça credibilidade, mas a sua ausência não invalida a competência.

Um perfil profissional não deve obrigar quem o lê a adivinhar o que existe realmente por trás de uma lista de competências.

A declaração ajuda a descobrir a competência. A evidência ajuda a compreendê-la.

Os seis níveis podem ser resumidos num percurso simples:

1. Digo que sei fazer.
2. Mostro onde utilizei.
3. Mostro o que criei.
4. Explico exatamente o que fiz.
5. Mostro o resultado.
6. Permito confirmação independente quando é possível.

Quanto mais destas perguntas conseguirmos responder, menos dependemos apenas da declaração.

É aí que Skills First passa a significar mais do que simplesmente mudar a ordem da informação num perfil.

[1] OECD - A Skills-First Labour Market: Promoting skills-first hiring and talent management, 2026
Abrir fonte

[2] Sackett, Zhang, Berry, Lievens - Revisiting the design of selection systems in light of new findings regarding the validity of widely used predictors, Cambridge University Press, 2023
Abrir fonte

[3] European Commission - A European approach to micro-credentials
Abrir fonte

Nota metodológica: as fontes [1]-[3] fornecem contexto mais amplo sobre Skills First, avaliação de competências e credenciais. O Modelo de 6 níveis de evidência de competências é um modelo conceptual original descrito neste material e não é apresentado como resultado dessas publicações.