Cosa faccio adesso? Pianificare le modifiche progettuali

Molto spesso mi trovo a parlare con le persone delle loro progettazioni, dei loro piani e delle loro architetture di sistema. E molte volte quella discussione avviene troppo tardi, quando i progetti sono già stati implementati o lo sono in parte. Questo può essere molto frustrante se il progetto in corso è stato ritenuto non ideale per la situazione.

Comprendo la sensazione di frustrazione che deriva da una situazione del genere, ma è qualcosa che noi dell'IT dobbiamo affrontare molto regolarmente, e gestire questa reazione in modo costruttivo è una competenza IT fondamentale. Dobbiamo diventare maestri di questa situazione sia dal punto di vista tecnico sia da quello emotivo. Non dovremmo lasciarci paralizzare da essa: è una situazione naturale che ogni professionista IT vivrà regolarmente. Non dovrebbe essere scoraggiante o paralizzante, ma è del tutto comprensibile che possa sembrare tale.

Una ragione chiave per cui lo sperimentiamo così spesso è che l'IT è un campo enorme, con un gran numero di variabili da considerare in ogni situazione. È anche un campo altamente creativo, in cui possono esistere numerosi approcci validi a qualsiasi problema dato. Che esista persino una singola opzione “migliore” è raramente vero. Normalmente esistono molte opzioni in concorrenza tra loro. A volte sono molto simili tra loro, a volte queste opzioni sono drasticamente diverse, rendendole molto difficili da confrontare in modo significativo.

Un'altra ragione chiave è che i fattori cambiano. Può accadere che emergano nuove tecniche o nuove informazioni, che vengano rilasciati nuovi prodotti, che i prodotti vengano aggiornati, che i prezzi cambino o che le esigenze aziendali cambino in prossimità o addirittura durante i processi decisionali e progettuali. Questo ritmo di cambiamento non è qualcosa che noi, come professionisti IT, possiamo sperare di controllare. È qualcosa che dobbiamo accettare e gestire nel miglior modo possibile.

Un'altra cosa che vedo spesso trascurata è che una soluzione che era ideale quando è stata realizzata potrebbe non esserlo se la stessa decisione venisse presa oggi. Questo non costituisce in alcun modo una carenza del progetto originale, eppure ho visto molte persone reagire come se lo fosse. Lo scenario più comune in cui vedo le persone manifestare questo comportamento è l'avversione all'uso del RAID 5 nella progettazione di storage moderna, con RAID 6 e RAID 10 che, per buone ragioni, sono le alternative più diffuse. Ma questa avversione al RAID 5, comune da circa il 2009, non è sempre esistita e, dalla metà degli anni '90 fino quasi alla fine degli anni 2000, il RAID 5 non era solo praticabile, ma era molto spesso la soluzione migliore per le esigenze aziendali e tecniche del caso (l'aumento dell'avversione nei suoi confronti è stato per lo più graduale, non improvviso). Tuttavia, molte persone considerano il RAID 5 comprensibilmente scarso come opzione oggi, ma applicano questa nuova avversione a sistemi progettati e implementati molto tempo fa, talvolta quasi due decenni fa. Questo non ha alcun senso ed è una reazione puramente emotiva. Il fatto che il RAID 5 fosse la scelta migliore per uno scenario nel 2002 non implica in alcun modo che sarà ancora la scelta migliore nel 2015. Ma allo stesso modo, il fatto che il RAID 5 sia una scelta scadente nel 2015 per uno scenario non sminuisce né nega in alcun modo il fatto che fosse molto spesso un'ottima scelta diversi anni fa.

Mi è stato chiesto molte volte cosa fare una volta che sono state prese decisioni progettuali non ideali. “Cosa faccio adesso?”

Imparare cosa fare quando la perfezione non è più un'opzione (ammesso che lo sia mai stata davvero: tutto l'IT è fatto di compromessi) è una competenza molto importante. Le prime cose che dobbiamo affrontare sono i problemi emotivi, perché questi mineranno tutto il resto. Dobbiamo fare del nostro meglio per fare un passo indietro, accettare la situazione e agire razionalmente. L'ultima cosa che vogliamo fare è prendere una situazione non ideale e peggiorare le cose tentando di giustificare a posteriori decisioni sbagliate o lasciandoci prendere dal panico.

