Hard skills e Soft skills. Come classificare le competenze?
Home > News > Hard skills e Soft skills. Come classificare le competenze?

Hard skills e Soft skills. Come classificare le competenze?

23 marzo 2018
La classificazione delle competenze è un’attività che può presentare parecchi rischi. Se fatta male può inficiare tutti gli sforzi di analisi e valutazione delle risorse umane all’interno dell’organizzazione. Allo stesso tempo una tassonomia è assolutamente necessaria per poter gestire dei cataloghi comuni all’interno di un’organizzazione e, magari, anche fra più organizzazioni. L’importante è distinguere le competenze operative da quelle abilitanti, che possono essere definite anche come trasversali. 
 
 
CLASSIFICARE HARD SKILLS E SOFT SKILLS 
 
 

In che modo classificare le Competenze?

È un’attività che mi è sempre stata richiesta dai clienti all’inizio di un nuovo progetto di mappatura. Un’attività assolutamente necessaria quando si ha a che fare con elenchi di centinaia, se non migliaia di referenze. Dopo tanti anni di esperienza, Exagogica ha sviluppato una tassonomia a tre livelli: Aree, Settori e Tipi. Mentre i primi due (aree e settori) esprimono le relazioni di vicinanza delle competenze in termini di contenuto (potremmo dire, con una forzatura, in base all’oggetto della competenza, ovvero il “cosa”), il terzo livello distingue le competenze in relazione al contesto entro cui assume valore quello stesso contenuto (anche qui, con un’altra forzatura, potremmo dire in base al modo, ovvero il “come”).
 

Un Esempio pratico

Facciamo un esempio pratico, prendendolo proprio dal mondo che mi è più familiare, quello dello sviluppo software. La competenza “Scrittura di stored procedure”, che si potrebbe anche descrivere più chiaramente come “Scrittura di procedure automatizzate per la gestione delle banche dati”, risponde pienamente ai criteri per essere definita come competenza.
È composta da un insieme di conoscenze teoriche (sulle strutture dei Data Base, sul linguaggio di interrogazione, ecc.), ma anche di abilità pratiche (sull’uso del software per interfacciarsi al server di gestione degli archivi, ecc.).
È rivolta al raggiungimento di un obiettivo misurabile e segregabile (Quante stored procedure sono in grado di scrivere? Di che complessità? Se non lo so fare io, lo può fare qualcun altro al posto mio, mentre io svolgo altro di utile? Se, al contrario, io lo so fare, posso aiutare qualcun altro a farlo mentre lui fa attività a monte o a valle nella catena di produzione?). Può essere, infine, definita su livelli all’interno di una scala di autonomia nel raggiungimento dell’obiettivo. Per esempio, ha senso dire che io sia completamente incapace, che sia un principiante (quindi posso partecipare all’attività, ma da solo non riuscirei a portare a casa nessun risultato), che sia un esecutore (ovvero sono autonomo nel fare ciò che gli altri mi ordinano e supervisionano), che sia un esperto (ovvero posso operare sotto la mia responsabilità) o, addirittura, un responsabile (ho, quindi tutte le capacità per ordinare e supervisionare quanto fanno gli altri). 
 
 

Le Competenze in Aree

Insomma, all’interno di Exagogica (ma anche all’interno della maggior parte delle altre software house), la “Scrittura di stored procedure” è sicuramente una competenza. Peccato che ce ne siano almeno qualche altra decina, se non centinaia. Da qui la necessità di raggruppare le competenze in aree. Questo tipo di sistemazione tassonomica è abbastanza semplice se viene fatta con logica bottom-up. Se torniamo all’esempio di prima, basterà mettere insieme tutte le competenze che concorrono all’ottenimento del risultato complessivo.
 
Quando scrivo semplice, non voglio dire che la soluzione sia scontata. Nel nostro caso, il risultato complessivo potrebbe essere la creazione e la gestione di Banche Dati, quindi le competenze dell’area “Data Base”, oltre alla “Scrittura di stored procedure” potrebbero essere, ad esempio, “Disegno delle strutture dati”, “Manutenzione e ottimizzazione dei data base”, “Interfacciamento ad applicazioni esterne”, ecc. Qualcuno, però, potrebbe anche intendere come area non i “Data Base“, ma lo “Sviluppo di applicazioni”, poiché la “Scrittura di stored procedure” è uno degli aspetti necessari allo sviluppo di una qualsiasi delle nostre applicazioni.
 
