Esplorare l’ignoto nello sviluppo software: tra reverse engineering e requisiti mancanti

Spesso ci troviamo a lavorare su un progetto dove molti requisiti fondamentali non erano documentati da nessuna parte. Questa situazione mi ha portato a riflettere su quanto sia difficile sviluppare in modo efficace senza una base solida di informazioni e su come questa difficoltà si ripercuota sul lavoro e sulle relazioni professionali.

Un aspetto particolarmente frustrante è la percezione che si crea attorno a questa situazione. Per chi arriva “dall’esterno” è facile essere accusati di “perdersi pezzi”, quando il vero problema è che non si sa quali domande porre per colmare le lacune. D’altro canto, chi detiene il know-how potrebbe non rendersi conto della difficoltà di ricostruire informazioni che non sono mai state formalizzate. A volte, chi ha queste informazioni è persino restio a condividerle, vuoi per mancanza di tempo, vuoi per il timore di esporsi a un problema di cui preferirebbe non occuparsi.

Nonostante gli sforzi per ricostruire quanto possibile, capita spesso di scoprire in corso d’opera dettagli fondamentali. Queste scoperte, però, spesso finiscono per irritare le persone da cui si dipende per sviluppare il progetto, creando tensioni. Tuttavia, queste persone, non per colpa loro, a volte non considerano che chi conduce l’analisi sta già compiendo uno sforzo notevole nel reverse engineering, assumendosi rischi e responsabilità significative in caso la loro analisi si rivelerà anche parzialmente errata. Non si tratta sempre di “perdersi pezzi”, ma spesso di non sapere che quei pezzi esistono: senza questa consapevolezza, è impossibile formulare le giuste domande per ottenere informazioni.

Sviluppo, ultima frontiera

In qualche modo, questa dinamica mi ricorda la missione quinquennale di James Kirk sulla USS Enterprise di Star Trek, l'esplorazione dell'ignoto in una missione di 5 anni, con l'obiettivo di "arrivare là dove nessuno è mai giunto prima". Kirk e Spock affrontavano pericoli imprevisti e situazioni complesse senza preparazione, ma riuscivano sempre a trovare una soluzione. Certo, non si lamentavano con la Flotta Stellare per averli mandati allo sbaraglio (McCoy, probabilmente sì), bensì analizzavano tutti i nuovi elementi scoperti sul campo, rivalutavano la situazione e adattavano il loro piano d'azione per l'unico scopo che contava: salvare la nave e l'equipaggio. E ci riuscivano, ogni settimana.

A volte può andarti bene, come nell’episodio “The Trouble with Tribbles” (Animaletti pericolosi): l’Enterprise si trova a gestire un problema imprevisto – i triboli – che inizialmente sembrano innocui, ma poi si rivelano una minaccia. Nonostante l’imprevisto, l’equipaggio lavora insieme, e grazie all’ingegno di Kirk e Spock riesce a trasformare una situazione difficile in una vittoria, persino ottenendo un vantaggio politico nei confronti dei Klingon.

Altre volte può andare male, come nell’episodio “The Doomsday Machine” (La macchina del giudizio universale): Kirk e l’equipaggio incontrano un’arma planetaria fuori controllo. L’assenza di preparazione porta a sacrifici e perdite significative prima di riuscire a fermarla: il Commodoro Decker prima perde il suo equipaggio, poi perde la sua stessa vita, infine da un'opportunità a Kirk di usare la sua nave, la USS Constellation, per distruggere la macchina del giudizio universale. E nonostante nel frattempo abbia quasi fatto distruggere l'Enterprise per eliminare il temibile nemico, Kirk gli riserva una nota di encomio postuma per il suo sacrificio.

Proprio come Kirk e Spock, chi lavora in condizioni di incertezza può non essere preparato a tutto ciò che troverà nell’ignoto, ma deve comunque trovare soluzioni creative. E alla fine, così come l’equipaggio dell’Enterprise non dà mai la colpa ai propri ufficiali di comando, o alla Flotta Stellare, per averli mandati in una missione in cui rischieranno la vita, anche chi affronta progetti con requisiti incerti o scoperti in corso d'opera bilanciare adattamento e proattività per portare avanti il progetto.

Come affrontare il problema?

Ci sono alcune soluzioni che potrebbero mitigare questo tipo di situazione, insieme a esempi concreti:

1. Formalizzare i requisiti: anche una documentazione incompleta può fare la differenza. Ad esempio, introdurre un semplice documento condiviso, come un foglio Google o, meglio ancora, un sistema come Confluence, può aiutare a tracciare i requisiti man mano che vengono scoperti. Se non esiste documentazione pregressa, un processo di “documentazione continua” potrebbe includere riunioni periodiche per annotare i nuovi requisiti emergenti, assegnandoli a una persona responsabile per garantirne il completamento.
2. Creare una cultura di condivisione incentivare il know-how sharing per ridurre la dipendenza da poche persone. Ad esempio, è utile organizzare sessioni di knowledge transfer, come workshop settimanali o pair programming, in cui chi detiene il know-how lo trasferisce attivamente al team. Un'altra soluzione è l’adozione di strumenti come Notion o Miro per creare diagrammi di flusso o mappe di processo che rendano visibili a tutti le informazioni chiave.
3. Accettare il cambiamento: integrare il cambiamento come parte del processo, riducendo la frustrazione per le scoperte tardive. In un contesto Agile, ad esempio, si potrebbe inserire un buffer temporale nello sprint planning per gestire imprevisti o dedicare una retrospettiva specifica ai “requisiti scoperti in corso d’opera”. Questo aiuta a prevenire tensioni future e ad accettare che l’iterazione fa parte della normalità.
4. Strumenti e processi migliori: utilizzare tool per la gestione delle informazioni e delle dipendenze tra team. Ad esempio, piattaforme come Jira e Trello possono essere utili per tracciare attività relative a specifici requisiti. Inoltre, stabilire un processo chiaro per le revisioni delle specifiche, come un “requirement review meeting” per discutere e confermare eventuali cambiamenti, può assicurare che nessun dettaglio venga trascurato.

Con questi approcci, non solo si affrontano meglio le incertezze, ma si pongono anche le basi per una maggiore resilienza organizzativa e una migliore collaborazione.

L’esplorazione dell’ignoto è un elemento inevitabile nello sviluppo di prodotti complessi. Accettarlo e strutturarsi per affrontarlo può fare la differenza tra una missione di successo e un fallimento.

Puoi trovare questo articolo anche su LinkedIn, sul mio profilo. Se il mio articolo ti piace, lascia un commento e metti un like sul mio post qui: https://www.linkedin.com/posts/luca-cappellaro_softwaredevelopment-teamwork-problemsolving-activity-7269266569287921664-Q4Zn