Lezione di Gestione Progetto e Organizzazione d’Impresa (GPO) • Dalla struttura funzionale al team temporaneo • Matrice RACI • Glossario tecnico

 

Obiettivi di apprendimento

Al termine della lezione saprai distinguere gerarchia e coordinamento, disegnare organigrammi leggibili, rappresentare correttamente incarichi temporanei, interpretare la doppia dipendenza, compilare una matrice RACI e spiegare il lessico di un progetto informatico.

1. Che cos’è un organigramma

L’organigramma è la rappresentazione grafica della struttura formale di un’organizzazione: mostra unità, ruoli, livelli di responsabilità e relazioni di autorità o coordinamento. Non coincide con l’elenco completo delle mansioni e non descrive, da solo, tutti i processi di lavoro. Serve a rispondere a domande come: chi guida un’area? A chi fa riferimento una persona? Quali funzioni collaborano?

Si distingue l’organigramma aziendale, relativamente stabile, dall’organigramma di progetto, valido per la durata di una specifica iniziativa. La stessa persona può comparire in entrambi: non significa che sia stata assunta due volte o trasferita definitivamente.

2. Come si costruisce: metodo in sette passaggi

1. Definire lo scopo. Decidere se rappresentare l’intera azienda, un reparto oppure un progetto. Stabilire il livello di dettaglio adatto ai destinatari.
2. Individuare le macrostrutture. Elencare le direzioni permanenti: Sviluppo Software, Infrastruttura e DevOps, Commerciale e Marketing, Amministrazione e HR.
3. Individuare il vertice e le funzioni di staff. Porre il CEO in alto e collocare accanto le funzioni che forniscono consulenza o supporto, senza attribuire loro automaticamente potere gerarchico.
4. Disegnare le dipendenze formali. Unire il vertice alle direzioni e queste alle unità subordinate con linee continue, quando rappresentano effettivamente un rapporto gerarchico.
5. Definire il progetto temporaneo. Indicare il Project Manager e le risorse assegnate, precisando provenienza, numero di persone, compito e durata dell’assegnazione.
6. Differenziare i legami. Usare tratteggi, colori e una legenda per separare la struttura stabile dal coordinamento di progetto. Non affidarsi soltanto al colore.
7. Controllare la coerenza. Verificare che ogni persona abbia una collocazione funzionale chiara, che i collegamenti non si contraddicano e che responsabilità e approvazioni siano documentate.

3. Simbologia: riquadri, linee e legenda

Elemento grafico	Significato didattico	Avvertenza
Riquadro con bordo continuo	Unità o ruolo stabile nell’azienda	Non implica, da solo, un livello gerarchico.
Linea continua verticale	Dipendenza gerarchica formale	Usarla solo se il rapporto è effettivo.
Linea tratteggiata	Relazione funzionale, di staff o assegnazione temporanea	Il significato preciso va scritto nella legenda.
Riquadro tratteggiato	Risorsa o incarico temporaneo di progetto	Convenzione grafica adottata in questa esercitazione, non standard universale.
Contenitore di gruppo	Team o unità composta da più ruoli	Può racchiudere risorse provenienti da più reparti.
Colore coerente	Identifica l’area di provenienza	Aggiungere sempre un’etichetta testuale.

Importante: non esiste un’unica simbologia obbligatoria per tutti gli organigrammi. In particolare, le linee tratteggiate possono indicare staff, coordinamento o relazione funzionale. La legenda deve evitare interpretazioni ambigue.

 

4. Dal modello funzionale alla struttura a matrice

Nella struttura funzionale, le persone sono raggruppate per competenze. Il CTO coordina lo sviluppo, la Direzione Infrastruttura gestisce sistemi e servizi, la Direzione Commerciale segue clienti e vendite, mentre Amministrazione e HR curano contabilità e personale. Questo modello favorisce specializzazione, standard tecnici e continuità.

La commessa BankApp richiede però competenze diverse nello stesso periodo. L’azienda crea quindi un team di progetto trasversale, coordinato da un Project Manager. Nasce una struttura a matrice: la dimensione verticale è la funzione di appartenenza; la dimensione orizzontale è il progetto. Una matrice può essere debole, bilanciata o forte a seconda di quanto potere decisionale è attribuito al PM rispetto ai responsabili funzionali.

Figura 2 — Vista d’insieme dei due organigrammi. È una rappresentazione illustrativa ampliata: alcune figure di supporto mostrate sono esempi possibili, non necessariamente risorse richieste dalla traccia originaria.

 

5. Ruoli, responsabilità e focus

