Tesi

L'artefatto che fa autorità è quello da cui si sanno estrarre gli altri

Info

Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.

Angolo

Il repository del codice ha sempre fatto fede su ciò che il prodotto fa; eppure è la specifica ad aver fatto autorità, perché era l'unica che si potesse leggere in riunione. Un artefatto non governa quindi una catena di prodotto grazie alla sua affidabilità, ma grazie alla facilità con cui se ne ricavano gli altri — e questa facilità è una questione di accesso, mai di natura. Quando leggere un repository, incrociarne le merge request e rigenerarne una documentazione di supporto smette di richiedere uno sviluppatore, la specifica perde ciò che la teneva al suo posto: non è mai stata più vera, era più accessibile. L'autorità passa allora al codice, con le sue due condizioni — un repository leggibile e qualcuno che sappia interrogarlo — e con la sua lacuna: dice che cosa fa il prodotto, mai perché lo fa in quel modo.

Sintesi

Prese una per una, queste idee sembrano un resoconto di esperienza su documenti di prodotto tenuti male. Messe in fila, descrivono come si distribuisce l'autorità tra gli artefatti di un prodotto, e che cosa la sposta.

Il punto di partenza è uno scarto tra due proprietà che si confondono. Il codice detiene lo stato reale: un comportamento presente nel repository esiste, un comportamento scritto in una specifica e assente dal repository non esiste per nessuno. Ma detenere lo stato reale non è mai bastato a governare la catena, perché chi produce i documenti — Product Manager, supporto, commerciali — non legge il repository. Lo strato in linguaggio naturale ha occupato il posto rimasto vacante, non per la qualità della sua informazione, ma per la facilità di accesso.

Questo strato, una volta installato, ha cominciato a divergere, e la divergenza non è un rilassamento. Vi concorrono due meccanismi: le decisioni prese durante lo sviluppo non risalgono sistematicamente, e risincronizzare specifica, mockup, changelog e documentazione di supporto costa, a ogni evoluzione, più del tempo disponibile. La documentazione scaduta è il risultato cumulato di scelte tutte ragionevoli prese una per una.

Ciò che cambia non è l'affidabilità del codice, che c'era già. È il prezzo del suo accesso. Non appena un repository si può interrogare senza saper scrivere codice, la specifica, il changelog, la documentazione di supporto e perfino il design system possono essere rigenerati a partire da esso invece che corretti a partire da sé stessi — e un artefatto rigenerato non scade: o viene rifatto o non lo è. L'inversione arriva fino alla fase che si credeva più lontana dal codice: un mockup composto di elementi che esistono davvero smette di essere una rappresentazione.

Questo spostamento ha un prezzo, e si paga in competenza. Presuppone un repository leggibile, il che fa della qualità del codice una variabile di prodotto e non un comfort del team. Presuppone anche qualcuno capace di incrociare codice, cronologia, merge request e regole di business — cosa che nessuno strumento verticale fa, perché ciascuno vede solo una faccia. E apre una trappola: produrre in fretta blocchi validi presi uno per uno e pagarne poi l'integrazione.

Ciò che l'insieme mostra: il rango di un artefatto segue il costo di accesso a ciò che contiene, e la gerarchia ritenuta naturale in una catena di prodotto non era che la mappa dei lettori disponibili.

Tensioni / contraddizioni

La tensione principale contrappone due note di questo gruppo. L'una fonda la posizione del Product Manager sul fatto che nessuno strumento verticale vede contemporaneamente più facce del prodotto; l'altra annuncia un protocollo che dà proprio a ogni strumento l'accesso ai perimetri vicini. Se il secondo movimento va in porto, il vantaggio del primo svanisce — e nulla qui permette di dire in quali tempi.

Seconda tensione, con un'idea scritta altrove: l'IA è stata presentata come ciò che rende finalmente redditizio uno strato di conoscenza neutro tra le fonti e i deliverable. Qui serve piuttosto a fare a meno di uno strato intermedio rigenerando dalla fonte. Le due cose possono stare insieme — lo strato che si conserva contiene l'intenzione, quello che si butta conteneva lo stato — ma il criterio che distingue i due casi non è stabilito.

Infine, l'angolazione presuppone che l'accessibilità spieghi il rango. Si può obiettare che una specifica faceva autorità anche perché era firmata: impegnava qualcuno, cosa che un artefatto rigenerato non fa.

Domande

  • Dove registrare l'intenzione di una decisione di prodotto, che né il repository né una specifica rigenerata contengono?
  • Che cosa sostituisce l'impegno rappresentato da un documento approvato, quando l'artefatto viene rigenerato su richiesta?
  • La dimostrazione regge su un prodotto software: che ne è in una catena di prodotto il cui oggetto reale non è leggibile come un repository?