Come dimostrare una competenza? Modello a 6 livelli di evidenza

L’approccio Skills First sposta l’attenzione dalle etichette formali alle competenze che una persona può realmente dimostrare. Questo però non risolve automaticamente il problema di come valutarle.

L’OCSE descrive skills-first come un approccio in cui pratiche di assunzione e talent management vengono adattate per valutare le persone sulla base di competenze dimostrate. Il rapporto sottolinea anche la necessità di strumenti di valutazione e framework di competenze adeguati. [1]

Sostituire una sezione "Education" con una sezione "Skills" più lunga non basta. Serve anche un modo migliore per spiegare perché una competenza dovrebbe essere considerata credibile.

Due persone possono indicare esattamente la stessa competenza pur avendo esperienze pratiche completamente diverse.

Immaginiamo due specialisti che dichiarano:

Angular - avanzato

La prima persona ha completato un corso, creato alcuni progetti personali e conosce i meccanismi di base del framework.

La seconda sviluppa da tre anni un’applicazione in produzione, è responsabile dell’architettura di una parte del sistema, ha gestito migrazioni tra versioni di Angular e può indicare risultati concreti del proprio lavoro.

In una classica lista di skill possono sembrare molto simili.

Solo evidenze inserite nel giusto contesto iniziano a mostrare la vera differenza.

Il modello non serve ad assegnare alle persone un unico punteggio universale. Professioni diverse producono tipi diversi di evidenza e non tutti i progetti possono essere mostrati pubblicamente.

L’obiettivo è rispondere a una domanda più semplice:

quanto sono solide le informazioni che permettono di considerare una competenza presentata in modo credibile?

Il livello più semplice è la dichiarazione dell’utente.

Esempi:

• Angular
• Figma
• SEO
• leadership di team
• negoziazione B2B

Questa informazione è utile per ricerca e discovery, ma il suo valore probatorio è limitato.

Non sappiamo ancora:

• dove è stata usata la competenza,
• per quanto tempo,
• su quale scala,
• con quale responsabilità,
• con quale risultato.

La dichiarazione è il punto di partenza, non la conclusione della valutazione.

L’evidenza diventa più forte quando sappiamo dove e in quale contesto è stata utilizzata la competenza.

Invece di:

Angular

possiamo leggere:

Angular utilizzato per 2 anni nello sviluppo di un’applicazione SaaS per il settore logistico.

Questo non dimostra ancora la qualità del lavoro, ma aggiunge un contesto importante:

• un progetto reale,
• durata di utilizzo della competenza,
• area di applicazione,
• natura dell’ambiente.

A questo livello, la skill smette di essere solo un’etichetta.

Il livello successivo compare quando dichiarazione ed esperienza possono essere collegate a un artefatto reale di lavoro.

A seconda della professione può essere:

• un’applicazione funzionante,
• un esempio di codice,
• un repository,
• un design di interfaccia,
• un prototipo,
• un report,
• un’analisi,
• una campagna,
• un articolo,
• documentazione,
• un modello finanziario,
• una fotografia,
• un progetto tecnico,
• una registrazione del lavoro svolto.

L’artefatto risponde a una domanda importante:

possiamo vedere qualcosa che è stato realmente creato usando questa competenza?

Questo non significa che un portfolio sia un test formale di competenze. La ricerca sulla selezione del personale indica però che metodi strettamente legati al lavoro reale, come work sample e test di conoscenza professionale, possono essere utili predittori della performance. Gli autori sottolineano anche che i risultati vanno interpretati considerando contesto, costo e limiti del metodo. [2]

Anche un artefatto può lasciare senza risposta una delle domande più importanti:

che cosa ha fatto esattamente questa persona?

È particolarmente importante nei progetti di team.

Un’applicazione può essere stata costruita da 20 persone. Una campagna può aver coinvolto 8 persone. Un rebranding può aver incluso un’agenzia, il reparto marketing interno e consulenti esterni.

