Quando l’ottimismo diventa una promessa

Dalla serie

Obiettivo

Rispondere a tempi, costi o risultati irrealistici con livelli di confidenza, scenari, dipendenze e opzioni verificabili invece di opposizione sterile o falsa rassicurazione.

Pratica: spostare la conversazione da “si può fare?” a “a quali condizioni si può credere?”

«Dobbiamo andare live entro fine mese». La data è già stata comunicata, il testGlossarioTestUna verifica deliberata che produce evidenze su una specifica aspettativa o rischio.Apri la voce completa dei volumi non è concluso e una dipendenza critica è ancora aperta. Quando un interlocutore propone una scadenza o un risultato troppo ottimistico, il compito del Solution Architect non è dire subito no. È rendere visibili le condizioni che devono essere vere perché quell’impegno sia credibile. La mossa pratica è costruire pochi scenari, non una stima unica presentata come certezza. Per esempio: scenarioGlossarioScenarioUna situazione concreta usata per testare come un design o una decisione si comporta.Apri la voce completa probabile, scenario accelerato e scenario prudente. Per ciascuno chiarisci tre elementi: livello di confidenza, dipendenze critiche e leve decisionali. Questo cambia la qualità della discussione. Invece di difendere una posizione, aiuti il gruppo a decidere quale rischio accettare: ridurre scope, aggiungere capacità, anticipare una decisione, rinviare una data o accettare più incertezza. La risposta diventa verificabile e quindi utile. • Rendi esplicite le assunzioni, non solo il risultato atteso. • Usa livelli di confidenza semplici: alto, medio, basso. • Accompagna ogni livello di confidenza con le assunzioni che lo giustificano e gli eventi che potrebbero modificarlo. • Collega ogni promessa a dipendenze concrete e a una leva di mitigazione.

Trade-off: proteggere l’ambizione senza vendere certezze che non esistono

Ragionare per scenari ha un vantaggio importante: preserva l’ambizione e rende più robusta la decisione. Però richiede disciplina, perché toglie spazio alle risposte comode. Il guadagno è una conversazione più onesta e gestibile: il business comprende quale combinazione di risultato, rischio e condizioni sta approvando, il delivery capisce dove il piano è fragile e l’architettura resta allineata a vincoli reali. Il costo è che la discussione diventa meno veloce e, a volte, meno “confortevole”. Alcuni stakeholderGlossarioStakeholderUna persona o un gruppo che influenza una decisione o ne sperimenta gli effetti.Apri la voce completa preferiscono una data netta a una stima con confidenza. Ma una data netta non elimina il rischio: spesso lo nasconde. Il vero trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa, quindi, è tra apparente semplicità e decisione informata. Se l’obiettivo è evitare sorprese, la seconda opzione è quasi sempre migliore. • Più trasparenza significa meno illusioni, ma anche meno ambiguità. • Una promessa troppo precisa può accelerare l’allineamento iniziale e rallentare il recupero successivo. • Ridurre scope o aumentare capacità sono leve reali; fingere certezza non lo è.

Esempio enterprise: una migrazione con una data già annunciata

In un programma di migrazione verso una nuova piattaforma, il business chiede di mantenere una data già comunicata ai clienti interni. L’aspettativa implicita è: stessa data, stesso perimetro, stesso livello di qualità. Il Solution Architect può rispondere con tre scenari: - Scenario probabile: migrazione completa entro la data, ma con confidenza media e con una dipendenza critica ancora aperta sul test dei volumi. - Scenario accelerato: data confermata solo se si rinuncia ad alcune funzionalità non essenziali e si aggiunge capacità al team di integrazione. - Scenario prudente: stessa qualità e stesso perimetro, ma con spostamento della data di rilascio. La discussione cambia tono perché non è più “sei d’accordo o no?”. È “quale combinazione di scope, rischio e data vogliamo accettare?”. In molte organizzazioni questa è la differenza tra un piano che sembra forte al comitato e un piano che regge davvero in esecuzione. • Azienda con più team e dipendenze tra piattaforme legacy e cloud. • Roadmap già condivisa con stakeholder non tecnici. • Pressione a mantenere la promessa anche quando una dipendenza critica è ancora incerta.

Per approfondire

Fonti esterne autorevoli per approfondire il tema della comunicazione dell’incertezza e delle decisioni architetturali. • Architecture Decision Records - Michael Nygard - https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions • How to Measure Anything: Finding the Value of "Intangibles" in Business - Douglas W. Hubbard - https://www.wiley.com/en-us/How+to+Measure+Anything%3A+Finding+the+Value+of+%22Intangibles%22+in+Business%2C+3rd+Edition-p-9781118539279