Accettare che nessun progetto è perfetto, che non c'è modo di fare sempre le cose completamente nel modo giusto e che affrontare tutto questo fa semplicemente parte del lavoro nell'IT è il primo passo. Fai un passo indietro, respira profondamente. Non è così grave. Non è una situazione unica. Ogni professionista IT che si occupa di progettazione vi passa continuamente. Dovresti fare del tuo meglio per prendere le migliori decisioni possibili, ma devi anche accettare che ciò raramente si può fare: nessuno ha accesso a risorse sufficienti per riuscirci davvero. Lavoriamo con ciò che abbiamo. Quindi eccoci qui. E adesso?

Il passo successivo è valutare la situazione. A che punto siamo ora? In molti casi l'implementazione è terminata e non c'è altro da fare. La situazione non è ideale, ma è grave? Molto spesso il più grande errore che vedo affrontare alle persone di fronte a un progetto già implementato è che è troppo costoso: tipicamente le soluzioni “migliori” non sono migliori perché più veloci o più affidabili, ma sono migliori perché più economiche, più semplici o più rapide da implementare. È una situazione sfortunata, ma difficilmente paralizzante. Qualunque tempo o denaro sia stato speso deve essere stato un importo accettabile all'epoca e deve essere stato approvato. Il meglio che possiamo fare, in questo momento, è imparare dal processo decisionale e cercare di evitare la spesa eccessiva in futuro. Ciò non significa che la soluzione esistente non funzionerà o addirittura non funzionerà benissimo. È semplicemente che potrebbe non essere stata una scelta perfetta date le esigenze aziendali, principalmente finanziarie, in gioco.

Ci sono situazioni in cui un progetto che è stato implementato non soddisfa adeguatamente i requisiti aziendali dichiarati. Per fortuna questo è meno comune, nella mia esperienza, perché è una situazione molto più difficile. In questo caso dobbiamo apportare alcune modifiche per soddisfare le nostre esigenze aziendali. Ciò può rivelarsi costoso o complesso. Ma le cose potrebbero non essere così gravi come sembrano. Spesso le reazioni a questo sono fuorvianti e la situazione può spesso essere recuperata.

Il primo passo, una volta che ci troviamo in una posizione in cui abbiamo implementato una soluzione che non soddisfa le esigenze aziendali, è rivalutare le esigenze aziendali. Questo non vuol dire che dovremmo manipolare le esigenze per piegarle a ciò che il nostro sistema è in grado di soddisfare, niente affatto. Ma è un buon momento per tornare indietro e verificare se le esigenze dichiarate in origine sono davvero valide o se semplicemente non sono state esaminate abbastanza a fondo o, cosa ancora più probabile, per verificare se le esigenze aziendali sono cambiate nel periodo in cui ha avuto luogo l'implementazione. Potrebbe darsi che la soluzione implementata soddisfi, di fatto, le effettive esigenze aziendali, anche se in origine erano state formulate in modo errato o perché le esigenze sono cambiate nel tempo. Oppure potrebbe darsi che le esigenze aziendali siano cambiate in modo così drastico che persino una pianificazione perfetta sarebbe stata originariamente inadeguata rispetto alle esigenze attuali, e il fatto che la soluzione implementata non funzioni come previsto è di scarsa rilevanza. Sono rimasto molto sorpreso da quanto spesso questa verifica delle esigenze aziendali abbia trasformato una soluzione ritenuta inadeguata in una soluzione “sovradimensionata” che in realtà è costata più del necessario semplicemente perché nessuno aveva contestato le sopravvalutazioni delle esigenze aziendali o nessuno aveva messo in discussione il valore economico di determinati investimenti tecnologici.

Il secondo passo è creare una nuova baseline tecnologica. Questo è un passo molto importante per contribuire a evitare che l'IT cada nella trappola della fallacia dei costi sommersi. È estremamente comune per chiunque, e questo non è affatto esclusivo dell'IT, guardare al tempo e al denaro spesi su un progetto e presumere che continuare lungo il percorso originale, per quanto sciocco sia, sia la strada da seguire perché su quel percorso sono già state spese così tante risorse. Ma questo non ha alcun senso, ovviamente: come sei arrivato al tuo stato attuale è irrilevante. Ciò che è rilevante è valutare le esigenze attuali del reparto e dell'azienda e fare il punto sulle soluzioni, le tecnologie e le risorse attualmente disponibili. Dato lo stato attuale, è possibile determinare la migliore strada da percorrere. Qualsiasi considerazione data allo sforzo impiegato per arrivare allo stato attuale è solo fuorviante.

