Metodo
Prima capire.Poi decidere cosa costruire.
Non parto dallo strumento, dalla tecnologia o dalla soluzione che pensi di dover acquistare.
Parto dall'obiettivo, dal problema e dal contesto nel quale dobbiamo intervenire. Ascolto, faccio domande, cerco connessioni, incongruenze e dettagli che possono sembrare secondari ma che spesso aiutano a capire dove si trova realmente il problema.
Una prima intuizione può arrivare molto rapidamente. Ma un'intuizione non diventa una decisione finché non abbiamo elementi sufficienti per sostenerla.
Le domande non servono solo a raccogliere informazioni. Servono a capire dove vale la pena guardare.
Cerco il problema reale, anche quando è scomodo
La richiesta iniziale è un punto di partenza, non necessariamente la diagnosi.
Un problema può dipendere da una tecnologia sbagliata, da un processo inefficiente, da un fornitore, da un'organizzazione non adeguata oppure anche da una risorsa interna che sta compromettendo una parte del lavoro. Se vedo una criticità preferisco portarla apertamente sul tavolo.
Non cerco un colpevole e nemmeno una conferma per imporre una conclusione. Spiego ciò che vedo, perché ritengo possa essere un problema e quale impatto potrebbe avere. Poi lo analizziamo insieme.
Una consulenza perde valore quando evita le questioni scomode.
Scelgo pensando anche a quello che verrà dopo
Una soluzione deve funzionare oggi senza diventare il problema di domani. Quando valuto una tecnologia, una piattaforma o un'architettura considero il rapporto tra investimento e benefici, ma guardo anche più avanti.
Non cerco necessariamente la tecnologia più nuova. Cerco quella che offre una prospettiva credibile di affidabilità, supporto ed evoluzione.
- Affidabiledeve funzionare stabilmente.
- Manutenibiledeve poter continuare a essere aggiornata e gestita.
- Evolutivatecnologie e necessità cambiano.
- Scalabilel'azienda deve poter crescere senza essere costretta a ricominciare da zero.
- Economicamente sostenibilela complessità deve essere proporzionata al valore prodotto.
Scalabilità non significa sovradimensionare oggi. Significa non chiudere le porte a domani.
Evito dipendenze inutili
Quando esistono alternative valide, preferisco sistemi aperti, integrabili e gestibili anche da professionisti diversi dalle persone che li hanno costruiti.
Un ecosistema chiuso può in alcuni casi essere la scelta migliore. Ma il lock-in deve essere una decisione consapevole e giustificata dal valore che produce, non una conseguenza nascosta del progetto.
Dati, integrazioni, architettura e conoscenze dovrebbero poter essere trasferiti senza rendere ogni cambiamento futuro sproporzionatamente complesso. Per questo considero la documentazione una parte reale del lavoro.
Un sistema che funziona soltanto finché è presente chi lo ha costruito è un sistema fragile.
Una direzione chiara. Un percorso adattivo
Definire un progetto non significa pretendere che la realtà segua esattamente il piano iniziale. Durante l'esecuzione possono cambiare priorità, persone, tecnologie e informazioni disponibili.
Può essere necessario anticipare una fase, rimandarne un'altra, tornare su una scelta già fatta oppure modificare parte dell'architettura. Per questo il lavoro non è rigido.
Mantengo chiaro l'obiettivo, verifico progressivamente ciò che stiamo costruendo e adatto il percorso quando emergono elementi che lo richiedono.
Il metodo deve dare struttura al progetto, non impedire al progetto di adattarsi alla realtà.
Autonomia nel lavoro. Trasparenza nelle decisioni
Prima di iniziare definiamo obiettivi, perimetro, responsabilità e modalità operative. All'interno di ciò che abbiamo concordato ho bisogno dell'autonomia necessaria per portare avanti il lavoro e prendere le decisioni operative senza introdurre rallentamenti continui.
Questo non significa lavorare in isolamento. Mantengo una comunicazione diretta con il cliente e condivido apertamente il confronto con chi ha la responsabilità strategica dell'azienda.
Posso lavorare autonomamente con responsabilità, team interni, tecnici e fornitori, ma nei progetti importanti mantengo sempre un accesso diretto a chi può prendere le decisioni finali.
Il cliente non deve gestire il mio lavoro, ma deve sempre sapere dove stiamo andando e perché.
Costruire, far utilizzare, verificare
Una soluzione non è completa soltanto perché tecnicamente funziona. Quando il progetto introduce nuovi strumenti, processi, automazioni o modalità di lavoro, il mio perimetro può includere prove, messa a punto, formazione, documentazione, coinvolgimento delle persone e accompagnamento all'adozione.
L'obiettivo non è soltanto consegnare qualcosa che funziona, ma mettere l'azienda nelle condizioni di utilizzarlo correttamente e con continuità.
La stessa logica vale per la verifica. Prima della messa in produzione definisco i test necessari in funzione del progetto. Non utilizzo una checklist identica per qualsiasi situazione: funzionalità, integrazioni, dati, prestazioni, processi e modalità di verifica cambiano in base a ciò che stiamo costruendo.
Quando possibile il cliente viene coinvolto già nelle fasi di test, così può utilizzare e verificare quanto realizzato prima del rilascio definitivo.
Il cliente non dovrebbe vedere il risultato per la prima volta il giorno della consegna.
Il metodo
Un metodo strutturato. Soluzioni costruite sulla realtà.
Non applico la stessa risposta a problemi diversi.
Cerco di comprendere ciò che serve, costruire la soluzione più adatta, verificarla sul campo e lasciare all'azienda qualcosa che possa funzionare, crescere ed evolvere nel tempo.
Parliamo del progetto