Il ruolo definisce la posizione o funzione svolta; la responsabilità indica i risultati di cui rispondere; il focus identifica la priorità prevalente. Non vanno confusi il ruolo aziendale permanente e l’incarico nel progetto.

Ruolo	Responsabilità prevalente	Focus
CEO	Strategia, indirizzo, risorse e decisioni aziendali	Perché e con quali obiettivi
CTO / responsabile sviluppo	Architettura, standard, qualità tecnica, crescita delle competenze	Come realizzare correttamente
Project Manager	Pianificazione, scadenze, coordinamento, costi, rischi e comunicazioni	Cosa consegnare e quando
Developer / Dev Lead	Implementazione, revisione del codice, test e guida tecnica del team	Esecuzione e qualità del software
DevOps Engineer	Pipeline, ambienti, automazione, rilascio e osservabilità	Affidabilità della delivery
Account Manager	Relazione commerciale e coordinamento con il cliente	Esigenze e aspettative del cliente
HR	Selezione, sviluppo, formazione e gestione delle persone	Competenze e personale

6. Dipendenza gerarchica, funzionale e di progetto

La dipendenza gerarchica identifica chi esercita l’autorità organizzativa stabile (ad esempio assegnazione alla direzione, valutazioni e gestione del personale secondo le regole aziendali). La dipendenza funzionale indica indirizzi professionali, standard o supporto specialistico. La dipendenza di progetto riguarda le attività, le priorità e i risultati della commessa entro i poteri attribuiti al PM.

Esempio: uno sviluppatore riceve dal CTO la richiesta di partecipare a una formazione sulla qualità del codice e dal PM la richiesta di completare una funzione di BankApp entro venerdì. Se le due attività sono incompatibili per tempi e capacità, non deve decidere da solo quale “capo” ignorare: il conflitto va reso esplicito e risolto mediante priorità condivise, pianificazione e, se necessario, escalation.

7. La doppia dipendenza (double reporting): vantaggi e rischi

Il doppio reporting è la situazione in cui una risorsa risponde a due linee di coordinamento: la direzione funzionale per competenze e continuità, e il progetto per consegne e tempi. Permette di condividere specialisti senza duplicare reparti, ma può creare sovraccarico, priorità incompatibili e responsabilità poco chiare.

Per gestirlo servono: un piano realistico della capacità delle risorse; una regola per stabilire le priorità; riunioni brevi tra PM e responsabili funzionali; un registro delle decisioni; e una matrice RACI per le attività importanti. La RACI chiarisce le responsabilità, ma non sostituisce la negoziazione delle risorse né risolve automaticamente i conflitti.

8. Che cos’è la matrice RACI

La matrice RACI è una tabella che incrocia attività o deliverable (righe) e ruoli (colonne). In ogni cella si indica il tipo di partecipazione di quel ruolo all’attività. RACI è un acronimo inglese: Responsible, Accountable, Consulted, Informed. Le lettere non rappresentano gradi gerarchici, ma responsabilità relative a uno specifico lavoro.

R = esegue materialmente il lavoro (possono esserci più R).
A = è il riferimento unico per l’esito e l’approvazione finale, secondo il modello RACI classico (preferibilmente un solo A per riga).
C = viene consultato prima o durante la decisione: comunicazione a due vie.
I = viene informato dell’esito o dello stato: comunicazione prevalentemente a una via.
Un ruolo può avere A/R se svolge e approva la stessa attività.

9. Esempio di matrice RACI per BankApp

Attività	CTO	PM	Dev Lead	DevOps	Cliente
Scelta architettura	A	C	R	C	I
Piano milestone e sprint	C	A/R	C	C	C
Sviluppo login SPID/CIE	C	A	R	C	I
Configurazione pipeline CI/CD	C	A	C	R	I
Approvazione variazioni di budget*	C	R	I	I	A
Accettazione finale del prodotto*	I	R	C	C	A

* Le ultime due righe sono esempi contrattuali: l’Accountable effettivo dipende dalle deleghe aziendali e dagli accordi con il cliente. Se la modifica di budget è interna, l’A potrebbe spettare alla direzione aziendale anziché al cliente. In un caso reale occorre definire esplicitamente i poteri di approvazione.

10. Procedura per compilare una RACI corretta

Si parte dai deliverable, non dai nomi delle persone. Per ciascuna attività si individua chi la esegue (R), chi ne approva l’esito e ne risponde (A), chi deve contribuire con pareri (C) e chi deve soltanto ricevere comunicazioni (I). Infine si controllano righe prive di R, righe con più A non giustificati, ruoli sovraccarichi e consultazioni inutili.

