Angolo

Un Product Manager dotato di un assistente di codice produce in quattro giorni ciò che gli avrebbe richiesto un mese, e questa velocità non dice nulla di ciò che ha il diritto di costruire. A dirlo è lo stato del terreno su cui appoggia il suo lavoro: un catalogo aggiornato delle API interne gli risparmia le deviazioni che generano incoerenza; test che esprimono l'intenzione di business gli restituiscono una presa su un codice che non ha letto; una codebase dal linguaggio di business leggibile decide da sola se compone con blocchi esistenti o se arrangia qualcosa accanto al prodotto; e controlli di sicurezza automatici presidiano l'unica esigenza che non si negozia né con la posta in gioco né con le scadenze. Dove questi quattro pezzi mancano, la stessa persona, con la stessa competenza e lo stesso strumento, produce solo oggetti che non saprà né spiegare né riparare — e la sua competenza tecnica, se ce l'ha, non fa che ritardare il momento in cui ciò diventa evidente. Il terreno fissa quindi insieme il perimetro consentito e la velocità raggiungibile, il che colloca l'apertura del codice ai profili di prodotto tra le decisioni di architettura prima ancora che tra le questioni di autorizzazione.

Sintesi

Le note, prese una per una, descrivono ciascuna un pezzo del problema: la velocità, i difetti che l'assistente crea da solo, l'autorizzazione, la review, i test, i binari, il ruolo degli sviluppatori. Ciò che fanno emergere insieme è uno spostamento del parametro di decisione. La discussione corrente verte sulla persona — ha abbastanza bagaglio tecnico, serve un livello minimo, bisogna vietarlo ai profili non tecnici. Ogni nota, presa dal suo lato, rimanda altrove: a ciò che è stato preparato prima di lei.

Il meccanismo è ogni volta lo stesso, e dipende da una proprietà dell'assistente: non indovina ciò che non è scritto da nessuna parte. Ignora i volumi reali, quindi progetta per il set di test. Non conosce i punti d'ingresso legittimi, quindi ne inventa. Non ricorda ciò che gli è stato corretto ieri, quindi ricomincia. Nessuna di queste lacune si colma con la competenza di chi guida; tutte si colmano con un'informazione messa a disposizione nell'ambiente — ed è questo a far passare la responsabilità dalla parte di chi gestisce quell'ambiente.

Ne segue una conseguenza meno prevedibile. La competenza tecnica di chi guida resta utile, ma il suo impiego cambia: non serve più a produrre, serve a rilevare — vedere un file che cresce troppo, accorgersi di uno strato che si mescola a un altro, riconoscere una risposta di API che non reggerà il carico. Questa capacità di rilevamento non ha alcun sostituto automatico, ed è l'unica cosa che il terreno non fornisce. Spiega perché la questione del perimetro non sparisce: un terreno eccellente allarga ciò che è fattibile senza rendere chi opera capace di valutare ciò che produce.

Resta ciò che questa angolazione costa all'organizzazione. Spostare la decisione verso il terreno significa dire che l'apertura del codice ad altre funzioni si paga prima di tutto in lavoro di architettura — API pulite, convenzioni rispettate, ambienti sicuri, controlli automatici —, cioè in spese senza nulla di visibile da consegnare al cliente. È la voce più facile da tagliare, eppure è quella che decide se l'apertura porta sollievo o soluzioni raffazzonate. La domanda «i Product Manager possono sviluppare?» non ha quindi una risposta generale: ne ha una per ogni azienda, e quella risposta è stata scritta prima che la si ponesse, nello stato della sua codebase.

Tensioni / contraddizioni

Queste note non concordano sul peso reale della competenza individuale. Quelle che spostano la decisione verso il terreno presuppongono che le lacune dell'assistente si colmino con l'ambiente; quella che descrive come far funzionare uno strumento nel tempo ricorda che saper diagnosticare un guasto non si scrive in nessun catalogo di API. Se questa parte è grande, il terreno è solo una condizione necessaria e la competenza resta il fattore limitante.

Un disaccordo più netto oppone due letture dell'accelerazione. L'angolazione difesa qui tratta la velocità come un beneficio da inquadrare, e ritiene che i meccanismi perduti si ricostituiscano attraverso il terreno. La lettura sviluppata altrove sulla formazione della competenza sostiene che alcuni di questi meccanismi — l'errore analizzabile, il primo gradino, il costo dello scrivere da sé — non si ricostituiscono con degli strumenti, perché richiedevano di essere stati responsabili del risultato. Niente qui scioglie la questione: un terreno che elimina le deviazioni elimina anche le occasioni di imparare a riconoscerle.

Infine, l'esigenza di sicurezza non graduata e l'alleggerimento della review sugli oggetti usa e getta convivono male nella pratica: chiedono alla stessa organizzazione di allentare un controllo umano e di mantenere un controllo automatico, il che presuppone strumenti che le organizzazioni che allentano la review spesso non hanno.

Domande

• Quale parte del terreno va costruita prima di aprire, e quale si costruisce in risposta ai primi usi, a rischio di lasciar passare gli oggetti prodotti nel frattempo?
• Un terreno progettato per gli assistenti e uno progettato per gli sviluppatori umani divergono, e a che punto bisogna mantenerne due?
• Come può un'organizzazione valutare lo stato del proprio terreno prima di aprire, se non constatando a posteriori ciò che è stato prodotto?
• Su cosa si fonda la decisione di investire in questo lavoro di architettura, quando il suo beneficio si misura in incoerenze che non si sono prodotte?