Per questo una forma di evidenza più forte è un case study che identifica il contributo individuale.

Un buon case study dovrebbe distinguere almeno:

• problema o obiettivo,
• ambito complessivo del progetto,
• responsabilità personale dello specialista,
• attività realmente svolte,
• competenze utilizzate,
• collaborazione con altre persone,
• risultato.

Invece di:

Ho creato una piattaforma e-commerce.

è meglio:

Ero responsabile dell’architettura frontend, dell’implementazione del checkout e dell’integrazione del flusso di pagamento. Il progetto è stato realizzato da un team di cinque persone.

La seconda descrizione è più utile perché non attribuisce a una sola persona il lavoro dell’intero team.

L’evidenza diventa ancora più forte quando il lavoro porta a un risultato concreto che può essere descritto senza generalizzazioni.

Esempi:

Frontend
Riduzione del tempo di caricamento della vista principale da 4,2 s a 1,8 s.

UX
Riduzione dell’abbandono del form di registrazione dopo la riprogettazione del flusso.

Marketing
Riduzione del costo per lead mantenendo una qualità del traffico comparabile.

Vendite
Apertura di un nuovo segmento clienti e chiusura di un numero definito di contratti.

Operations
Riduzione di un processo da diversi giorni a poche ore.

Non tutte le professioni possono o dovrebbero esprimere un risultato in percentuale o valore economico. Non bisogna inventare metriche solo per rendere il profilo più impressionante.

La domanda utile è:

che cosa è cambiato grazie a questo lavoro?

Il livello più forte del modello si raggiunge quando almeno una parte delle informazioni può essere verificata indipendentemente dalla dichiarazione del proprietario del profilo.

Può includere:

• un progetto disponibile pubblicamente,
• un repository con storico dei contributi,
• una pubblicazione pubblica,
• partecipazione confermata a un progetto,
• una referenza di cliente o collega pubblicabile legalmente,
• un risultato verificabile in modo indipendente,
• una credenziale ufficiale quando realmente rilevante,
• un’altra fonte che confermi un lavoro specifico.

Questo non significa che ogni progetto debba essere pubblico.

Molti progetti di valore sono coperti da NDA, segreto commerciale o altri obblighi di riservatezza.

L’assenza di evidenza pubblica non significa assenza di competenza.

Significa soltanto un livello inferiore di verificabilità indipendente.

Livello 1 - dichiarazione
Angular.

Livello 2 - contesto
Angular utilizzato per 3 anni in applicazioni SaaS.

Livello 3 - artefatto
Un’applicazione pubblica, un repository o un altro esempio di lavoro che può essere mostrato.

Livello 4 - contributo individuale
Responsabilità per l’architettura di alcuni moduli, componenti condivisi e migrazione dell’applicazione.

Livello 5 - risultato
Un’ottimizzazione ha ridotto il tempo di avvio del modulo principale da 4,2 s a 1,8 s. I valori sono illustrativi.

Livello 6 - verifica
Risultato e contributo possono essere ulteriormente confermati da un progetto pubblico, storico delle modifiche, referenza o altra fonte indipendente.

Due evidenze allo stesso livello possono avere un valore molto diverso. Cinque dimensioni aggiuntive aiutano a interpretarle.

1. Rilevanza - l’evidenza riguarda davvero la competenza che si vuole valutare?

2. Recenza - quando è stata utilizzata la competenza e quanto conta l’attualità in quel settore?

3. Autorialità e responsabilità - sappiamo che cosa ha fatto realmente la persona?

4. Contesto - quali erano scala, complessità, responsabilità, risorse e condizioni di lavoro?

5. Verificabilità - esiste un modo indipendente per confermare almeno parte delle informazioni?

Rilevanza

Un progetto in cui una tecnologia è stata usata solo marginalmente è una prova più debole rispetto a uno in cui quella competenza era centrale.

Recenza