11. Esercizio guidato e verifica

Disegna due organigrammi affiancati: a sinistra la struttura funzionale di TechVision Solutions con CEO, staff e quattro direzioni; a destra il progetto BankApp con PM e almeno tre sviluppatori, un DevOps e un referente commerciale. Mantieni i colori delle direzioni di provenienza; usa un bordo tratteggiato per gli incarichi temporanei e aggiungi una legenda. Compila poi una RACI per architettura, pianificazione, sviluppo, test e budget.

Domande di controllo: (1) Perché uno sviluppatore compare in due schemi? (2) Una linea tratteggiata indica sempre lo stesso tipo di relazione? (3) Qual è la differenza tra R e A? (4) Chi risolve un conflitto tra scadenza del progetto e formazione tecnica? (5) La RACI assegna automaticamente il potere di spesa? Motiva le risposte.

12. Glossario ragionato

Account Manager — Figura che cura la relazione commerciale con uno o più clienti, raccoglie esigenze, gestisce aspettative e opportunità; non coincide necessariamente con il PM.

Accountable (A) — Ruolo che risponde dell’esito finale di una specifica attività e ne autorizza l’accettazione secondo le deleghe stabilite. Nella RACI classica si preferisce un solo A per attività.

Agile — Insieme di valori e principi per sviluppare prodotti in modo iterativo, con feedback frequente e capacità di adattamento; non è un singolo metodo.

Ambiente di sviluppo / test / staging / produzione — Contesti separati in cui il software viene scritto, verificato, collaudato in condizioni simili al reale e infine reso disponibile agli utenti.

API — Application Programming Interface: interfaccia che permette a sistemi o programmi di comunicare secondo regole definite.

Architettura software — Organizzazione dei componenti di un sistema, delle loro interazioni e delle principali scelte tecniche.

Back-end / Front-end — Il back-end gestisce logica applicativa, dati e servizi; il front-end è la parte con cui l’utente interagisce.

Budget — Quantità di risorse economiche autorizzate per un progetto o una sua parte; può includere personale, infrastrutture e servizi.

CEO — Chief Executive Officer: vertice esecutivo aziendale, responsabile dell’indirizzo generale e delle decisioni secondo l’assetto societario.

CI/CD — Continuous Integration / Continuous Delivery (o Deployment): pratiche e pipeline automatizzate per integrare, testare e preparare o effettuare rilasci. Delivery richiede tipicamente un passaggio di autorizzazione al rilascio; Deployment può automatizzarlo.

CIE — Carta d’Identità Elettronica: documento e sistema di identificazione digitale utilizzabile per accedere a servizi abilitati.

Cloud — Risorse informatiche erogate via rete, come server, archiviazione e servizi gestiti, spesso scalabili a richiesta.

Commessa — Incarico contrattuale conferito da un cliente per realizzare beni o servizi secondo requisiti, tempi e corrispettivi.

Consultant / Consulente — Professionista che fornisce competenze e raccomandazioni; può essere interno o esterno. Non equivale automaticamente a Consulted della RACI.

Consulted (C) — Ruolo consultato per fornire competenze o pareri prima o durante il lavoro o la decisione; lo scambio è bidirezionale, ma C non approva automaticamente.

CTO — Chief Technology Officer: responsabile della direzione tecnologica e, secondo l’organizzazione, delle scelte tecniche, standard e sviluppo.

Deliverable — Risultato verificabile che un progetto deve produrre, come un modulo software, un documento, un test o una versione funzionante.

Deployment — Distribuzione e attivazione di una versione software in un ambiente, soprattutto staging o produzione; distinto dalla semplice compilazione del codice.

Dev Lead / Technical Lead — Sviluppatore con responsabilità di guida tecnica: indirizza scelte implementative, revisioni del codice e coordinamento tecnico; non è necessariamente il capo gerarchico.

Developer / Dev — Sviluppatore che progetta, scrive, verifica e mantiene codice software.

DevOps — Approccio culturale e tecnico che integra sviluppo e operations tramite collaborazione, automazione, CI/CD, monitoraggio e gestione dell’infrastruttura. DevOps Engineer è un ruolo, DevOps non è solo un reparto.

Doppia dipendenza / Double reporting — Situazione in cui una risorsa risponde sia alla funzione aziendale sia al coordinamento di progetto, con possibili conflitti di priorità.

DPO — Data Protection Officer (Responsabile della protezione dei dati): figura prevista dal GDPR in determinati casi, con compiti di consulenza e sorveglianza della conformità. Deve poter operare con indipendenza nei compiti assegnati.

