Contesti diversi, problemi simili

In Jaewa ci occupiamo da anni di integrazione tra sistemi, reingegnerizzazione di software legacy, architetture distribuite e sviluppo di soluzioni su misura; lavoriamo con aziende strutturate, PMI, prodotti interni, piattaforme operative critiche ed ecosistemi in cui vari sistemi si sono sedimentati nel tempo: una varietà di contesti che rende necessario confrontare problemi simili visti da angolazioni diverse.

Dall’esperienza maturata in questa varietà emerge un dato ricorrente: i problemi software raramente nascono dal codice, ma molto più spesso da ambiguità non esplicitate, aspettative incompatibili tra le parti, responsabilità poco chiare e, soprattutto, da un rapporto sbagliato con l’incertezza.

Quando si interviene a sistema compromesso

Ci capita spesso di intervenire su situazioni già compromesse: sistemi legacy ingestibili, integrazioni fragili, roadmap bloccate o team esausti dopo mesi di pressione continua, in quei casi il nostro lavoro assomiglia a quello del pronto soccorso: prima si stabilizza il paziente, poi si ragiona sul percorso di evoluzione.

In quasi tutti questi scenari c’è una frattura implicita tra chi sviluppa il software e chi lo commissiona o lo governa. Da una parte ci sono i tecnici che vedono complessità, vincoli, dipendenze e debito tecnico, mentre dall’altra c’è chi conosce il dominio, gli obiettivi di business, le urgenze operative e  le aspettative di chi userà il sistema.

Quasi sempre hanno ragione tutti e due, e quasi sempre tutti e due sono frustrarti dalle circostanze.

Storie che si ripetono

Le storie che ascoltiamo tendono a ripetersi: rilasci notturni, escalation, scadenze impossibili e settimane spese a rincorrere problemi venuti fuori troppo tardi. Sono situazioni che vengono raccontate come se fossero inevitabili, come se la tensione permanente facesse parte del mestiere e il conflitto fosse il prezzo da pagare per “fare software seriamente”.

In certi ambienti diventa quasi un rito di passaggio: chi non ha vissuto notti di emergenza, requisiti cambiati all’ultimo minuto o trincee tra business e sviluppo non viene considerato “senior”.

Comuni, ma non inevitabili

La nostra esperienza ci porta a una conclusione diversa: questi scenari sono comuni ma non per questo virtuosi, e non sono inevitabili.

Sviluppare software non dovrebbe diventare una contrapposizione tra chi “paga” e chi “realizza”, e nemmeno un gioco a somma zero in cui una parte vince solo perché l’altra si carica pressione, rischio e ambiguità.

Un progetto sano funziona quando tecnici e committenza riescono a lavorare come una squadra, riconoscendo che hanno una convenienza concreta a farlo.

Perché conviene a entrambi

I tecnici lavorano meglio se hanno il tempo per capire il problema, se i trade-off vengono discussi apertamente, se le priorità sono chiare e se non sono costretti a scaricare ogni incertezza su straordinari o debito tecnico che nessuno vede.

Allo stesso modo, la committenza lavora meglio se percepisce trasparenza, se capisce cosa è rischioso e cosa no, se può prendere decisioni progressive e sente che il proprio investimento produce chiarezza ancora prima che funzionalità.

In un progetto davvero collaborativo nessuno ha la sensazione di doversi difendere dall’altro e anche se le discussioni non spariscono, cambiano natura: invece di servire a scaricare responsabilità diventano un modo per gestire vincoli e priorità.

Una necessità ingegneristica

Su questo punto vale la pena soffermarsi. La collaborazione nel software non è un tema esclusivamente culturale o etico, non si tratta di “essere gentili”, fare team building o aderire a qualche moda manageriale: è una necessità ingegneristica.

Nei progetti software complessi l’incertezza esiste comunque, le troviamo nei requisiti, nell’architettura, nelle integrazioni, nelle performance, nei processi organizzativi r nei comportamenti reali degli utenti. La scelta da fare è tra gestirla in modo esplicito o lasciarla emergere sotto forma di conflitto.

Quando un progetto finge che l’incertezza non esista, prima o poi qualcuno la assorbe in ritardo sotto forma di slittamenti, tensioni, costi imprevisti, qualità più bassa o burnout operativo.

Cosa significa fare squadra

Fare squadra, in questa cornice, ha un significato molto concreto: rendere espliciti i punti di ambiguità, discutere i rischi senza addolcirli, distinguere ciò che già sappiamo da ciò che ancora non sappiamo, e decidere passo dopo passo dove investire tempo, energia e budget.

Questo non vuol dire abolire ruoli o responsabilità, e nemmeno essere sempre d’accordo, ma piuttosto condividere un obiettivo: ridurre l’incertezza quanto basta a prendere decisioni migliori.

Prima si chiarisce, poi si investe

Da questa idea nasce il nostro approccio di Risk Aware Software Engineering.

Per noi l’ingegneria del software non si esaurisce nello scrivere codice ma deve anche servire a trasformare complessità implicita in complessità governabile: chiarire vincoli, mettere a fuoco i trade-off e distinguere ciò che è stabile da ciò che è ancora in esplorazione.

Per questo nei nostri progetti il livello di commitment cresce solo man mano che l’incertezza si riduce, in un percorso dove prima si chiarisce, poi si valida, poi si investe.

Non si tratta di mera “prudenza”, lo facciamo perché è il modo più efficace di costruire sistemi sostenibili senza ridurre ogni progetto a una guerra di attrito.

La tecnologia viene dopo

La tecnologia viene dopo le decisioni, la gestione del rischio e la capacità di affrontare la complessità senza farla degenerare in conflitto.

In questa logica la tecnologia diventa un punto di arrivo, invece che una premessa.

Scegliamo strumenti, linguaggi, architetture e pattern in funzione del contesto reale, dei vincoli, delle competenze già presenti, dei rischi specifici, e degli obiettivi di chi ci lavorerà ogni giorno.

Non esiste una tecnologia migliore in assoluto ma possiamo e dobbiamo scegliere quella più adatta a un determinato problema, in un determinato momento, con un determinato livello di incertezza residua.

Il senso della collaborazione

Per questo il nostro lavoro non si misura nelle righe di codice prodotte ma nella qualità delle decisioni che riusciamo a rendere possibili insieme alla committenza.

Quando tecnici e committenti smettono di fronteggiarsi e iniziano a condividere l’incertezza, il progetto cambia natura, trasformandosi da trattativa permanente a percorso comune.

Questo, per noi, è il senso della collaborazione nel software. Non un valore etico da esibire, ma una scelta ingegneristica che rende i progetti più sostenibili, più prevedibili e, alla fine, più riusciti per tutti.