Idea principale

Uno sviluppatore che usa un agente di codice e consegna tre volte più in fretta non per questo cambia ruolo. Se non ha accesso né ai clienti, né ai dati d'uso, né al contesto di business, né alle scelte di priorità, ciò che guadagna è un carico: più funzionalità sulle spalle, più pressione sulle scadenze, più decisioni locali da prendere alla cieca — senza il potere sul prodotto che gli permetterebbe di decidere in altro modo che per default.

È la differenza tra farsi carico di una parte del giudizio di prodotto il più vicino possibile alla costruzione e pilotare una macchina che produce. La prima presuppone un accesso; la seconda soltanto uno strumento.

Un'organizzazione che annuncia di ridistribuire l'ownership di prodotto verso chi costruisce, senza aprire al tempo stesso l'accesso al cliente, ai dati e alle scelte, ridistribuisce quindi la responsabilità e si tiene il potere. La crescita di ruolo resta sulla carta.

Perché è importante

Offre una domanda da porre a ogni ridistribuzione annunciata: che cosa ha ottenuto la persona il diritto di vedere e di decidere, oltre a ciò che ha ottenuto il diritto di consegnare?

E dà un nome a un rischio di degrado silenzioso: il team è più produttivo, gli indicatori di delivery migliorano, e il lavoro diventa meno sostenibile per chi lo fa.

Sfumature e limiti

Nemmeno l'accesso basta. Incontrare i clienti senza il tempo di elaborare ciò che si sente, o assistere alle scelte senza pesarvi, riproduce lo stesso effetto con un'apparenza di apertura.

E non tutti gli sviluppatori desiderano questo spostamento: alcuni vogliono costruire, non decidere tra opzioni, e imporre loro un'ownership di prodotto impoverisce il lavoro invece di arricchirlo.

Domande aperte

• Quale livello di accesso ai clienti e alle scelte basta a rendere reale l'ownership, senza trasformare il team di sviluppo in un team di discovery?