Qual è la scelta giusta? Lo sono entrambe? No. La scelta giusta è la prima perché, organizzando una tassonomia funzionale ai nostri scopi, se adottiamo “Data Base” come area, la competenza “Scrittura di stored procedure” potrà essere dichiarata solo all’interno di essa. Al contrario, se l’area fosse lo “Sviluppo di applicazioni”, la “Scrittura di stored procedure” potrebbe essere necessaria qui, ma anche, per esempio, nell’area “Personalizzazione delle istanze”, oppure “Manutenzione e ottimizzazione delle applicazioni”.
Il criterio che deve guidare la definizione delle aree è, quindi, diverso da quello delle competenze. Per non rischiare di creare un sistema intrinsecamente contraddittorio, si deve abbandonare la logica del “prodotto” (le competenze possono essere collegate al risultato tangibile che consentono di ottenere, quindi l’intensità con cui viene applicata una competenza è misurabile e si ritrova nel livello della prestazione che ne consegue).
Per le aree (che hanno solo scopo tassonomico), può valere invece un criterio di contiguità delle conoscenze e delle abilità richieste dalle competenze contenute. Pertanto, visto che la conoscenza dei Data Base relazionali e delle logiche del loro linguaggio di interrogazione è sottostante a tutte le competenze che abbiamo citato come esempio, possiamo desumere che l’area opportuna in cui raggrupparle sia proprio quella dei “Data Base”.
 

I Settori 

In una organizzazione abbastanza articolata, questo tipo di suddivisione però non appare sufficiente. Visto che le aree che servirebbero per descrivere le competenze necessarie in una software house sono diverse decine, bisognerà introdurre un secondo livello, che nascerà dall’aggregazione di più aree all’interno di ciò che noi abbiamo sempre chiamato “Settore”.
L’area “Data Base” avrà attinenze con l’area “Programmazione”, mentre ne avrà meno con l’area “Contabilità”. Le prime due potranno essere quindi inserite in un settore “Informatica”, mentre la terza potrà essere inserita in un settore “Gestione”. In questa classificazione i settori sono di fatto dei contenitori delle aree e consentono semplicemente di gestirle con maggiore efficienza. In questo tipo di suddivisione ha anche un senso definire il livello di competenza di una persona in un’area o in un settore. La competenza, in questo caso, può essere espressa, più che come livello medio (che è poco rilevante, perché non si sa a quante competenze fa riferimento), come indice di copertura ad un determinato livello. Mi spiego meglio. Dire che una risorsa in una software house copre l’area Data Base con un livello da esperto per il 75% delle competenze richieste, significa che questa è in grado di raggiungere in totale autonomia il 75% dei diversi tipi di risultato concreto che l’azienda si attende.
 
 

I Tipi

I settori (e le aree e le competenze in essi organizzate), possono poi essere divise in Tipi. Non tutte le competenze infatti, sono legate al contesto specifico. Facciamo anche in questo caso un esempio pratico. Parlare in lingua inglese per un non madre lingua è sicuramente una competenza. È valutabile in maniera obiettiva. È classificabile all’interno di un’area (Lingua Inglese), dove trovano posto anche le altre competenze collegate allo stesso contenuto (l’Inglese), come, per esempio, ascoltare e comprendere un discorso in inglese, scrivere in inglese, leggere testi in inglese.
L’area “Lingua Inglese”, con lo stesso tipo di ragionamento, è perfettamente inseribile all’interno di un settore “Lingue”. Eppure, è evidente che, nel contesto della mia software house, “Parlare in Inglese” non ha la stessa valenza di “Scrittura di stored procedure” (badate bene che ho scritto giustamente “Parlare in Inglese”, che è diverso dallo scrivere “Inglese parlato” e ne capirete il motivo alla fine del mio ragionamento…). Scrivere una stored procedure è per noi un risultato valorizzabile. Parlare inglese, no. È chiaro che parlare in inglese è estremamente importante, soprattutto in un contesto internazionale come il nostro, ma non è l’obiettivo del nostro agire. Nessuno ci paga per farlo.
 
