Nel messaggio precedente abbiamo introdotto la Legge di Conway e come i suoi effetti siano inevitabili.

Come prendere tutto questo in considerazione?

Il primo passo è smettere di opporti a questa dinamica o far finta che non esista. Immagina di essere un architetto incaricato di un nuovo progetto da distribuire tra sei team sparsi in diverse città europee. La tua prima decisione potrebbe essere quella di suddividere il sistema in sei sottosistemi principali. In questo modo stai già tenendo conto delle dinamiche descritte dalla legge di Conway. Perché? Perché stai considerando la collocazione geografica.

Ti è mai capitato di faticare a comunicare con un collega semplicemente perché lavorava su un piano diverso dal tuo? Se sì, hai sperimentato un effetto diretto di queste dinamiche. La posizione fisica delle persone influisce sulla comunicazione, anche quando sono nello stesso edificio: basta metterle su piani diversi per ridurre in modo significativo la frequenza e la qualità dello scambio. Se poi sono in città diverse o addirittura in fusi orari differenti, la complessità aumenta quindi le interazioni tra i componenti del sistema devono essere definite con precisione e ridotte al minimo, perché chi li sviluppa avrà a disposizione canali di comunicazione sempre meno efficaci.

Anche se oggi siamo tutti collegati tramite chat e call?

Sì, ma in modo un po’ diverso. Il lavoro da remoto riduce l’impatto della distanza, perché tutti comunichiamo online, ma la legge di Conway continua ad agire: si riflette nei canali digitali invece che nei corridoi dell’uffici. Ad esempio, se lavori con qualcuno nella stessa stanza, basta alzare lo sguardo o fare un cenno per chiarirsi in pochi secondi. Se invece lavori isolato da casa comunicando su Slack, la conversazione sarà meno spontanea, forse frammentata, e potrebbe slittare di ore. La comunicazione di natura scritta e asincrona è completamente diversa quella verbale istantanea. Questo cambia radicalmente il modo in cui i team collaborano — e, di conseguenza, il modo in cui il software viene progettato e strutturato. Con queste prime considerazioni puoi già assicurarti che le tue architetture non siano in contrasto con i percorsi di comunicazione dei tuoi software engineer.

Azioni / Finale

C’è un ulteriore approccio… ma è per il prossimo messaggio.

Sharing is caring

Se conosci qualcuno che potrebbe trovare utile ricevere e-mail per migliorare l’organizzazione dei team di sviluppo software, DevOps e software engineering in generale inoltragli questo post! Qui può iscriversi e cominciare a ricevere subito!