Idea principale

Quando un Product Manager apre una pull request e uno sviluppatore intervista i clienti, la conclusione che viene spontanea è che le responsabilità si dissolvano insieme agli ambiti. Succede il contrario: la confusione dei ruoli rende più necessario, non meno, designare i garanti.

Una scelta di prodotto resta una scelta di prodotto — visione, posizionamento, coerenza, decisioni, lettura del mercato, segnale del cliente — e spetta al prodotto. Una scelta tecnica resta una scelta tecnica — sicurezza, performance, capacità di reggere il carico, architettura, manutenibilità — e spetta alla tecnica. Una scelta di esperienza resta una scelta di esperienza — design system, coerenza d'uso, accessibilità, livello di esigenza — e spetta al design o al front-end.

L'organizzazione che funziona non è quindi quella in cui ciascuno fa tutto per conto suo: è quella in cui ciascuno può intervenire oltre il proprio dominio iniziale perché dei garanti hanno fissato gli standard, i guardrail e i limiti. È la chiarezza di queste tre linee a permettere lo sconfinamento, e non il contrario.

Perché è importante

Ribalta un'intuizione diffusa sui team autonomi: non è cancellando i confini che si allargano i contributi, è dicendo chi risponde di che cosa.

E dà un ordine delle operazioni a un team che vuole aprirsi: prima designare i garanti, poi aprire gli ambiti.

Sfumature e limiti

I tre domini non si separano in modo netto. Una scelta di architettura condiziona il costo delle future evoluzioni del prodotto, una scelta di esperienza impone vincoli tecnici: il garante decide nel proprio dominio, non decide da solo che cosa la decisione produce altrove.

E un garante può diventare un passaggio obbligato: se tutto deve risalire fino a lui, la funzione di garanzia si trasforma in autorizzazione preventiva, e l'apertura che doveva rendere possibile si richiude.

Domande aperte

• Come fa un garante a fissare uno standard abbastanza esplicito perché i contributi vi si conformino senza doverlo consultare ogni volta?