Quando un progetto software enterprise viene avviato, la tentazione è pensare che il modo migliore per ridurre il rischio sia definire tutto prima di iniziare: requisiti, perimetro, tempi, responsabilità, criteri di accettazione e costi. È un obiettivo corretto e una buona fase di analisi resta indispensabile, ma nei progetti complessi esiste un limite oltre il quale la precisione iniziale diventa soltanto apparente. Alcune informazioni non sono ancora disponibili, altre dipendono da sistemi o fornitori terzi, altre ancora emergono soltanto quando utenti e ingegneri del software iniziano a confrontarsi con il funzionamento concreto della soluzione.
Questo non significa che il progetto debba procedere senza regole o che un perimetro poco definito sia accettabile. Significa, piuttosto, riconoscere che nessun contratto e nessun documento di analisi possono eliminare completamente l’incertezza. Tra ciò che è stato definito al giorno zero e ciò che accadrà nei mesi successivi esiste inevitabilmente uno spazio che deve essere governato. È proprio in quello spazio che la qualità del rapporto tra software house e azienda diventa determinante.
Per questo è più corretto parlare di partner. Il termine non è soltanto una scelta lessicale: descrive un modello nel quale entrambe le organizzazioni contribuiscono al risultato e nel quale trasparenza, tempestività, buona fede e capacità di trovare un equilibrio diventano parte del metodo di progetto. La fiducia non sostituisce il contratto, ma consente al contratto di funzionare senza trasformare ogni imprevisto in una negoziazione.
Un progetto complesso non può essere completamente descritto prima di iniziare
In un’applicazione enterprise possono convivere centinaia di regole di business, decine di integrazioni e processi costruiti in anni di operatività. Durante l’analisi è possibile ricostruirne una parte molto ampia, ma pretendere che ogni eccezione sia nota prima dello sviluppo può essere irrealistico. Spesso l’azienda stessa conosce perfettamente il proprio processo nella pratica, ma non lo ha mai dovuto formalizzare con il livello di precisione richiesto da un software.
Immaginiamo un progetto da 200.000 euro, pianificato su otto mesi, che debba integrare un nuovo portale B2B con ERP, CRM e sistema logistico. L’analisi può definire correttamente il flusso principale degli ordini, ma durante lo sviluppo può emergere che alcune categorie di clienti seguono regole di credito differenti, che un vecchio codice ERP viene ancora utilizzato per una procedura mensile o che un’informazione necessaria alla logistica non è disponibile attraverso le API previste. Non necessariamente qualcuno ha sbagliato: semplicemente il progetto ha portato alla luce una complessità che prima era nascosta.
In questi casi esistono due estremi ugualmente pericolosi. Il primo consiste nel considerare automaticamente qualsiasi elemento emerso in itinere come un extra da contabilizzare a parte; il secondo nel ritenere che qualsiasi esigenza necessaria al risultato finale fosse implicitamente compresa nel perimetro iniziale. Entrambi gli approcci spostano tutto il rischio su una sola parte e trasformano rapidamente una collaborazione tecnica in una discussione contrattuale.
Il tempo di risposta del partner è una variabile economica del progetto
Uno degli aspetti più sottovalutati riguarda i tempi con cui vengono prese le decisioni. Nei progetti software una risposta che arriva in ritardo non produce necessariamente un ritardo equivalente sul calendario. Può generare inefficienze molto maggiori, perché un team che non può proseguire deve cambiare attività, essere riallocato oppure procedere sulla base di assunzioni che dovranno successivamente essere verificate.
Supponiamo che quattro persone stiano lavorando su un modulo e che, per proseguire, serva una decisione dell’azienda su una regola commerciale. Se la risposta arriva in due giorni, il team può probabilmente organizzare altre attività e assorbire l’attesa. Se arriva dopo tre settimane, la situazione cambia: gli ingegneri possono essere stati spostati su altri task, il contesto deve essere ricostruito e alcune parti potrebbero essere state implementate sulla base di un’ipotesi provvisoria. Anche soltanto mezza giornata necessaria a ciascuna delle quattro persone per riprendere il contesto significa due giornate/uomo che non producono nuovo valore.
Se una dinamica simile si verifica dieci volte durante il progetto, il costo non è più marginale. Dieci decisioni che generano mediamente due giornate di inefficienza producono 20 giornate aggiuntive. Valorizzando una giornata tecnica a 700 euro, parliamo di 14.000 euro di effort che non dipende da una nuova funzionalità, ma dal modo in cui il progetto è stato governato. A questo possono aggiungersi rework, ripianificazione e slittamenti delle attività successive.
Il punto non è attribuire una colpa all’azienda partner. Le persone coinvolte nel progetto hanno spesso responsabilità operative, riunioni e priorità concorrenti. Proprio per questo, però, la disponibilità degli stakeholder e i tempi decisionali devono essere considerati risorse di progetto esattamente come le giornate degli sviluppatori.
La software house deve rendere facile decidere
La responsabilità della tempestività non può essere scaricata unilateralmente sull’azienda cliente. Se una software house invia una richiesta tecnica poco comprensibile, non chiarisce quale decisione sia necessaria e non spiega entro quando serva una risposta, difficilmente può limitarsi a registrare il ritardo come responsabilità del partner.
Una richiesta efficace dovrebbe rendere evidente il problema, le alternative possibili e le conseguenze della decisione. Invece di chiedere genericamente come debba funzionare una determinata integrazione, è molto più utile spiegare che sono possibili due comportamenti, indicare quello suggerito e chiarire che la scelta è necessaria entro venerdì perché dalla settimana successiva inizierà lo sviluppo del modulo dipendente. La competenza tecnica serve anche a ridurre il carico decisionale dell’azienda, non soltanto a produrre codice.
Lo stesso principio vale quando mancano dati, accessi o informazioni provenienti da terze parti. Segnalare tempestivamente una dipendenza, mantenerla visibile e quantificarne l’impatto consente al management di intervenire prima che diventi un problema. Dire dopo due mesi che una parte del progetto è in ritardo perché mancava un’informazione è molto diverso dal segnalare, fin dal primo giorno, che quella informazione si trova sul percorso critico e che oltre una certa data produrrà uno slittamento.
La buona fede serve soprattutto nella zona grigia
Nei progetti reali esiste quasi sempre una zona nella quale non è immediato stabilire se un’attività sia compresa nel perimetro oppure rappresenti una variazione. È qui che il principio di buona fede assume un significato molto concreto. Non ogni differenza rispetto all’analisi iniziale dovrebbe trasformarsi automaticamente in una change request, ma nemmeno una successione di modifiche può essere assorbita indefinitamente dalla software house.
Consideriamo un progetto stimato in 1.500 giornate. Durante lo sviluppo emerge una piccola modifica necessaria per rendere coerente un flusso, con un effort di due giornate. Aprire una trattativa economica può costare, in riunioni e attività amministrative, quasi quanto realizzare la modifica. Una software house che ragiona da partner può decidere di assorbirla. Se però nel corso dei mesi cinquanta modifiche da due giornate producono complessivamente 100 giornate aggiuntive, il fenomeno non è più marginale: equivale a oltre il 6% dell’effort originario e deve essere governato economicamente.
La reciprocità è essenziale. Se la software house dimostra elasticità sulle piccole variazioni, l’azienda deve essere disponibile a riconoscere quando una richiesta modifica realmente il perimetro. Se l’azienda risponde rapidamente a una criticità, la software house deve fare altrettanto quando emerge un problema tecnico. Nessuna delle due parti dovrebbe utilizzare ogni ambiguità per spostare sistematicamente sull’altra costi e responsabilità.
Il contratto deve proteggere la relazione, non sostituirla
Un contratto ben costruito rimane fondamentale. Deve definire perimetro, responsabilità, modalità di approvazione, gestione delle variazioni, milestone, criteri di accettazione ed eventuali meccanismi di escalation. Ma il contratto dovrebbe rappresentare la struttura entro cui il progetto viene governato, non lo strumento da consultare quotidianamente per stabilire chi abbia ragione.
Se per ogni decisione entrambe le parti devono verificare quale clausola consenta loro di trasferire il rischio sull’altra, il problema non è più soltanto contrattuale. Si è perso quel livello di fiducia che permette di affrontare rapidamente gli inevitabili imprevisti di un progetto complesso.
Un rapporto maturo consente alla software house di dire: questa attività non era prevista, ma richiede tre giornate e la assorbiamo noi. E consente, qualche settimana dopo, di dire con la stessa trasparenza: questa nuova esigenza modifica invece in modo sostanziale quanto definito, stimiamo 25 giornate e dobbiamo gestirla separatamente. La credibilità della seconda affermazione nasce anche dalla correttezza dimostrata nella prima.
La fiducia è un capitale che si costruisce durante il progetto
La fiducia può sembrare un concetto difficile da associare a KPI, budget e pianificazione, ma nei progetti software produce effetti estremamente concreti. Ogni comportamento può aumentare o ridurre quello che potremmo definire capitale di fiducia tra i partner.
Una software house che segnala immediatamente un proprio errore invece di cercare di nasconderlo accumula fiducia. Un’azienda che riconosce senza discussioni una variazione sostanziale del perimetro fa lo stesso. Assorbire una piccola attività imprevista, rispettare una data promessa, fornire rapidamente un accesso critico o comunicare con anticipo che una milestone è a rischio sono comportamenti che rendono più semplice la decisione successiva.
Il contrario accade quando ogni stima viene percepita come un tentativo di aumentare il budget, ogni richiesta del partner come scope creep e ogni problema come un’occasione per individuare un responsabile. In quel contesto aumentano controlli, riunioni, formalizzazioni e tempi di approvazione. Paradossalmente, nel tentativo di proteggersi da qualche giornata di effort, entrambe le parti possono creare decine di giornate di inefficienza.
Anche la governance deve essere progettata
La collaborazione non può dipendere soltanto dalla buona volontà delle persone. Nei progetti importanti è utile definire fin dall’inizio chi possa prendere quali decisioni, con quali tempi e attraverso quali canali. Una richiesta bloccata per quindici giorni perché nessuno sa chi debba approvarla è un problema di governance prima ancora che di disponibilità.
Per un progetto di otto mesi può essere ragionevole, per esempio, avere un referente operativo in grado di rispondere alle questioni quotidiane, un responsabile business per le decisioni funzionali rilevanti e uno steering periodico per gli elementi che incidono su budget o perimetro. Non serve burocratizzare il progetto: serve evitare che una domanda da trenta minuti rimanga aperta tre settimane perché percorre una catena decisionale non definita.
Anche le decisioni dovrebbero lasciare una traccia sufficiente. Non occorrono verbali di dieci pagine per ogni riunione, ma è importante poter ricostruire cosa sia stato deciso, da chi e sulla base di quali informazioni. Questo protegge entrambi i partner e riduce il rischio che, mesi dopo, una scelta venga riletta con un contesto completamente diverso.
L’obiettivo non è eliminare l’incertezza, ma governarla insieme
Un progetto software enterprise non diventa prevedibile perché ogni possibile evento è stato scritto in anticipo. Diventa governabile quando esiste un metodo per affrontare rapidamente ciò che non era prevedibile. Analisi, contratto, pianificazione e governance servono proprio a ridurre l’incertezza e a renderla visibile; fiducia e collaborazione servono a gestire quella parte che inevitabilmente rimane.
Questo richiede equilibrio. La software house deve essere trasparente su effort, rischi ed errori e non utilizzare ogni ambiguità per aumentare il valore del progetto. L’azienda partner deve garantire disponibilità, decisioni tempestive e riconoscere quando una nuova esigenza produce realmente lavoro aggiuntivo. Entrambe devono poter discutere un problema con l’obiettivo di risolverlo, non di costruire preventivamente la posizione migliore per una futura contestazione.
Quando questo equilibrio esiste, anche i problemi diventano più economici da risolvere. Le decisioni vengono prese prima, il team mantiene continuità, il rework diminuisce e le variazioni sostanziali vengono riconosciute senza trasformarsi in conflitti. Il risultato non è soltanto un rapporto migliore: è un progetto più efficiente e, molto spesso, un software migliore.
Il modo in cui lab51 interpreta il rapporto con i propri partner
In lab51 consideriamo l’analisi iniziale, la chiarezza del perimetro e la trasparenza economica elementi indispensabili di un progetto, ma sappiamo anche che nei contesti enterprise non tutto può essere previsto al giorno zero. Per questo cerchiamo di costruire con le aziende un rapporto da partner, nel quale le criticità vengano rese visibili quando emergono, le decisioni siano supportate da informazioni comprensibili e le variazioni vengano valutate con equilibrio.
Il nostro obiettivo non è spostare il rischio sul cliente né assorbire indiscriminatamente qualsiasi cambiamento, ma creare le condizioni perché il progetto possa essere governato secondo principi di collaborazione, buona fede e responsabilità reciproca. Questo significa anche aiutare il partner a organizzare la governance, identificare le decisioni critiche e comprendere l’impatto che tempi di risposta, dipendenze e variazioni possono avere su budget e pianificazione.
Se stai affrontando un progetto software complesso, oppure un’iniziativa nella quale requisiti, integrazioni e processi non possono essere definiti completamente prima di iniziare, lab51 può affiancarti non soltanto nello sviluppo della soluzione, ma nella costruzione di un modello di lavoro che mantenga allineati obiettivi, responsabilità e sostenibilità economica durante tutto il percorso.
