Idea

Il diritto di produrre codice si regola sul rapporto tra competenza e rischio del prodotto, non sulla sola competenza

Info

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

Idea principale

La domanda «un Product Manager può ormai sviluppare con un assistente?» chiama una risposta sì o no, ed è proprio questo a renderla inutilizzabile. Nessuna organizzazione si comporta così con i propri sviluppatori: a un principiante non si apre il primo giorno il repository più critico, e non gli si danno nemmeno tutti gli accessi, tutti i dati e tutti i permessi. La competenza non decide da sola; decide in rapporto a ciò che è in gioco.

La formulazione utile non è quindi un diritto ma un perimetro. Un piccolo strumento interno, personale, con vita breve e senza impatto tollera poco formalismo: se si rompe, lo si butta. Uno strumento condiviso, con scritture limitate e dipendenze dal business, chiede già di più. Un prodotto che tocca dati sensibili dei clienti, permessi, fatturazione o scritture irreversibili cambia completamente categoria.

Lo stesso ragionamento vale per la competenza, e non solo all'ingresso: chi accetta di non saper spiegare certe parti del codice su uno strumento interno può rifiutare la stessa zona d'ombra su un prodotto critico. Dove si mette l'asticella non è un tratto di carattere, è una scelta fatta prodotto per prodotto.

Perché è importante

Toglie la discussione dalla disputa sulla legittimità. Dibattere se i profili di prodotto abbiano «il diritto» di programmare non produce nessuna politica; definire cosa possono fare, su quali repository, con quali permessi e da quale livello di posta in gioco, sì.

Sposta anche l'onere della prova. Non si tratta più di dimostrare che un Product Manager è abbastanza bravo, ma di classificare i prodotti in base a quanto vi costerebbe un errore — un lavoro che l'organizzazione deve fare comunque, anche per i suoi sviluppatori.

Sfumature e limiti

La regola presuppone che la categoria di rischio di un oggetto sia nota nel momento in cui lo si costruisce. Lo è di rado, e uno strumento può cambiare categoria per effetto della sua adozione senza che il quadro iniziale venga rivisto.

Non dice nulla nemmeno del livello di esigenza da adottare per ciascuna categoria: fissa la domanda, non la griglia, e la griglia dipende da ogni azienda.

Domande aperte

  • Chi, in un'organizzazione, è legittimato a classificare un prodotto in una categoria di rischio — il team tecnico, la sicurezza, il reparto che ne dipende?