Concetti base, ridotti all'essenziale
Concetti insegnati in ogni corso di management, qui ridotti a quello che serve per applicare le tre regole viste nella lezione 1 — non la teoria completa.
Il triangolo del progetto
Ogni progetto è vincolato da tre variabili che si condizionano a vicenda: non si può cambiarne una senza che le altre due si muovano.
TEMPO
/\
/ \
/ \
/ VINCOLI\
/ REALI \
/ \
COSTO ────────────── QUALITÀ / AMPIEZZA
Vuoi il progetto più VELOCE? → costa di più o si riduce cosa consegni
Vuoi il progetto più ECONOMICO? → richiede più tempo o meno ampiezza
Vuoi TUTTO incluso, al massimo? → richiede più tempo o più budget
Quando qualcuno chiede "fallo prima, con lo stesso risultato, senza costi in più" sta chiedendo di violare questo triangolo — è matematicamente impossibile, non è questione di impegno o buona volontà. Il triangolo non è un'opinione tecnica: è un vincolo logico, vale per un'azienda come per la costruzione di una casa.
Strutture organizzative — chi risponde a chi
| Struttura | Come funziona | Vantaggio / limite |
|---|---|---|
| Gerarchica/Funzionale | Ogni persona risponde a un solo capo, raggruppata per competenza (commerciale, tecnico, amministrazione) | Chiara, ma lenta quando serve collaborazione stretta tra funzioni diverse |
| A matrice | Ogni persona risponde sia al proprio responsabile di funzione sia al responsabile del progetto specifico | Flessibile sui progetti, ma richiede che i due responsabili si coordinino esplicitamente — altrimenti genera conflitti di priorità |
| Per progetto | Un team dedicato lavora solo su un progetto, dall'inizio alla fine, con un unico responsabile | Massima focalizzazione, ma poco efficiente se l'azienda gestisce molti piccoli progetti in parallelo |
Un'azienda piccola con due soci (uno commerciale, uno tecnico) è già, di fatto, una struttura a matrice minima: ogni richiesta cliente attraversa entrambe le funzioni. La Regola 2 della lezione 1 è semplicemente la matrice resa esplicita invece che implicita.
RACI — chi fa cosa, in una parola
Uno degli strumenti più usati al mondo per eliminare ambiguità su chi decide cosa. Ogni attività ha esattamente queste quattro etichette assegnate a delle persone:
| Lettera | Significato |
|---|---|
| R — Responsible | Chi esegue materialmente il lavoro |
| A — Accountable | Chi risponde del risultato finale — una sola persona, mai due, altrimenti nessuno risponde davvero |
| C — Consulted | Chi va consultato prima che la decisione sia presa (parere a due vie) |
| I — Informed | Chi va informato dopo, perché la decisione lo riguarda, ma non decide né viene consultato |
| Attività | Commerciale | Tecnico |
|---|---|---|
| Raccogliere la specifica dal cliente | R + A | C |
| Valutare la fattibilità tecnica | I | R + A |
| Promettere una data al cliente | R + A | C |
| Eseguire il lavoro tecnico | I | R + A |
Questa tabella è la Regola 2 scritta in linguaggio RACI: nessuno promette (riga 3) senza che il tecnico sia stato Consultato — è la stessa regola, con il nome che usano i libri di management.
Scomporre un progetto — la WBS
La Work Breakdown Structure (WBS) è la tecnica per rendere gestibile qualunque progetto, grande o piccolo: si scompone il risultato finale in pezzi via via più piccoli, fino ad arrivare a compiti che una persona può stimare con precisione.
PROGETTO: Consegna documento tecnico al cliente
│
├── 1. Raccolta dati e specifica (chi, cosa, quando — Regola 1)
├── 2. Elaborazione tecnica (il lavoro vero e proprio)
├── 3. Controllo qualità interno (verifica prima della consegna)
└── 4. Consegna e presentazione al cliente
Un compito che non si riesce a stimare è un compito troppo grande:
va scomposto ancora, non stimato "a occhio".
Il motivo per cui una richiesta "fai questo per domani" spesso non regge: chi la fa non ha scomposto il lavoro in questi passi — ha stimato l'insieme "a sensazione". La scomposizione (anche solo mentale, 4 righe) è ciò che trasforma una sensazione in una stima affidabile.
Il percorso critico — perché un ritardo di due giorni ne causa dieci
Non tutte le attività di un progetto sono ugualmente urgenti. Alcune possono slittare senza conseguenze; altre, se slittano anche di un giorno, fanno slittare tutto il progetto. Queste ultime formano il percorso critico.
Attività A (2 giorni) ──► Attività C (3 giorni) ──► CONSEGNA
▲
Attività B (1 giorno) ───────────┘
Il percorso A→C dura 5 giorni: è il PERCORSO CRITICO.
Il percorso B dura 1 giorno: ha 4 giorni di margine (slack).
Un ritardo su B (fino a 4 giorni) non sposta la consegna.
Un ritardo di UN SOLO giorno su A o C sposta la consegna di un giorno.
Prima di dire "questa cosa è urgente, deve passare avanti a tutto" vale la pena chiedersi: è sul percorso critico, o ha margine? Trattare tutto come ugualmente urgente (quando non lo è) è uno dei modi più comuni per rallentare l'intero progetto invece di velocizzarlo.
Gestione del rischio in tre passi
| Passo | Domanda da farsi |
|---|---|
| 1. Identificare | Cosa potrebbe andare storto in questo progetto, prima ancora che inizi? |
| 2. Valutare | Quanto è probabile? Se succede, quanto costa (tempo, denaro, relazione col cliente)? |
| 3. Mitigare | Cosa si può fare ORA per ridurre probabilità o impatto, invece di scoprirlo a progetto avviato? |
"Un piano non è una previsione di ciò che accadrà. È una preparazione a ciò che potrebbe accadere." — principio di risk management, adattato da Peter Drucker
Primi principi e scomposizione — il metodo per i problemi davvero grossi
C'è un metodo, più antico di qualunque software, per affrontare un problema troppo grande per essere risolto tutto insieme: scomporlo nei suoi elementi verificabili, ignorare come "di solito si fa", e ricostruire la soluzione partendo solo da ciò che è vero per fisica, logica o dato — non per abitudine.
| Chi | Epoca | Cosa ha formalizzato |
|---|---|---|
| Cartesio | 1637, Discorso sul Metodo | "Dividere ciascuna delle difficoltà in tante parti quante possibili" prima di cercare la soluzione |
| Richard Feynman | XX secolo, fisica | Non fidarsi mai di ciò che "si dice sempre" — ricostruire ogni fenomeno dalle leggi fisiche di base, anche quando è più lento che copiare una formula nota |
| Taiichi Ohno | Toyota, anni '50 | I "5 Perché" — davanti a un difetto, chiedere "perché" cinque volte di seguito finché non si arriva alla causa reale, non al sintomo più visibile |
| Charlie Munger | investitore | "Invert, always invert" — capire un problema anche ragionando al contrario: non solo cosa lo risolve, ma cosa lo renderebbe impossibile da risolvere |
| Elon Musk | ingegneria/business | Invece di chiedere "quanto costa di solito una batteria", ha chiesto "quanto costano le materie prime fisiche che la compongono" — la differenza tra le due domande ha reso possibile Tesla |
Un sistema software complesso obbliga a definire con precisione dove finisce una parte e comincia l'altra (boundary, interfaccia), a isolare la causa reale di un malfunzionamento tra migliaia di componenti (debugging), e a scomporre un problema enorme in problemi piccoli che comunicano tra loro con regole chiare (architettura a moduli) — perché un sistema che non lo fa, semplicemente non funziona. Fisica, ingegneria e chirurgia insegnano lo stesso metodo — ma il software è una delle poche discipline in cui il sistema stesso, ogni giorno, costringe a farlo bene: se il confine tra due moduli non è definito con precisione assoluta, il programma si rompe subito, non dopo mesi.
| Passo del metodo | Applicazione a un problema aziendale complesso |
|---|---|
| Definire i confini (boundary) | Dove finisce esattamente questo problema? Cosa NON fa parte di questa richiesta? |
| Scomporre | Il problema grande si divide in problemi piccoli che si possono risolvere uno alla volta — è la stessa WBS di prima |
| Trovare la causa reale (root cause) | Il sintomo che si vede (una consegna in ritardo) quasi mai è la causa vera (una specifica mancante tre settimane prima) |
| Ripartire dai fatti fisici, non dalle abitudini | "Si è sempre fatto così" non è una verifica — è un'abitudine. Il tempo di un materiale a essiccare, la distanza di una nave, la disponibilità reale di una persona sono fatti |
Questo metodo non appartiene a una generazione né a una professione — appartiene a chiunque lo applichi con disciplina. Un mastro costruttore medievale che verificava la portata di una trave prima di caricarla, e un ingegnere informatico che verifica il confine tra due sistemi prima di collegarli, stanno facendo esattamente la stessa cosa: fidarsi dei fatti verificabili, non delle impressioni.
"Non basta fare del bene. Bisogna farlo bene." — San Francesco di Sales