Escalation — Trasferimento di un problema o decisione a un livello con autorità adeguata quando i soggetti operativi non riescono a risolverlo.

Feature — Funzionalità del prodotto che offre un valore riconoscibile all’utente o al cliente.

Funzione di staff — Unità che fornisce supporto o consulenza alla direzione o ad altre aree, senza necessariamente esercitare comando gerarchico su di esse.

Gerarchia di linea — Catena formale di autorità e responsabilità all’interno della struttura aziendale.

HR — Human Resources: funzione che si occupa di selezione, gestione, formazione e sviluppo del personale.

Helpdesk — Servizio di assistenza che riceve, classifica e gestisce richieste e problemi degli utenti.

Informed (I) — Ruolo che deve ricevere informazioni sullo stato o sull’esito dell’attività; in genere non è chiamato a decidere o a eseguire.

KPI — Key Performance Indicator: indicatore misurabile usato per valutare un risultato o l’andamento di un processo.

Milestone — Traguardo significativo del progetto, spesso associato a una data o a un risultato verificabile; non coincide necessariamente con un’attività.

Organigramma — Schema della struttura formale che mostra ruoli, unità e relazioni organizzative.

PM / Project Manager — Responsabile del coordinamento del progetto entro l’autorità delegata: pianifica, monitora tempi e costi, gestisce rischi e comunicazioni.

Product Owner — Nel framework Scrum, figura responsabile di massimizzare il valore del prodotto e della gestione efficace del Product Backlog; non coincide necessariamente con il PM.

QA / Tester — Quality Assurance: attività e ruoli per prevenire e rilevare difetti; il tester esegue verifiche sul comportamento del software.

RACI — Matrice che attribuisce, per ciascuna attività, Responsible, Accountable, Consulted e Informed.

Refactoring — Riorganizzazione del codice per migliorarne la struttura interna senza modificarne intenzionalmente il comportamento esterno.

Responsible (R) — Chi esegue concretamente il lavoro necessario per completare una determinata attività.

Rilascio / Release — Versione del software resa disponibile o preparata per la distribuzione, secondo un processo di approvazione.

RSPP — Responsabile del Servizio di Prevenzione e Protezione: figura della sicurezza sul lavoro prevista dal D.Lgs. 81/2008; ruolo distinto dal DPO.

Scrum — Framework Agile con responsabilità, eventi e artefatti definiti per affrontare problemi complessi e produrre valore in modo iterativo.

Scrum Master — Responsabilità prevista da Scrum: favorisce la comprensione e l’applicazione del framework e aiuta a rimuovere impedimenti organizzativi.

SPID — Sistema Pubblico di Identità Digitale: sistema italiano di accesso ai servizi online tramite identità digitale.

Sprint — Periodo di durata fissa, non superiore a un mese in Scrum, durante il quale si lavora a un obiettivo e a un incremento di prodotto.

Stakeholder — Persona o organizzazione interessata dal progetto o capace di influenzarlo: cliente, utenti, direzione, team e altri soggetti.

Struttura a matrice — Modello che incrocia direzioni funzionali e progetti, condividendo risorse e responsabilità di coordinamento.

Struttura funzionale — Modello che raggruppa persone e risorse per specializzazione o funzione aziendale.

System Administrator — Figura che gestisce sistemi operativi, server, account, configurazioni e disponibilità dei servizi.

Task — Unità di lavoro assegnabile e monitorabile, spesso parte di un’attività o deliverable più ampio.

UX/UI — User Experience: qualità dell’esperienza d’uso; User Interface: elementi visivi e interattivi dell’interfaccia.

Workload / Capacità — Carico di lavoro richiesto e disponibilità effettiva di una persona o squadra in un certo intervallo di tempo.

Nota conclusiva

L’organigramma risponde soprattutto alla domanda «come è organizzata l’azienda?», quello di progetto a «come si coordinano le persone per questa commessa?», la RACI a «chi fa, chi approva, chi viene consultato e chi viene informato per ogni attività?». Usati insieme, questi strumenti rendono visibili le responsabilità e aiutano a prevenire ambiguità.

Riferimenti per approfondire: Scrum Guide (Schwaber e Sutherland, 2020); Regolamento UE 2016/679, artt. 37–39 (DPO); D.Lgs. 81/2008, artt. 31–33 (servizio di prevenzione e protezione); documentazione AgID su SPID e CIE. Le convenzioni grafiche di questa lezione sono scelte didattiche dichiarate nella legenda.