L’importanza dell’attualità dipende dal settore. In alcuni ambiti, esperienza di dieci anni fa può essere ancora molto preziosa. In altri, strumenti e pratiche cambiano così rapidamente che l’uso recente conta molto.

Autorialità e responsabilità

Più grandi sono progetto e team, più è importante separare il risultato complessivo dal contributo individuale dello specialista.

Contesto

Lo stesso risultato può avere peso diverso in base a scala del progetto, vincoli di tempo, risorse, responsabilità e complessità del problema.

Verificabilità

La verifica indipendente non è sempre possibile e non dovrebbe essere sempre obbligatoria. Quando esiste una fonte indipendente che conferma risultato o contributo, rafforza la credibilità dell’evidenza.

Una persona può svolgere molto bene la propria parte in un progetto che alla fine fallisce dal punto di vista commerciale.

Può anche partecipare a un progetto di grande successo avendo avuto solo un’influenza limitata sul risultato finale.

È quindi utile separare tre elementi:

1. Competenza
La persona sa svolgere un determinato tipo di lavoro?

2. Contributo
Di quale parte era realmente responsabile?

3. Risultato
Che cosa è cambiato grazie a quel lavoro?

Solo la combinazione di questi elementi offre un quadro più completo.

Un certificato o un’altra credenziale formale può essere una prova utile, ma il suo valore dipende da che cosa conferma realmente e da come è stata ottenuta.

Può confermare, per esempio:

• completamento di una formazione,
• raggiungimento di risultati di apprendimento definiti,
• superamento di una specifica valutazione,
• conoscenza di uno standard,
• rispetto di requisiti formali.

La Commissione europea descrive le micro-credenziali come attestazioni di risultati di apprendimento acquisiti attraverso una breve esperienza formativa. L’approccio europeo sottolinea, tra gli altri aspetti, trasparenza e qualità. [3]

Un certificato non dovrebbe essere automaticamente equiparato alla prova che una persona sappia svolgere autonomamente un lavoro complesso in un contesto professionale reale.

Una credenziale è quindi uno dei possibili elementi di evidenza, il cui significato dipende dal contesto.

Non poter mostrare pubblicamente un progetto non dovrebbe cancellare un’esperienza di valore.

Allo stesso tempo, NDA, obblighi di riservatezza, segreti commerciali, diritto d’autore e protezione dei dati hanno priorità rispetto al desiderio di mostrare il portfolio.

Lo specialista dovrebbe descrivere un progetto solo nei limiti consentiti dai contratti, dalla legge applicabile e dai diritti di altre persone e organizzazioni. Eliminare il nome del cliente non è sempre sufficiente se le informazioni rimanenti permettono comunque di identificare progetto, cliente, tecnologia, risultati o metodi riservati.

Quando la divulgazione è consentita, può essere possibile descrivere:

• il settore in forma sufficientemente generale,
• la natura del problema senza divulgare informazioni riservate,
• ruolo e responsabilità personali,
• competenze utilizzate,
• scala del lavoro solo nella misura consentita,
• tipo di risultato senza pubblicare dati protetti,
• approccio in forma sufficientemente generale.

In caso di dubbio sulla possibilità di pubblicare una determinata informazione, la scelta più sicura è non divulgarla finché non è stato verificato il contratto o ottenuto il consenso del titolare dei diritti.

Un sistema di evidenza delle competenze non dovrebbe essere progettato come se ogni professione fosse sviluppo software.

Un designer può mostrare processo, decisioni di design, prototipo e risultato.

Uno sviluppatore può mostrare prodotto, codice, architettura o ambito tecnico di responsabilità.

Un marketer può presentare campagna, approccio, responsabilità e cambiamenti nei risultati.

Un professionista delle vendite può descrivere segmento, processo commerciale, ruolo e risultato senza divulgare dati riservati dei clienti.

Un Project Manager può mostrare ambito del progetto, organizzazione del lavoro, vincoli e influenza sulla delivery.

Un fotografo può presentare lavori completati senza inventare KPI artificiali.

