Imparare a costruire software — La nostra sfida culturale nella realizzazione di un agreement tecnico
Costruire software è un processo complesso che richiede una solida base tecnica, ma anche una solida cultura aziendale.
L’eterogeneità all’interno di un team di sviluppo può essere allo stesso tempo sia un punto di forza, se visto come stimolo al confronto, sia un punto di debolezza, poiché le diversità di vedute possono portare all’innalzamento di muri poi molto difficili da rimuovere.
Nel nostro percorso di sviluppo qui in Webeetle, abbiamo affrontato una sfida significativa: si è notata la necessità di alzare la qualità dei nostri processi interni, sia di pianificazione che di scrittura del codice.
Photo by Maryia Shedava on Unsplash
Uno sforzo comune
Questa sfida ha richiesto uno sforzo collettivo da parte dei vari team per superare differenze di opinione e punti di vista per creare un ambiente in cui le idee potessero fluire liberamente e convergere verso un obiettivo comune: realizzare un agreement tecnico che faccia da “punto di partenza” di un percorso più lungo e strutturato.
Nel nostro contesto aziendale, abbiamo riconosciuto l’importanza di promuovere una cultura che valorizzasse la qualità del software come elemento fondamentale. Tuttavia, ci siamo resi conto che la nozione di “qualità” poteva variare tra i diversi membri del team.
Alcuni mettevano l’accento sulla stabilità e l’affidabilità, mentre altri privilegiavano la velocità di sviluppo e l’innovazione. Queste differenze culturali hanno creato un terreno fertile per il confronto e la discussione.
Come sempre si parla sempre di compromesso, di trovare un punto di equilibrio tra queste diverse prospettive e creare un accordo che tenesse conto delle esigenze di tutti (sembra facile eh?).
Ma come abbiamo fatto?
Abbiamo iniziato promuovendo un ambiente di lavoro inclusivo e aperto, in cui ogni voce potesse essere ascoltata e rispettata. Abbiamo organizzato sessioni di brainstorming e incontri per consentire a tutti di esprimere le proprie idee, i propri dubbi e le proprie preoccupazioni.
La stesura è stata un’attività collettiva, che ha seguito solo la regola della valorizzazione delle conoscenze: nel senso che la prima bozza era curata dalla persona più addentro in quel determinato aspetto. Le fasi successive sono state seguite sempre dal team nella sua interezza
Ma non è stato tutto rose e fiori, non stiamo parlando di un processo lineare. Il gioco di squadra non è sempre stato dei migliori. Non siamo mica i power rangers.
Ma con il passare delle riunioni è emerso rapidamente che la diversità di opinioni rappresentava un vantaggio per tutti. Le diverse prospettive ci hanno permesso di considerare aspetti del processo di sviluppo che altrimenti sarebbero potuti sfuggire. Ci siamo resi conto che la chiave per superare le differenze culturali era la volontà di ascoltarsi reciprocamente, di cercare punti di convergenza e di lavorare insieme.
Durante i nostri dibattiti, abbiamo identificato alcuni principi condivisi che hanno guidato la nostra visione di costruire software di qualità. Abbiamo riconosciuto l’importanza di un’architettura modulare, di una copertura di testing adeguata e di una gestione efficace dei requisiti.
Questi principi sono diventati i pilastri che hanno stabilito le linee guida per lo sviluppo dei nostri software oltra a definire nuovi workflow che sono stati abbracciati poi dai vari team.
Abbiamo realizzato una base solida su cui costruire e stabilito un linguaggio comune per discutere delle scelte di sviluppo, si è dato spazio ad una cultura di responsabilità e di attenzione alla qualità.
La nostra sfida culturale nella realizzazione di questo agreement tecnico ci ha insegnato l’importanza di abbracciare le differenze e di lavorare insieme per raggiungere un obiettivo comune. Ha rafforzato il nostro team, promuovendo un ambiente di lavoro collaborativo e inclusivo. Siamo fieri dei risultati che abbiamo ottenuto e siamo fiduciosi che questa esperienza ci abbia resi una squadra più forte e coesa.
