Cultura aziendale: perché conta anche (e soprattutto) nel mondo tech

Immaginiamo due software house: stesso stack, stessi strumenti, stesso numero di persone. In una, uno sviluppatore riceve un requisito che non sta in piedi e lo implementa così com'è, perché è quello che dice il ticket. Nell'altra si ferma e chiede perché.

Dall'esterno sono identiche. Il software che consegnano, due anni dopo, no.

Quella differenza si chiama cultura aziendale, e vive in un posto preciso: in quello che succede quando nessuna procedura dice cosa fare.

Una definizione che si può verificare

Della cultura aziendale si parla quasi sempre attraverso i suoi contorni: i benefit, le attività di team building, le foto della cena di Natale. Cose piacevoli, e nel migliore dei casi sintomi.

Una definizione più utile, perché si può verificare: la cultura di un'azienda è ciò che al suo interno passa per normale. Cosa passa per normale fare quando si scopre un errore. Cosa passa per normale dire quando una decisione presa più in alto ti sembra sbagliata. Cosa si risponde a un cliente che chiede una cosa che non gli conviene. Nessuna di queste situazioni sta scritta in un regolamento, e per questo dicono più di qualsiasi dichiarazione di intenti.

Perché nel software si vede più che altrove

Che nel tech la cultura abbia un peso particolare bisogna dimostrarlo, altrimenti resta un complimento che ci facciamo da soli. Non serve sostenere che pesi più che in medicina o in aeronautica: basta osservare che nel software diventa visibile molto prima, per tre caratteristiche di questo lavoro.

Lo stesso problema ha spesso più soluzioni difendibili. Quale convenga dipende dal contesto, dal budget, da chi manterrà il sistema. Nessun manuale contiene quella risposta, e una procedura nemmeno: serve giudizio, quindi servono persone a cui è stato dato il permesso di usarlo.

Il conto arriva molto dopo. Una scorciatoia presa oggi non si vede oggi: il codice funziona, i test passano, il cliente è contento. Si vede otto mesi dopo, quando una modifica da un giorno ne chiede quindici. E chi ha preso la scorciatoia, di solito, non è chi paga. Se l'unica cosa che si misura è la velocità di consegna, il debito tecnico cresce da sé, perché individualmente conviene a tutti.

Gli errori diventano pubblici in fretta. Una scelta sbagliata può arrivare davanti a migliaia di utenti nel giro di un rilascio. E in quel momento l'unica cosa che serve è che chi sospetta di averla causata lo dica subito. Se dirlo costa, lo dirà venti minuti più tardi, e quei venti minuti sono disservizio.

Il filo comune è che nel software la parte di lavoro coperta da regole è piccola, e quella lasciata al giudizio è enorme. Dove finisce la procedura comincia la cultura, per esclusione.

La cultura lascia tracce nel codice

Smette di essere un discorso astratto quando apri un progetto e riconosci le conseguenze tecniche di una cultura:

• Dove il confronto tecnico sa di ispezione, le code review diventano un timbro. Si approva per non offendere, e i difetti passano.
• Dove chiedere è visto come debolezza, un requisito ambiguo viene interpretato invece che chiarito. Al collaudo scopri che l'interpretazione era quella sbagliata, e il lavoro si rifà.
• Dove rilasciare fa paura, si rilascia raramente. Ma un rilascio raro contiene più modifiche, quindi è più rischioso, quindi fa ancora più paura.
• Dove sapere è potere, la conoscenza resta ferma e ogni area del sistema diventa proprietà di qualcuno. Nel gergo si chiama bus factor. Vale 1 più spesso di quanto si ammetta.

Il bello è che sono tracce visibili da fuori, senza sapere niente dell'azienda. La frequenza dei rilasci, la dimensione media di una modifica, il tempo che passa fra la scoperta di un problema e la sua segnalazione: dicono più di qualsiasi pagina dei valori, la nostra compresa.

Gli errori sono la parte scomoda

"Impariamo dagli errori" lo firmano tutti. Poi il momento in cui andrebbe applicato è sempre il peggiore: sistema fermo, cliente al telefono, e l'istinto che spinge a capire chi ha rotto cosa. L'istinto è comprensibile e inefficace. Un team in cui l'errore si paga impara una cosa sola e la impara benissimo, cioè come non esporsi. I problemi continuano a succedere, smettono soltanto di arrivare presto.

