Un assistente di programmazione suggerisce una modifica; una persona la accetta, la integra e se ne assume la responsabilità. Questa catena di responsabilità non cambia solo perché cambia la persona che scrive la bozza, ed è meglio che non cambi: è l'unico modo per garantire che ci sia qualcuno a cui rivolgersi quando il sistema si comporta in modo imprevisto in produzione.
Il problema sorge quando la responsabilità viene implicitamente diluita, senza che nessuno lo decida esplicitamente. Nessuno dichiara di non essere più responsabile del proprio codice. In poche parole, il divario tra chi lo accetta e chi lo ha compreso si allarga.
Questa confusione è costosa perché consuma il budget e mina la credibilità dell'iniziativa. Quando, sei mesi dopo, qualcuno chiede cosa sia migliorato, la risposta onesta è di solito "l'esperienza iniziale", e questo non giustifica un programma di trasformazione.
Tre meccanismi, tutti e tre silenziosi:
La recensione diventa superficiale. Quando si verificano frequentemente grandi cambiamenti, l'atteggiamento del revisore passa da "Capisco e sono d'accordo" a "sembra ragionevole". Il rapporto DORA del 2024 ha misurato l'effetto complessivo: con l'aumento dell'adozione dell'IA, la stabilità delle consegne è diminuita del 7,2%, in concomitanza con la crescita delle dimensioni dei batch di modifiche.
La paternità dell'opera si fa sfumata. In un caso, alla domanda "Chi ha scritto questo?" la risposta è stata "L'abbiamo generato noi". Questa risposta impedisce alla conversazione di proseguire.
La fiducia sostituisce la verifica. Il codice funziona durante i test, quindi si presume che sia valido. Ma funzionare ed essere valido sono due cose diverse: quest'ultima include ciò che accadrà quando il contesto cambierà.
Nello stesso rapporto DORA, il 39,21% degli sviluppatori ha dichiarato di avere poca o nessuna fiducia nel codice generato. Si tratta di un dato scomodo che va nella direzione opposta: si dichiara sfiducia, eppure il volume di codice accettato è in aumento.
Non si tratta di attribuire colpe. Si tratta di essere in grado di rispondere a quattro domande su qualsiasi parte del sistema:
Chiunque sia in grado di rispondere a tutte e quattro le domande è responsabile di quel codice, indipendentemente dal fatto che sia stato scritto da una persona o da uno strumento. Chiunque non sia in grado di rispondere a nessuna di esse non è responsabile, anche se è elencato come autore nel repository.
Ruolo | Quali caratteristiche offre questo strumento? | Ciò che resta umano |
|---|---|---|
Progetto | Alternative ed esempi | Scegliere e accettare la scelta |
Implementazione | Bozza funzionale | Verifica che soddisfi le aspettative aziendali. |
Revisione | Rilevamento di modelli noti | Valutazione dell'adeguatezza e delle conseguenze |
Operazione | Avvisi e diagnosi | Decidere cosa fare quando qualcosa va storto |
Responsabilità | Nessuno | Tutto |
L'ultima frase non è retorica. Nessuno strumento condivide la responsabilità di fronte a un cliente, un revisore dei conti o un tribunale. L'organizzazione è responsabile di ciò che fa il suo software, indipendentemente da come è stato prodotto, come stabilito nel caso del chatbot di Air Canada, risolto nel 2024.
Nessuno unisce ciò che non sa spiegare. La regola di base. Non richiede la comprensione di ogni dettaglio, ma piuttosto la capacità di rispondere alle quattro domande sopra elencate.
Ad ogni modifica è associata una persona responsabile, nominata per nome. Non si tratta di un team. C'è una sola persona responsabile di quella parte del sistema, alla quale è possibile rivolgere domande.
I test critici sono scritti da una sola persona. Se lo stesso strumento genera sia l'implementazione che il test che la convalida, il circuito si chiude su se stesso e non verifica nulla di rilevante.
L'entità del cambiamento è limitata. È la misura che rende possibili le tre precedenti. Un cambiamento importante non può essere esaminato a fondo, per quanto buone siano le intenzioni di chi lo esamina.
Se la vostra azienda esternalizza lo sviluppo, questa conversazione ha un impatto contrattuale diretto. Tre domande da porre al fornitore:
Chi è responsabile dei difetti nel codice consegnato? Un difetto non comporta una modifica dell'ambito del progetto. Deve essere corretto gratuitamente e documentato per iscritto. Nel nostro caso, si tratta della Garanzia Rain: correggiamo qualsiasi difetto nel codice che consegniamo, a vita.
Riusciresti a spiegare qualche aspetto del sistema a distanza di sei mesi? Il test è semplice: chiedete una spiegazione di un modulo scelto a caso.
Quale documentazione relativa alla decisione viene fornita? Non si tratta di un commento riga per riga, ma piuttosto di una spiegazione del perché ogni approccio è stato scelto e cosa è stato scartato. Questo è ciò che permette a un altro team di subentrare.
Un fornitore che accetta queste tre condizioni afferma di mantenere intatta la catena di responsabilità. Un fornitore che le condiziona, invece, indica dove si verificherà la lacuna.
Per un direttore tecnico che desidera conoscere lo stato attuale del proprio team, esiste un esercizio che richiede un'ora: Scegli a caso tre parti del sistema e chiedi ai responsabili di rispondere alle quattro domande.
Il risultato non misura la qualità del codice. Misura qualcosa di più importante: se l'organizzazione controlla il proprio sistema o se ne è semplicemente proprietaria.
La persona che lo accetta e lo integra nel sistema e l'organizzazione che lo mette in produzione. Nessuno strumento condivide la responsabilità di fronte a un cliente, un revisore dei conti o un tribunale: l'azienda è responsabile di ciò che fa il suo software, indipendentemente da come è stato prodotto.
Con quattro domande: cosa fa questo in termini aziendali, perché è fatto così e quale alternativa è stata scartata, cosa si romperà se viene modificato e come si fa a sapere che continuerà a funzionare? Chiunque sia in grado di rispondere a tutte e quattro le domande è responsabile di quel codice, che sia stato scritto da una persona o da uno strumento.
Attraverso tre percorsi silenziosi: la revisione diventa superficiale man mano che le modifiche aumentano di portata, l'attribuzione di paternità si fa più sfumata fino a quando la risposta a un incidente è "l'abbiamo generato noi", e la fiducia nel superamento dei test sostituisce la verifica che il comportamento corrisponda alle aspettative aziendali.
Quattro: nessuno unisce elementi che non può spiegare, ogni modifica ha una persona specifica responsabile e non un team, i test critici sono scritti da una persona e non dallo stesso strumento che ha generato l'implementazione, e la dimensione delle modifiche è limitata in modo da consentire la revisione.
Devono essere responsabili, senza alcun costo aggiuntivo e per iscritto, dei difetti presenti nel codice consegnato, essere in grado di spiegare qualsiasi parte del sistema anche sei mesi dopo e fornire documentazione delle decisioni prese e delle alternative scartate, non solo commenti nel codice.
Secondo il rapporto DORA del 2024, il 39,21% degli intervistati ha espresso poca o nessuna fiducia nel sistema. Questo dato è rilevante perché coincide con un aumento del volume dei test accettati, suggerendo che la sfiducia espressa non si traduce sempre in un maggior numero di test.
Il vostro team potrebbe illustrarvi qualche aspetto del vostro sistema? La nostra verifica tecnica valuta l'architettura, il codice, il debito tecnico e l'effettiva manutenibilità, fornendo una documentazione scritta entro 10 giorni lavorativi. Richiedi la verifica → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
