Esperienza per sviluppatori

Se sì:
passa a 02.

In caso contrario:
comprendere i punti deboli degli sviluppatori è il primo passo per migliorare DevEx.

Passaggi successivi consigliati:

Eseguire un sondaggio con gli sviluppatori e porre domande come:

• Qual è la parte più difficile del tuo lavoro e perché?
• Pensando agli strumenti e ai processi di sviluppo, qual è il più grande ostacolo alla produttività?
• Se fosse possibile cambiare qualcosa nel modo in cui il team crea il software, di cosa si tratterebbe?

Se sì:
passare a 03.

Se no:
DevEx è multi-facet, quindi richiede un framework multi-faceted per comprenderlo, ecco perché abbiamo sviluppato il framework SPACE. Considera cinque dimensioni di DevEx: soddisfazione e benessere prestazioni, attività, comunicazione e collaborazione; ed eefficienza e flusso..

Per valutare DevEx, è consigliabile tenere traccia delle metriche/KPI in almeno tre dimensioni dello SPAZIO.

Per altre informazioni sul framework SPACE e per visualizzare le metriche di esempio di ogni dimensione, leggere il documento di ricerca.

Se sì:
passa a 04.

Se no:
è importante definire obiettivi chiari e realistici per ogni metrica. Inoltre, è importante che questi obiettivi si allineano ai punti critici dello sviluppatore.

Può essere difficile definire gli obiettivi. Alcuni scelgono di fare riferimento alle metriche di altri team o società ad alte prestazioni, alcuni benchmark di settore di riferimento. È anche importante notare che gli obiettivi possono cambiare nel tempo per riflettere il miglioramento continuo.

Per altre informazioni su come quantificare l'impatto di DevEx e il possibile ROI, leggere il blog e il documento di ricerca.

Se sì:
passa a 05.

Se no:
l'unico modo per migliorare DevEx consiste nel migliorare il modo di lavorare degli sviluppatori. In genere, si tratta di investire in strumenti che semplificano la loro vita o facilitano i processi chiave. Per una maggiore efficacia, è consigliabile concentrarsi e tenere traccia dei miglioramenti apportati a DevEx con le metriche identificate.

Se sì:
passa a Continua il tuo viaggio.

In caso contrario:
a volte le organizzazioni commettono l'errore di ritenere i propri sviluppatori responsabili del loro DevEx, ma questo non è corretto perché non sono gli sviluppatori a progettare la toolchain o i processi della loro azienda, bensì il team di leadership.

Le iniziative DevEx dovrebbero essere avviate dal team di leadership con l'obiettivo esplicito di migliorare l'esperienza degli sviluppatori, e il team di leadership dovrebbe essere ritenuto responsabile del successo di tali iniziative.

Questo non significa che gli sviluppatori non debbano essere coinvolti nelle iniziative DevEx. Queste iniziative sono progettate per risolvere i problemi degli sviluppatori, che ovviamente dovrebbero essere consultati e coinvolti durante tutto il processo, ma alla fine il team di leadership dovrebbe essere ritenuto responsabile del miglioramento di DevEx nella propria organizzazione.

DevEx è più maturo della maggior parte delle persone, ma il viaggio non finisce mai. È possibile mantenersi un passo avanti alla concorrenza leggendo le Ricerche DevEx più recenti ed esplorando i moderni strumenti di sviluppo che possono migliorare DevEx.