Il modello può essere comune nei principi e flessibile nel tipo di evidenza.

1. Verifica dove la competenza è stata realmente utilizzata.

2. Cerca un artefatto di lavoro o un esempio concreto di realizzazione.

3. Separa il contributo dello specialista dal lavoro dell’intero team.

4. Valuta il risultato quando può essere descritto in modo significativo.

5. Considera recenza e somiglianza dell’esperienza precedente con il problema da risolvere.

6. Cerca conferme indipendenti quando sono possibili e appropriate.

In questo modo la valutazione si sposta dalle parole chiave del profilo verso la reale corrispondenza tra competenze dimostrate e una necessità concreta.

Il modello serve a organizzare le informazioni e supportare il giudizio umano. Non dovrebbe essere trattato come un verdetto automatico su assunzione, rifiuto di un candidato o avvio di una collaborazione professionale.

Non serve avere un’evidenza di livello 6 per ogni competenza.

È più utile rivedere le skill principali e chiedersi:

• dove l’ho usata?
• quale problema stavo risolvendo?
• che cosa ho fatto esattamente?
• ho un artefatto di quel lavoro?
• qual è stato il risultato?
• posso descriverlo senza violare la riservatezza?
• una persona o una fonte può confermare il mio contributo?

Anche solo passare da:

Figma - avanzato

a:

Ho progettato il processo di onboarding di un’applicazione B2B ed ero responsabile di research, prototipazione, usability test e design system finale

migliora chiaramente la qualità delle informazioni disponibili a chi visita il profilo.

Un approccio Skills First ha senso solo se la parola "skill" rappresenta più di un semplice tag.

Se le competenze devono essere uno dei principali modi per trovare e confrontare specialisti, dovrebbero essere collegate al miglior contesto disponibile:

esperienza -> portfolio -> contributo individuale -> risultato -> verificabilità.

Non tutte le competenze raggiungeranno il livello più alto e non dovrebbero essere obbligate a farlo.

L’obiettivo non è creare burocrazia obbligatoria attorno a ogni voce del profilo.

L’obiettivo è permettere agli specialisti di spiegare perché una competenza dovrebbe essere credibile e aiutare chi cerca expertise a prendere decisioni meglio informate.

1. Concretezza invece di dichiarazione - mostra dove e come la competenza è stata usata.

2. Contributo individuale invece del successo dell’intero team - separa il tuo lavoro dal risultato di tutta l’organizzazione.

3. Risultato invece della lista di attività - quando possibile, mostra che cosa è cambiato grazie al lavoro.

4. Contesto invece del numero isolato - una metrica senza condizioni può portare a conclusioni errate.

5. Verifica quando possibile - una conferma indipendente rafforza la credibilità, ma la sua assenza non invalida la competenza.

Un profilo professionale non dovrebbe costringere chi legge a indovinare che cosa c’è davvero dietro una lista di competenze.

La dichiarazione aiuta a scoprire una competenza. L’evidenza aiuta a comprenderla.

I sei livelli possono essere riassunti in un percorso semplice:

1. Dico che so farlo.
2. Mostro dove l’ho usato.
3. Mostro che cosa ho creato.
4. Spiego che cosa ho fatto esattamente.
5. Mostro il risultato.
6. Rendo possibile una conferma indipendente quando è possibile.

Più risposte possiamo fornire, meno dobbiamo affidarci alla sola dichiarazione.

È allora che Skills First diventa qualcosa di più di un semplice cambio nell’ordine delle informazioni del profilo.

[1] OECD - A Skills-First Labour Market: Promoting skills-first hiring and talent management, 2026
Apri la 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
Apri la fonte

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

Nota metodologica: le fonti [1]-[3] forniscono un contesto più ampio su Skills First, valutazione delle competenze e credenziali. Il Modello a 6 livelli di evidenza delle competenze è un modello concettuale originale descritto in questo materiale e non viene presentato come risultato di tali pubblicazioni.