L'ho fatto io o il team? Come descrivere onestamente il proprio contributo nel portfolio

La maggior parte dei prodotti, delle campagne, delle implementazioni e dei processi di valore nasce dal lavoro di squadra.

Per questo mostrare soltanto il risultato finale non dice ancora quale ruolo abbia svolto davvero uno specifico specialista.

Per chi valuta un portfolio, la differenza è enorme:

"Ho lavorato alla riprogettazione del processo di completamento dell'acquisto"

non significa lo stesso di:

"Ho guidato la ricerca, progettato il nuovo percorso di completamento dell'acquisto, preparato il prototipo e condotto test di usabilità. Un team separato di sviluppo dell'interfaccia si è occupato dell'implementazione."

La seconda descrizione consente di valutare le competenze reali senza sminuire il lavoro degli altri.

Il problema non riguarda soltanto i portfolio professionali.

Nel mondo delle pubblicazioni scientifiche esiste, tra gli altri, CRediT - Contributor Role Taxonomy. Lo standard descrive 14 tipi di contributo ed è stato creato per rendere più trasparente chi sia stato realmente responsabile delle diverse parti di un lavoro. CRediT consente di assegnare più ruoli a una persona e lo stesso ruolo a più persone. Raccomanda inoltre che i collaboratori possano verificare e confermare i ruoli loro attribuiti. [1]

CRediT riguarda soprattutto la ricerca e le pubblicazioni scientifiche. Non è uno standard per i portfolio professionali. Mostra però un principio utile anche in altri contesti: invece della vaga affermazione "ho fatto parte del progetto", è meglio indicare chiaramente la natura del proprio contributo effettivo.

Una buona descrizione di un progetto di squadra può essere costruita intorno a sei informazioni:

1. Contesto del progetto
2. Composizione e ambito del team
3. Responsabilità personale
4. Azioni e decisioni concrete
5. Artefatti o prove del lavoro
6. Risultato e modalità di attribuzione

L'obiettivo non è scrivere un lungo rapporto. È eliminare le ambiguità più importanti.

Per prima cosa spiega su che cosa stava realmente lavorando il team.

È sufficiente indicare brevemente:

• il problema o l'obiettivo,
• il tipo di prodotto o servizio,
• la scala approssimativa,
• i vincoli importanti,
• il periodo di realizzazione, se rilevante.

Esempio:

L'obiettivo del progetto era abbreviare il processo di acquisto in un'applicazione B2B. Il prodotto operava in diversi mercati europei e serviva clienti aziendali.

In questo modo il lettore comprende il contesto prima di valutare il contributo individuale.

Non è necessario elencare ogni persona per nome.

In molti casi basta una struttura come:

Team: responsabile di prodotto, progettista dell'esperienza utente, 2 sviluppatori dell'interfaccia, 2 sviluppatori lato server e uno specialista della qualità.

Questa sola informazione cambia il modo in cui viene interpretata l'intera descrizione del progetto.

Il lettore capisce che il risultato non è nato in isolamento e che lo specialista lavorava all'interno di una precisa distribuzione delle responsabilità.

Questa è la parte più importante.

Invece di una frase generica come:

"ho lavorato sull'interfaccia"

scrivi qualcosa di concreto:

"ero responsabile dell'architettura del modulo di pagamento, dell'implementazione del processo di completamento dell'acquisto, dell'integrazione con l'API di pagamento e della revisione del codice per le modifiche in quest'area."

Può essere utile anche indicare ciò che non hai fatto quando potrebbe essere ambiguo:

"il livello server e l'integrazione lato server con il fornitore di pagamenti sono stati realizzati da un altro team."

Questo non indebolisce il portfolio. Lo rende più credibile.

Il titolo professionale non descrive ancora il contributo.

Un progettista senior dell'esperienza utente può guidare l'intero processo di ricerca in un progetto e, in un altro, preparare soltanto le schermate finali.

Mostra quindi azioni collegate a competenze concrete:

• ho progettato l'architettura della soluzione,
• ho condotto ricerche,
• ho progettato il flusso del processo,
• ho analizzato i dati,
• ho scritto una parte fondamentale dell'implementazione,
• ho preparato la strategia della campagna,
• ho condotto negoziazioni,
• ho coordinato le dipendenze tra i team,
• ho verificato la soluzione prima del rilascio.

Gli esempi più utili sono quelli in cui puoi anche spiegare perché è stata presa una determinata decisione.

Se il progetto può essere mostrato, un artefatto aiuta a collegare il contributo dichiarato al lavoro reale.

Può essere, per esempio:

• una schermata del prodotto,
• una parte dell'interfaccia,
• un prototipo,
• un frammento di codice,
• un repository pubblico,
• un rapporto,
• un diagramma,
• una pubblicazione,
• materiale di campagna,
• una fotografia,
• un documento o una sua parte che possa essere mostrata in sicurezza.

L'artefatto non deve dimostrare tutto. Deve aiutare il lettore a capire che cosa è stato realmente creato e come si collega al contributo descritto.

Il rischio maggiore di esagerare il proprio contributo nasce quando si descrivono i risultati.

Se il tasso di conversione di un'azienda aumenta del 25% dopo un progetto, ciò non significa automaticamente che una persona abbia aumentato la conversione del 25%.

Nello stesso periodo potrebbero essere cambiati:

• i prezzi,
• l'offerta,
• il marketing,
• l'esperienza utente,
• l'infrastruttura,
• la stagionalità,
• le fonti di traffico,
• il lavoro degli altri membri del team.

Descrivi il risultato solo con il livello di certezza che puoi realmente giustificare.

1. Responsabilità diretta
"Ho ridotto il tempo necessario per questo processo da 12 a 4 minuti automatizzando i passaggi di cui ero responsabile."

Usa questa formulazione quando il rapporto tra la tua azione e il risultato è diretto e giustificabile.

2. Risultato condiviso
"Insieme al team abbiamo riprogettato il processo di inserimento degli utenti. Dopo il rilascio, il tasso di completamento è aumentato del 18%."

Usa questa formulazione quando il risultato nasce dal lavoro di più persone.

3. Contributo a un cambiamento più ampio
"Ero responsabile della riprogettazione del processo di completamento dell'acquisto come parte di una più ampia ottimizzazione del processo di acquisto. Dopo il rilascio dell'intero programma, l'azienda ha registrato un aumento della conversione."

Usa questa formulazione quando la tua area era solo uno dei diversi fattori.

4. Risultato come contesto del progetto
"Il progetto si è concluso con un aumento delle vendite del 40%. Il mio ambito comprendeva l'architettura lato client e l'implementazione del processo di completamento dell'acquisto."

Usa questa formulazione quando conosci il risultato complessivo del progetto ma non hai basi solide per stabilire quale parte derivi dal tuo lavoro.

Quando un progetto presenta più persone, la descrizione migliore dovrebbe rispondere contemporaneamente a due domande:

Che cosa ha consegnato il team?

e

Di che cosa era responsabile ciascuna persona?

Esempio:

Progetto: prima versione di un'applicazione per la logistica
Team: progettista dell'esperienza utente, sviluppatore dell'interfaccia, sviluppatore lato server
Risultato condiviso: prima versione funzionante del prodotto pronta per un progetto pilota
Progettista dell'esperienza utente: ricerca, percorso utente, prototipo, progettazione dell'interfaccia
Sviluppatore dell'interfaccia: architettura lato client, implementazione dell'applicazione web
Sviluppatore lato server: API, modello dati, integrazioni

Una descrizione di questo tipo rafforza sia il team sia i singoli specialisti.

In alcuni progetti possono essere utili descrizioni semplici del livello di partecipazione:

Ruolo principale - ho guidato l'area ed ero responsabile delle decisioni chiave.
Responsabilità condivisa - ho condiviso la responsabilità con una o più persone.
Ruolo di supporto - ho supportato l'area, ma non ne ero il principale responsabile.

CRediT utilizza una distinzione simile per i ruoli dei collaboratori. [1]

Il principio più importante è semplice: il livello di responsabilità deve essere comprensibile.

Nei progetti condivisi importanti vale la pena verificare che la descrizione del proprio contributo non contraddica chiaramente il modo in cui gli altri partecipanti comprendono i ruoli.

CRediT raccomanda che i collaboratori possano rivedere e confermare i ruoli loro attribuiti. [1]

In un portfolio professionale questo non deve significare un processo formale di approvazione di ogni frase. La regola pratica è più semplice: non attribuirti una responsabilità che in realtà era guidata da qualcun altro.

Descrivere il proprio contributo non deve essere confuso con la determinazione dei diritti d'autore.

Secondo la normativa polacca sul diritto d'autore, i diritti spettano in linea di principio all'autore e sono detenuti congiuntamente dai coautori. Per le opere create nell'ambito di un rapporto di lavoro, il datore di lavoro può acquisire i diritti patrimoniali nei limiti previsti dalla legge e dal rapporto di lavoro. [2]

In pratica, è opportuno trattare separatamente tre domande:

Ho partecipato alla creazione del progetto?
Sono autore o coautore di uno specifico elemento?
Ho il diritto di pubblicare il materiale nel mio portfolio?

Rispondere "sì" alla prima domanda non determina automaticamente le altre due.

Non tutti i progetti possono essere mostrati o descritti in dettaglio.

La normativa polacca sulla concorrenza sleale protegge le informazioni che costituiscono segreto commerciale, comprese determinate informazioni tecniche, tecnologiche, organizzative e altre informazioni di valore economico mantenute riservate. [3]

Per questo, in un progetto riservato, eliminare soltanto il nome del cliente potrebbe non essere sufficiente. Altri dettagli possono continuare a rivelare informazioni protette.

Una regola più sicura è:

descrivi soltanto ciò che sei realmente autorizzato a divulgare in base alla legge applicabile, ai contratti, ai consensi e agli altri diritti di cui disponi.

Una descrizione del progetto normalmente non richiede i dati privati dell'intero team.

Il GDPR richiede, tra le altre cose, liceità, limitazione delle finalità e minimizzazione dei dati, cioè che i dati personali siano limitati a ciò che è necessario per la finalità pertinente. [4]

Se è sufficiente descrivere il team così:

1 progettista dell'esperienza utente, 2 sviluppatori dell'interfaccia, uno sviluppatore lato server e uno specialista della qualità

non vi è alcuna necessità automatica di pubblicare nomi, fotografie, indirizzi e-mail o altri dati personali dei colleghi.

Se vuoi pubblicare una testimonianza, una dichiarazione, un'immagine o altri dati relativi a una persona specifica, verifica la base giuridica appropriata e l'ambito in cui il materiale può essere utilizzato.

Se le condizioni della collaborazione consentono una descrizione generale dell'esperienza, puoi valutare di mostrare:

• il tipo di problema senza identificare il cliente,
• il tuo ruolo,
• le categorie di competenze utilizzate,
• il tipo di responsabilità,
• il processo decisionale a un livello sufficientemente generale,
• il risultato solo nella misura in cui può essere divulgato.

Non inventare schermate, dati o risultati per sostituire materiale riservato.

Se non sei sicuro che una determinata informazione possa essere divulgata, è più sicuro non pubblicarla finché la questione non è stata chiarita.

Piccole differenze nella formulazione possono comunicare molto bene il livello di responsabilità.

Ero responsabile di... - attribuisce chiaramente il tuo ambito.
Ho guidato... - indica responsabilità per la direzione o l'esecuzione di una determinata area.
Ho cocreato... - mostra che il risultato ha avuto più di un autore.
Ho supportato... - descrive onestamente un contributo di supporto.
Facevo parte del team che... - separa la partecipazione individuale dal risultato complessivo del team.
Dopo il rilascio del progetto, l'azienda ha registrato... - presenta il risultato come contesto senza attribuirti automaticamente l'intero effetto.