Poi c'è un secondo modo di sbagliare la lezione, più elegante e più diffuso: chiudere l'analisi con una raccomandazione al posto di un cambiamento. "Stiamo più attenti" è il post-mortem equivalente di "ci sentiamo presto": non è verificabile e non sopravvive al primo mercoledì di corsa. Un test che riproduce quel bug, un controllo che blocca il rilascio se la condizione torna, un allarme che suona prima dell'utente: quelli tengono, perché non chiedono a nessuno di ricordarsi.

Ecco perché ci teniamo tanto all'automazione dei rilasci, dal commit alla produzione senza passaggi manuali. Un processo automatico è cultura sedimentata, la parte della lezione che non dipende più dalla memoria delle persone. È lo stesso lavoro che facciamo sui progetti dei clienti, su DevOps e infrastruttura.

Per la conoscenza vale lo stesso. Di formazione abbiamo già scritto, come funziona da noi; quello che si perde più spesso è il passo successivo, cioè mettere per iscritto perché una decisione è stata presa. Se quel motivo non sta scritto da nessuna parte, chi arriva dopo lo legge come un errore, lo "sistema", e il problema originale torna.

Sette persone, cinque città

La sede è alle porte di Bologna, ma il team lavora da Modena, dal Friuli, dalla Campania e dalla Calabria: quattro persone su sette in remoto. In un'organizzazione così, alcune cose che altrove restano valori diventano requisiti operativi.

Quello che non è scritto non esiste, perché una decisione presa a voce fra due persone è invisibile alle altre cinque. L'autonomia si accompagna alla responsabilità di quello che si decide, perché a distanza il controllo diretto non c'è e sostituirlo non serve: serve che le informazioni circolino. E chiedere aiuto deve costare poco, perché senza la scrivania accanto un dubbio non detto non lo intercetta nessuno passando. Non ce lo attribuiamo come merito, è una conseguenza: quando non si è nella stessa stanza, comunicazione, documentazione e facilità di chiedere aiuto smettono di essere bei valori e diventano le condizioni per lavorare.

Le domande da fare a un fornitore

Sembra un discorso interno, da pagina "lavora con noi", e invece riguarda direttamente chi compra: la cultura del fornitore la paga il cliente. Chi non mette in discussione i requisiti costruisce anche le cose sbagliate. Chi tiene nascosto un problema finché non ha la soluzione te lo fa scoprire quando è tardi per reagire. Chi ha una sola persona che conosce il progetto te lo consegna con un vincolo che durerà anni. Tre cose che nel preventivo non compaiono e che paghi comunque.

Il guaio è che la cultura non si legge sul sito, perché tutti i siti dicono le stesse cose, il nostro compreso. Si fa emergere con qualche domanda, e vale la pena farla a chiunque:

• "Raccontatemi una cosa andata storta e cosa avete cambiato dopo." La più rivelatrice. Chi non ha niente da raccontare non ha memoria dei propri errori; chi racconta il guaio ma non sa dire cosa è cambiato dopo, non ne ha ricavato niente.
• "Cosa fate se vi chiedo una cosa che secondo voi è sbagliata?" Se la risposta è "il cliente ha sempre ragione", il rischio lo scoprirai da solo, in produzione.
• "Cosa succede il giorno dopo il rilascio?" Se la risposta finisce con la consegna, il progetto ti torna in mano nel momento esatto in cui si complica.

Sono domande a cui rispondiamo volentieri, anche perché su alcune la nostra risposta è scomoda. Nel manifesto c'è scritto che non diciamo sì per compiacere, e tradotto significa che a qualche cliente abbiamo detto no. Ogni principio ha un prezzo; se non ce l'avesse sarebbe marketing.

Lo stack si scambia, la cultura no

Anche il miglior stack tecnologico ha bisogno del team giusto, e vale la pena dire perché. Tecnologie e strumenti si possono sostituire, a volte con costi importanti. La cultura di un team no: si costruisce nel tempo, attraverso quello che ogni giorno viene premiato, tollerato o corretto, e non esiste un fornitore che te la venda.

Per noi vuol dire che condividere idee, confrontarsi, imparare dagli errori e crescere insieme sono il modo in cui prendiamo le decisioni tecniche che i clienti ci pagano per prendere. Il ritorno lo misuriamo su una cosa sola: i progetti che seguiamo da anni si modificano ancora in tempi ragionevoli. Su un software su misura è l'unico test che conta davvero.

Se hai un progetto di cui parlare, o vuoi farci quelle domande, scrivici. Se invece è il nostro modo di lavorare che ti interessa dall'interno, le posizioni aperte sono queste.