Un buon esempio della fallacia dei costi sommersi è nel gioco degli scacchi. A ogni mossa è importante valutare di nuovo tutte le mosse, i rischi e le strategie disponibili, perché le mosse usate per arrivare allo stato attuale non hanno alcuna influenza su quali mosse abbiano senso d'ora in avanti. Se il più grande giocatore di scacchi del mondo o uno straordinario algoritmo scacchistico al computer venisse chiamato a metà partita, non avrebbe bisogno di alcuna conoscenza su come si fosse arrivati allo stato attuale: si limiterebbe a valutare lo stato attuale e a creare una strategia basata su di esso.

Questo è lo stesso modo in cui dovremmo comportarci nell'IT. Il nostro stato attuale è il nostro stato attuale. Ai fini della pianificazione strategica non importa ciò che si è svolto per portarci a quello stato. Quelle decisioni e quei costi ci interessano solo quando svolgiamo un processo di analisi a posteriori per determinare dove possa aver fallito il processo decisionale, al fine di imparare da esso. Imparare su noi stessi e sui nostri processi è molto importante. Ma questo è un compito molto diverso dal fare pianificazione strategica per l'iniziativa attuale.

La cosa sfortunata, qui, è che dobbiamo ricominciare i nostri processi di pianificazione, ma questa volta con, presumiamo, più elementi su cui lavorare. Ma questo non può essere evitato. Nei casi peggiori, i budget non sono più disponibili e non ci sono risorse per correggere il progetto difettoso e raggiungere gli obiettivi aziendali necessari. A volte i compromessi sono necessari. Arrangiarsi con ciò che abbiamo è a volte il meglio che possiamo fare. Ma, nella stragrande maggioranza dei casi a quanto pare, una qualche combinazione di budget aggiuntivo o di riutilizzo creativo dei prodotti esistenti può essere adeguata a rimediare alla situazione.

Una volta raggiunto uno stato in cui abbiamo affrontato le nostre carenze, sia semplicemente accettando di aver speso troppo o reso troppo poco, sia adattandoci per soddisfare le esigenze, abbiamo l'opportunità di tornare indietro e indagare sui nostri processi decisionali. È facendo questo che speriamo di crescere come individui e, se possibile, a livello organizzativo, di imparare dai nostri errori, o di determinare se ci siano stati davvero degli errori. Ogni azienda e ogni individuo commette errori. Ciò che ci distingue è la capacità di imparare da essi ed evitare gli stessi errori in futuro. La crescita deriva principalmente dallo sperimentare il dolore in questo modo e, sebbene spesso sgradevole da affrontare, è qui che abbiamo la migliore opportunità di creare valore reale e duraturo. Non rinviare né saltare questa opportunità di revisione, che si tratti di una revisione dura e personale che svolgi tu stesso o di una revisione formale e organizzativa condotta da persone addestrate a farlo, o di qualcosa di intermedio. Prima vengono valutati i processi decisionali, più fresca sarà la memoria e prima potrà entrare in vigore la correzione di rotta.

Il passo finale che possiamo compiere è avviare il processo decisionale per progettare una sostituzione dell'implementazione attuale il prima possibile, una volta completata la revisione del processo decisionale. Questo non significa necessariamente che dovremmo avere intenzione di spendere denaro o modificare i nostri progetti nel prossimo futuro. Niente affatto. Ma essendo estremamente proattivi nel prendere decisioni progettuali, possiamo tentare di evitare i problemi del passato concedendoci più tempo per la pianificazione, più tempo per la raccolta dei requisiti e la documentazione, una migliore comprensione dei cambiamenti dei requisiti nel tempo, rivisitando regolarmente quei requisiti per vedere se rimangono stabili o se stanno cambiando, maggiori opportunità di ottenere il consenso e l'impegno del management e dei colleghi nella decisione, e una migliore comprensione del dominio del problema, così da essere meglio attrezzati per modificare il progetto previsto o per sapere quando scartarlo e ricominciare prima di implementarlo la volta successiva. Potrebbe anche, potenzialmente, darci una migliore possibilità di codificare la conoscenza organizzativa che potrebbe essere trasmessa a un successore, qualora tu stesso non fossi nella posizione di prendere decisioni o effettuare l'implementazione quando arriverà il ciclo successivo.

Con processi validi e razionali e una buona comprensione dei passi che devono essere compiuti in un caso di progettazione o implementazione di sistemi non ideale, possiamo riprenderci dai passi falsi e non solo, nella maggior parte dei casi, riprenderci da essi nel breve termine, ma possiamo anche proteggere l'organizzazione dagli stessi errori in futuro.