Evita di dire automaticamente "l'ho fatto io" quando l'ambito reale era condiviso.

1. Usi il singolare per un progetto realizzato da molte persone.

2. Mostri un risultato commerciale senza spiegare il tuo ambito.

3. Elenchi le tecnologie dell'intero prodotto come tue competenze anche se non hai lavorato con tutte.

4. Mostri il progetto visivo finale, il codice o la strategia senza indicare quali parti hai realmente creato.

5. Ometti collaboratori chiave quando la loro partecipazione è necessaria per comprendere il progetto.

6. Suggerisci un rapporto causale tra il tuo lavoro e un risultato che non puoi giustificare.

Progetto
Che cosa veniva creato e quale problema doveva risolvere?

Team
Quali ruoli hanno partecipato al progetto?

La mia responsabilità
Di quale area ero personalmente responsabile?

Le mie azioni e decisioni
Che cosa ho fatto o guidato concretamente?

Collaborazione
Quali elementi sono stati creati insieme ad altre persone?

Artefatti
Che cosa posso mostrare legalmente?

Risultato
Che cosa ha ottenuto il progetto e in che modo il mio contributo si collegava al risultato?

Limitazioni
Ci sono elementi che non posso divulgare per riservatezza o per i diritti di altre persone?

Fatti sette domande:

1. Il lettore sa quanto era grande il team?

2. È chiaro esattamente di che cosa ero responsabile?

3. Ho evitato di attribuirmi il lavoro svolto da altre persone?

4. Il risultato è descritto con un livello adeguato di cautela?

5. Posso pubblicare legalmente i materiali utilizzati?

6. Evito di divulgare inutilmente dati personali o informazioni riservate?

7. Una persona esterna potrebbe capire da questa descrizione quali competenze ho realmente utilizzato?

Se le risposte sono chiare, la descrizione del progetto comincia a funzionare come prova di competenza e non solo come una storia attraente.

La migliore descrizione di un progetto non deve scegliere tra:

"l'ho fatto io"

e

"l'ha fatto il team."

Può mostrare entrambe le verità contemporaneamente:

il team ha consegnato un risultato specifico e io ero responsabile di una parte concreta, di determinate decisioni e della loro esecuzione.

Questo livello di precisione permette di valutare uno specialista senza togliere merito agli altri.

Un portfolio non dovrebbe essere una gara a chi formula l'affermazione più grande possibile.

Il suo valore aumenta quando chi lo legge può capire:

che cosa è stato creato, chi ci ha lavorato, di che cosa eri responsabile, che cosa hai fatto personalmente e quale risultato può essere ragionevolmente collegato al tuo contributo.

Una descrizione precisa non indebolisce un risultato.

Al contrario. Mostra che comprendi la tua responsabilità, sai collaborare con gli altri e rappresenti onestamente i risultati del tuo lavoro.

[1] CRediT - Contributor Role Taxonomy, NISO
Apri la fonte

[2] Legge polacca sul diritto d'autore e i diritti connessi - artt. 8-12, ELI
Apri la fonte

[3] Legge polacca contro la concorrenza sleale - art. 11, testo consolidato pubblicato nel 2026
Apri la fonte

[4] Regolamento (UE) 2016/679 - GDPR, art. 5, EUR-Lex
Apri la fonte

Nota metodologica: CRediT è uno standard relativo ai ruoli dei collaboratori nella ricerca e nelle pubblicazioni scientifiche. Questo articolo lo utilizza come esempio di attribuzione trasparente dei contributi, ma non lo presenta come standard per i portfolio professionali. I sei elementi della descrizione di un progetto e i quattro modi di descrivere il rapporto con i risultati costituiscono un modello editoriale proposto in questo materiale.