Idea

Aprire un ambito ai contributi si decide in base al rischio della zona, non al mestiere di chi contribuisce

Info

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

Idea principale

«Un Product Manager può rilasciare in produzione?» è una domanda mal posta, perché si aspetta una risposta unica là dove il prodotto non è omogeneo. La domanda utile riguarda la zona: traduzioni, contenuti, dashboard e schermate in sola lettura presentano un rischio basso; le piccole azioni in scrittura e le modifiche di interfaccia delimitate e supervisionate, un rischio medio; pagamenti, permessi, sicurezza, dati sensibili, logica di business critica e architettura, un rischio alto.

Questa suddivisione non segue i confini dei prodotti. Un software regolamentato contiene schermate di consultazione relativamente sicure; un prodotto in apparenza innocuo contiene una zona molto delicata appena tocca i permessi o una decisione di business irreversibile. È quindi la zona, e non il settore, a fissare il livello di esigenza.

L'analogia regge con l'arrivo di uno sviluppatore junior: non gli si affida il motore il primo giorno, si comincia da ambiti semplici e si allarga man mano che la competenza si dimostra. La stessa scala vale per un profilo di prodotto che costruisce — a condizione che competenza, contesto e guardrail avanzino insieme.

Perché è importante

Sostituisce un dibattito identitario con una scelta praticabile: invece di decidere chi ha il diritto di contribuire, si decide quali zone sono aperte e a quali condizioni.

E protegge dai due eccessi: il divieto generale che congela i contributi, e l'apertura generale che lascia modificare una regola di fatturazione a qualcuno il giorno stesso in cui ha imparato ad aprire una pull request.

Sfumature e limiti

La mappa dei rischi ha un costo di manutenzione, e invecchia: una zona considerata sicura lo diventa meno appena un'integrazione la collega a un flusso sensibile.

E il rischio non si riduce alla zona toccata: una modifica innocua su un componente condiviso si propaga ovunque quel componente venga riusato.

Domande aperte

  • Chi stabilisce e tiene aggiornata la mappa delle zone di rischio, in un team in cui più mestieri contribuiscono allo stesso repository?