Non ogni lavoro comincia con un compito già pronto.
A volte una persona arriva con un’attività che esiste da anni, materiali accumulati, clienti, un’idea che non ha ancora trovato forma oppure una situazione che semplicemente non vuole più continuare nello stesso modo.
Qualcosa funziona.
Qualcosa richiede troppa energia.
Qualcosa che dovrebbe essere possibile non lo è ancora.
In questi casi chiedere subito «che progetto facciamo?» può essere prematuro.
Prima viene una domanda più semplice:
che cosa dovrebbe diventare diverso?
Solo dopo possiamo capire che cosa fare e quale quantità di lavoro sia davvero necessaria.
Prima del progetto: che cosa deve cambiare?
È facile partire dallo strumento.
«Mi serve un nuovo sito.»
«Dobbiamo automatizzare.»
«Vorrei un’app.»
«Bisogna riorganizzare tutto.»
Sono richieste legittime, ma contengono già una soluzione.
La situazione che le ha generate può essere ancora poco definita.
Forse il sito non rende riconoscibile il valore del lavoro.
Forse il problema non è il sito, ma il tipo di persone che arrivano.
Forse l’automazione dovrebbe ridurre un carico che in realtà nasce dalle eccezioni e dalle decisioni, non dall’esecuzione.
Forse l’app è un modo immaginato per rendere accessibili materiali che oggi dipendono dalla presenza continua della persona.
Prima di stimare funzioni, pagine o ore, provo quindi a rendere visibile il cambiamento atteso.
Che cosa vuoi poter fare che oggi non riesci a fare?
Che cosa vuoi smettere di fare?
Che cosa dovrebbe diventare più semplice, più chiaro, meno dipendente da te?
Da quale segnale riconosceresti che la situazione è davvero cambiata?
Non serve arrivare con risposte perfette.
Il lavoro di chiarirle può far parte del progetto stesso.
Una soluzione deve stare nelle condizioni reali
Anche un obiettivo abbastanza chiaro non determina ancora la quantità di lavoro.
La domanda successiva è: che cosa è possibile sostenere adesso?
Non parlo soltanto di budget.
Ci sono tempo, energia, competenze, persone disponibili, materiali già pronti, obblighi che continuano mentre il progetto si sviluppa.
E c’è un tipo di risorsa che tende a essere dimenticato: ciò che servirà dopo.
Una soluzione può essere realizzabile una volta e troppo costosa da mantenere.
Si può costruire una grande biblioteca di contenuti e poi non avere il tempo di aggiornarla.
Si può automatizzare un processo e scoprire che la gestione delle eccezioni richiede una presenza continua.
Si può sviluppare un sistema complesso che funziona bene ma che nessuno vuole amministrare nel tempo.
Per questo «possiamo costruirlo?» non è sufficiente.
Serve anche chiedere:
possiamo usarlo, mantenerlo e voler continuare a sostenerlo dopo la fine del progetto?
Una soluzione proporzionata non è necessariamente la più piccola.
A volte il minimo non è sufficiente a produrre il cambiamento cercato e conviene investire di più — oppure non iniziare ancora.
Il punto è che la quantità di lavoro deve essere coerente con la funzione e con la realtà in cui quella soluzione dovrà vivere.
«Quanto basta» rispetto a che cosa?
La parola «minimo» crea facilmente un equivoco.
Può sembrare sinonimo di «più economico», «più semplice» o «fatto in fretta».
Non è questo che mi interessa.
Un intervento minimo ma sufficiente è un intervento che riesce già a svolgere la funzione scelta per questa fase, senza costruire tutto ciò che potrebbe diventare utile un giorno.
Se il bisogno attuale è rendere accessibile a un piccolo gruppo una raccolta di materiali già esistenti, forse non servono da subito livelli di accesso complessi, un’app dedicata, automazioni e decine di funzioni.
Ma questa scelta è sensata soltanto se la versione più semplice permette davvero alle persone di usare quei materiali nel modo necessario.
Se togliamo proprio ciò che dovrebbe produrre il cambiamento, non abbiamo costruito una soluzione minima.
Abbiamo costruito una soluzione insufficiente.
Per questo una domanda che uso spesso è:
che cosa stiamo scegliendo consapevolmente di non fare adesso — e perché?
La stessa domanda vale al contrario.
Perché questa funzione aggiuntiva serve già oggi?
Perché una limitazione della prima versione è diventata un ostacolo reale?
Perché è stata verificata una domanda che giustifica il livello successivo?
Oppure perché tecnicamente possiamo aggiungerla?
La possibilità tecnica non è, da sola, un criterio di priorità.
Risolvere un problema e verificare un’ipotesi sono due lavori diversi
Un primo passo piccolo può avere due scopi completamente diversi.
Può già produrre un cambiamento utile.
Oppure può servire soltanto a imparare se un’ipotesi importante è vera.
Immaginiamo un professionista con un’offerta complessa. Pensa che i potenziali clienti facciano fatica a capire il valore del suo lavoro.
Una strada è rifare tutto il sito.
Un’altra è verificare prima un’ipotesi più stretta: una spiegazione diversa rende l’offerta più comprensibile alle persone a cui è destinata?
Se testiamo due o tre formulazioni con una piccola audience pertinente e una viene compresa meglio, abbiamo ottenuto un’informazione utile.
Non abbiamo dimostrato che il nuovo sito porterà più clienti.
Abbiamo verificato una premessa.
Questo tipo di passo deve essere abbastanza solido da permettere una decisione successiva, ma non deve fingere di aver già prodotto il cambiamento finale.
Una soluzione limitata e un esperimento possono avere la stessa dimensione.
Non hanno la stessa funzione.
Il primo passo non deve essere una miniatura del progetto completo
Per questo un primo intervento sensato non è sempre il primo dieci per cento di una grande architettura futura.
A volte conviene costruire un solo tratto che funzioni davvero.
A volte bisogna prima ordinare i materiali per capire che cosa possano diventare.
A volte va verificato un collegamento da cui dipende il senso del resto.
A volte si risolve un problema circoscritto e solo dopo si vede se esiste davvero un secondo livello.
E a volte, una volta chiarita la situazione, la parte pratica può essere qualcosa che posso realizzare direttamente io.
Non parto però dalla promessa di costruire un sito, un’app o un’automazione.
La forma viene dopo il compito.
Quando il compito è abbastanza chiaro, possiamo definire che cosa viene realizzato, che cosa resta fuori, quale risultato ci aspettiamo e quando torneremo a valutarlo.
«Risultato» può voler dire quattro cose diverse
Dopo che qualcosa è stato realizzato, un’altra confusione diventa frequente: chiamiamo «risultato» cose che appartengono a livelli diversi.
Il primo livello è l’oggetto realizzato.
Il sito è online. I materiali sono organizzati. Il documento esiste. Il sistema funziona tecnicamente.
È un risultato reale: il lavoro concordato è stato eseguito.
Il secondo livello sono i segnali di movimento.
Le persone iniziano a usare ciò che è stato costruito. Alcuni errori diminuiscono. Un comportamento cambia. Compare un effetto intermedio atteso.
Il terzo livello è il cambiamento per cui il lavoro era iniziato.
Se l’obiettivo era rendere accessibili conoscenze senza la presenza continua della persona, ora sono davvero utilizzabili senza di lei?
Se l’obiettivo era ridurre la dipendenza dal titolare, il suo coinvolgimento è davvero diminuito?
Se l’obiettivo era rendere l’offerta più comprensibile, le persone pertinenti la capiscono meglio?
C’è poi un quarto livello: il costo del risultato quando comincia a vivere.
Quanto è difficile mantenerlo?
Richiede aggiornamenti continui?
Ha spostato il carico in un’altra parte del sistema?
È sostenibile senza creare un nuovo sovraccarico?
Non sempre questi livelli si misurano con un numero.
Ma è importante non confonderli.
Un oggetto consegnato non prova automaticamente il cambiamento atteso.
Un segnale positivo non prova ancora l’esito finale.
E un esito positivo non dice, da solo, se la soluzione resterà sostenibile.
E se la soluzione funziona davvero?
C’è una domanda che vale la pena fare prima di quanto sembri:
che cosa succede se funziona?
Non significa progettare ogni piccolo intervento per una crescita infinita.
Molte attività non vogliono diventare grandi, e va benissimo.
Ma se l’aumento di volume fa parte dell’intenzione, alcune conseguenze meritano di essere viste in anticipo.
Più utenti richiedono anche più supporto?
Più contenuti aumentano il valore o creano una biblioteca difficile da mantenere?
Più automazione riduce la presenza umana o la sposta nella supervisione?
Più clienti sono compatibili con il modo attuale di lavorare?
E soprattutto: la persona vuole davvero la vita che esiste dall’altra parte di quel successo?
Una possibilità di crescita non è un obbligo.
A volte conviene costruire qualcosa che funzioni bene alla scala desiderata e fermarsi lì.
A volte è utile non bloccare un’espansione futura, senza pagare oggi per tutta la complessità.
E a volte il volume futuro è parte essenziale del problema e deve entrare nel progetto dall’inizio.
Correggere il progetto non significa cambiare il criterio dopo
Quasi nessun lavoro procede esattamente come era stato immaginato.
Arrivano informazioni nuove. Un’ipotesi non regge. Una parte costa più del previsto. Una soluzione risulta meno utile.
Possiamo cambiare strada.
Ridurre o aumentare il perimetro.
Coinvolgere una competenza diversa.
Rimandare una parte.
Fermarci.
Possiamo anche cambiare l’obiettivo, se durante il lavoro la persona scopre che vuole davvero un’altra cosa.
Il problema nasce quando il criterio cambia senza essere nominato, soltanto per dichiarare riuscito ciò che abbiamo già fatto.
Se l’obiettivo era ridurre la presenza del titolare e il sistema è bello, usato e ricco di funzioni ma il suo coinvolgimento non è diminuito, possiamo riconoscere che il progetto ha creato un altro valore.
Ma non possiamo usarlo come prova che l’obiettivo iniziale sia stato raggiunto.
Se il criterio cambia, deve diventare una nuova decisione esplicita.
Altrimenti perdiamo il riferimento con cui valutare il lavoro.
A volte il risultato sufficiente è capire che non serve fare altro
C’è una conseguenza che fatica a entrare nella logica tradizionale del progetto:
un buon chiarimento non deve per forza produrre un progetto più grande.
Può emergere che lo strumento immaginato non serve.
Che il cambiamento richiederebbe risorse che la persona non vuole investire.
Che un piccolo test non conferma l’ipotesi su cui si basava l’intervento.
Che una modifica limitata è già sufficiente.
Oppure che il progetto potrebbe crescere tecnicamente, ma la vita necessaria per sostenerlo non è quella che la persona desidera.
Non è un fallimento.
Se la domanda iniziale era «che cosa vale davvero la pena fare?», una risposta come «per ora basta così» può essere estremamente pratica.
Per questo non è necessario arrivare con un incarico già formulato nei dettagli, una diagnosi o un progetto già scelto.
Si può arrivare con una situazione, un’idea, dei materiali, qualcosa che pesa troppo o qualcosa che non è ancora possibile fare.
Da lì si può chiarire che cosa deve cambiare, che cosa può influenzarlo, quale perimetro è sufficiente e come riconosceremo che è il momento di fermarsi.
Come lavoro: dal contesto all’azione →
Continua / nel sistema