Nelle organizzazioni IT complesse è frequente la strutturazione in “silos organizzativi”, aree verticali distinte per competenza. Ad esempio, un’area di esercizio distinta da un’area di sviluppo; un’area di “business analysis” distinta dal “technical development”.
I silos organizzativi, quando sono tali, tendono a ragionare in modo autonomo, e a cercare di ottimizzare il proprio funzionamento anche quando il loro interesse particolare può andare a scapito del funzionamento complessivo dell’organizzazione. A ricercare un’ottimizzazione locale a scapito di quella globale.
Ciò diventa evidente nel caso dei progetti di sviluppo software. Le aree-silos sono portate a ragionare in un’ottica di separazione, in cui la collaborazione si riduce ad un meccanismo di input-output in un modello di attività basato su una sequenza rigida. Una catena di montaggio. Un processo a cascata. Fino a quando non mi fornisci una specifica dei requisiti consolidata io non inizio a progettare.
In alcuni casi questo approccio viene contrabbandato come una logica “cliente-fornitore”.
Ma si tratta della logica “cliente-fornitore” di supply chain che oggi non funzionano più. Di organizzazioni che operavano in settori basati su economia di scala, mercati tranquilli e processi fortemente standardizzati. Non a caso, questo approccio organizzativo era soprattutto frequente nelle organizzazioni con un flusso di cassa cospicuo e garantito, operanti in mercati protetti, senza necessità di fare attenzione ai costi ed alla qualità del servizio offerto. Bei tempi, forse, ma andati.
Le logiche “cliente-fornitore” che funzionano nell’economia contemporanea sono quelle basate sulla flessibilità della supply-chain, sulla velocità di innovazione e di cambiamento
di rotta, sulla condivisione degli obiettivi e la riduzione dei rischi attraverso la collaborazione.
Nei progetti di sviluppo software, i silos organizzativi aumentano i costi ed i tempi, e riducono la qualità del servizio agli utenti. Lo sviluppo software consiste nell’acquisizione progressiva di conoscenza, e richiede che competenze diverse collaborino in modo sistematico durante l’intero progetto.
Ma la conseguenza peggiore delle catene di montaggio nello sviluppo software è a volte l’assenza di una responsabilità complessiva per il progetto. Una catena di responsabili per diverse porzioni di progetto equivale spesso a conflitti e negoziazioni tra i (parzialmente) responsabili, a riduzioni di efficienza, al perdere di vista le esigenze del committente e degli altri stakeholder di progetto.
Formazione sulle tecniche di analisi dei sistemi
I miei corsi di formazione: corsi.analisi-disegno.com