Potremmo dire che, sempre in riferimento al nostro contesto, “Scrittura di una stored procedure” è una competenza che specifica il “cosa” dobbiamo fare, mentre “Parlare in Inglese” ci dice “come” siamo in grado di farlo. Se qualcuno dei programmatori di Exagogica deve scrivere una stored procedure da solo, il fatto che parli fluentemente inglese non avrà alcuna rilevanza. Se, invece, la stored la deve scrivere insieme o per conto di un collega della software factory estera, sarà invece assolutamente fondamentale che lo sappia fare. 
 
SOFT SKILL_ HARD SKILL
 
 
Bene, mentre la “Scrittura di una stored procedure” (e tutte quelle dell’area che la racchiude e del relativo settore) è una competenza di tipo “professionale”, il “Parlare in inglese” è, invece, una competenza di tipo abilitante (o, come si dice comunemente, trasversale). Con un’altra terminologia, la prima è una “Hard skill”, la seconda è una “Soft Skill”.
Adesso qualcuno storcerà sicuramente il naso. Proverà a richiamare alla mente elenchi di Soft Skill letti su qualche manuale e dirà: ”L’Inglese non c’era! Le Soft Skill sono un’altra cosa!”. Perché? Forse perché la conoscenza della lingua inglese appare misurabile, mentre siete abitati a considerare le Soft Skill come qualcosa di imponderabile e, tutto sommato, fumoso? Bene (cioè male…), se anche fosse così, allora dovremmo ammettere che parlare di Soft Skill non avrebbe senso (visto che non si potrebbero circoscrivere e misurare).
  

"La classificazione delle Competenze non può essere statica, ma è relativa al contesto."

Ma, per vedere se questo è vero e se esse sono diverse dalle caratteristiche della competenza “Parlare in inglese” così come appena descritta, pensiamo ad altre soft skill che ci appaiono più familiari, come, per esempio, la determinazione, oppure la capacità di ascolto e applichiamole alla situazione precedente. Se un programmatore sa fare una stored procedure, la farà sicuramente meglio se agirà in maniera determinata. Se poi dovesse lavorare con qualcun altro, sarebbe molto meglio se possedesse capacità di ascolto. Se questo collega, poi, fosse di un altro paese, sarebbe meglio che parlasse bene inglese! Allo stesso tempo, se il nostro programmatore possedesse tutte queste competenze (determinazione, capacità di ascolto, capacità di parlare in inglese), anche al massimo della capacità richiesta, ma non fosse in grado di scrivere una stored procedure… bene, possiamo dire che non servirebbe proprio a nulla!
 
Questo esempio di classificazione della capacità di parlare la lingua inglese nelle Soft Skill (o, come io preferisco definirle, nelle competenze abilitanti) ci porta a sottolineare due aspetti per nulla scontati della metodologia di classificazione delle competenze.
 
1) Il primo è che la classificazione non può essere statica e universalmente valida, ma è relativa al contesto. In contesti diversi la stessa competenza può e deve essere classificata in aree diverse e, addirittura, in tipi opposti. L’esempio della lingua inglese dimostra proprio come una competenza “soft” possa essere concreta, codificata e valutabile e possa diventare “hard” nei contesti in cui il suo esercizio assume carattere finalistico, ovvero nel suo specifico contesto professionale.
 
2) L’altro aspetto, direttamente collegato al primo, è che la creazione di un catalogo di competenze debba avvenire prima attraverso la descrizione del processo e l’isolamento di competenze significative e poi attraverso la loro classificazione all’interno di strutture logiche (aree, settori, tipi) funzionali alla loro gestione.
 
La dichiarazione di competenze così come viene invece fatta di solito, ovvero partendo da strutture logiche preesistenti e considerate a-priori (es. Tipo: Competenze umanistiche, Settore: Lingue, Area: Lingue del ceppo anglossassone) è logicamente errata e particolarmente pericolosa, poiché porta a dichiarare competenze inutili alla specifica mappatura funzionale (es. lingue che non si usano nel processo considerato) e, soprattutto, di granularità molto diversa fra loro (es. l’intero dominio della lingua inglese come singola competenza).
 
Per questo motivo la classificazione delle competenze è un’attività particolarmente sensibile, che non deve essere sottovalutata e che va assolutamente approcciata in maniera induttiva e con rigore metodologico.
 

 

Alessandro Obino, CEO Exagogica

© Riproduzione riservata

Condividi





Scopri e leggi tutti i nostri articoli