Flussi di lavoro e implementazione di Performance Analytics: costruire una cultura delle prestazioni

Porta le prestazioni nel flusso di sviluppo. Costruisci una cultura delle prestazioni con rituali settimanali, budget e responsabilità del team.

Bozza

Ottimizzare le prestazioni non è un progetto una tantum. Le prestazioni sono una pratica continua.

Un flusso di lavoro significa: il team rivede i dati sulle prestazioni ogni settimana. Il team ne parla nelle riunioni quotidiane. Il team pensa alle prestazioni quando scrive il codice. Il team festeggia i miglioramenti.

Senza flusso di lavoro: le prestazioni peggiorano nel tempo. Il team non ci pensa finché il sito non si rompe.

Con il flusso di lavoro: le prestazioni migliorano nel tempo. Il team costruisce una cultura delle prestazioni. Le prestazioni hanno valore.

Il rituale settimanale sulle prestazioni

Ogni lunedì mattina: il team rivede il report sulle prestazioni.

Il report mostra: cosa è migliorato la settimana scorsa, cosa è peggiorato la settimana scorsa, cosa richiede attenzione questa settimana.

Discussione del team: perché è peggiorato l'LCP della pagina di pagamento? È colpa del nuovo codice? Dobbiamo indagare?

Risultato: si definiscono le azioni da fare. I miglioramenti delle prestazioni entrano nello sprint.

Esempio reale di rituale settimanale:

  • Lunedì ore 10: riunione di revisione delle prestazioni
  • Revisione delle metriche: l'LCP della home page è migliorato di zero virgola due secondi (bene), l'INP della pagina prodotto è peggiorato di cinquanta millisecondi (da approfondire)
  • Analisi della causa: la pagina prodotto ha caricato una nuova funzione (motore di raccomandazioni). La funzione ha aggiunto JavaScript che ha fatto salire l'INP.
  • Azioni: rimanda il JavaScript del motore di raccomandazioni, ottimizza il codice della funzione
  • Responsabile: il tecnico incaricato della correzione
  • Scadenza: rilascio di mercoledì

Portare le prestazioni nel flusso di sviluppo

Prima di rilasciare una funzione: il tecnico misura l'impatto sulle prestazioni.

Una funzione aggiunge funzionalità. Aggiunge anche codice. Il codice fa crescere il pacchetto. Un pacchetto più grande può peggiorare le prestazioni.

Il metodo: il budget di prestazioni. La funzione non deve superare il budget.

Esempio: una nuova funzione della pagina di pagamento. Budget: non aggiungere più di venti kilobyte al pacchetto JavaScript. Il tecnico realizza la funzione. La funzione aggiunge venticinque kilobyte. La funzione supera il budget. Il tecnico deve ottimizzare: togliere il codice inutilizzato, dividere il pacchetto, rimandare il codice. Il tecnico riporta la funzione a venti kilobyte. La funzione viene approvata.

Esempio reale: realizzare un motore di raccomandazioni di prodotti

Funzione: mostrare raccomandazioni di prodotto personalizzate nella pagina prodotto.

Budget di prestazioni: non aggiungere più di cinquanta kilobyte al pacchetto.

Prima realizzazione: cinquanta kilobyte. Al limite del budget.

Test: misura LCP e INP.

  • L'LCP sale da due a due virgola tre secondi (inaccettabile, supera il budget)
  • L'INP sale da centocinquanta a trecento millisecondi (inaccettabile, supera il budget)

Ottimizzazione del tecnico: carica in modo differito le raccomandazioni sotto la parte visibile, rimanda il caricamento dei dati delle raccomandazioni a dopo che la pagina è interattiva.

Nuova realizzazione: stessa dimensione di cinquanta kilobyte, ma:

  • L'LCP torna a due secondi (entro il budget)
  • L'INP torna a centosettanta millisecondi (entro il budget)

Funzione approvata: i requisiti di prestazioni sono rispettati.

Riferire alla direzione

Report mensile alla direzione: andamento delle prestazioni e impatto sul business.

Struttura del report:

  • Obiettivi di prestazioni e progressi
  • Confronto con il mercato (come ci posizioniamo rispetto agli altri)
  • Impatto sul business (ricavi generati dai miglioramenti delle prestazioni)
  • Prossima priorità (cosa ottimizziamo adesso)

Esempio reale di report mensile al team dirigente:

  • Obiettivo: portare il novanta per cento degli utenti sotto un LCP di due virgola cinque secondi
  • Progressi: ora l'ottantasette per cento (era l'ottantacinque per cento il mese scorso)
  • Tempi: in linea per raggiungere l'obiettivo in due mesi
  • Posizione sul mercato: l'LCP mediano degli altri è due secondi, il nostro LCP è due secondi (nella media, competitivi)
  • Impatto sul business: i miglioramenti delle prestazioni del mese scorso hanno aumentato i pagamenti completati dello zero virgola cinque per cento. Su centomila visitatori al mese, sono cinquecento conversioni in più. Con un valore d'ordine di cento dollari, sono cinquantamila dollari di ricavi mensili in più. Seicentomila dollari all'anno.
  • Prossima priorità: ottimizzazione mobile (l'LCP su mobile è più lento di un secondo rispetto al desktop, occasione per migliorare la conversione su mobile)

Assumere per una cultura delle prestazioni

Assumi tecnici a cui importano le prestazioni. Domanda per il colloquio: raccontami un'ottimizzazione delle prestazioni che hai realizzato.

Assumi responsabili di prodotto che danno valore alle prestazioni. Le prestazioni migliorano l'esperienza utente e il tasso di conversione. I responsabili di prodotto devono conoscerne l'impatto sul business.

Costruisci una cultura di team in cui le prestazioni hanno valore. Festeggia i successi sulle prestazioni. Riconosci il tecnico che ha migliorato l'LCP di zero virgola cinque secondi.

Esempio reale: assumere per una cultura delle prestazioni.

Domanda per un candidato tecnico: descrivi una volta in cui hai ottimizzato il codice per le prestazioni. Qual era il problema? Come hai misurato il miglioramento? Qual è stato l'impatto sul business?

Risposta buona: avevamo un endpoint API lento che impiegava due secondi. Gli utenti si lamentavano dell'iscrizione lenta. Ho analizzato il codice e ho trovato una query costosa al database. Ho aggiunto la cache. Il tempo di risposta è sceso a duecento millisecondi. Il completamento delle iscrizioni è salito del due per cento. Cinquanta clienti in più al mese. Duecentocinquantamila dollari di ricavi annui in più.

La risposta mostra: comprensione tecnica (analisi del codice, cache), misurazione (prima e dopo), pensiero di business (impatto su iscrizioni e ricavi).

Assumi questo tecnico. Pensa alle prestazioni e al business.

Domande frequenti

Come motiviamo il team a dare priorità alle prestazioni?

Collega le prestazioni alle metriche di business. Mostra che un miglioramento dell'uno per cento delle prestazioni equivale a un aumento dell'uno per cento delle conversioni. Calcola l'impatto sui ricavi. Mostra il costo di ottimizzazione rispetto ai ricavi ottenuti. Ai tecnici importa l'impatto. Le prestazioni hanno un impatto misurabile. I tecnici daranno la priorità. Con il creatore di siti di WEMASY puoi impostarlo direttamente sul tuo sito.

L'ottimizzazione delle prestazioni dev'essere un team a parte o far parte di tutti i team?

Far parte di tutti i team. Ogni tecnico dovrebbe pensare alle prestazioni. Un team separato per le prestazioni è un collo di bottiglia. Meglio una responsabilità distribuita. Ogni tecnico è responsabile delle prestazioni del proprio codice. Il responsabile tecnico chiede conto al team.

Come bilanciamo le nuove funzioni con l'ottimizzazione delle prestazioni?

Le prestazioni sono una funzione. Una nuova funzione più il suo impatto sulle prestazioni è il costo totale. Pianifica il budget per entrambe. Esempio: una nuova funzione costa uno sprint. La stessa funzione costa anche zero virgola cinque sprint per ottimizzare le prestazioni. Il costo totale è uno virgola cinque sprint. Assegna entrambi. Funzione e prestazioni si rilasciano insieme.

E se alla direzione le prestazioni non interessano?

Mostra l'impatto sul business. Un miglioramento della conversione dell'uno per cento vale cinquantamila dollari al mese (per un tipico negozio online). La direzione capisce i ricavi. Migliorare le prestazioni vuol dire migliorare i ricavi. La direzione si interesserà.

Quanto ci vuole per costruire una cultura delle prestazioni?

Da tre a sei mesi. Primo mese: definisci metriche e dashboard. Secondo mese: partono le revisioni settimanali, la consapevolezza del team cresce. Terzo mese: il team inizia a pensare alle prestazioni nel codice. Sei mesi: le prestazioni fanno parte del DNA del team. I nuovi tecnici imparano la cultura delle prestazioni dal primo giorno.

Come manteniamo la cultura delle prestazioni mentre l'azienda cresce?

Documenta le pratiche. Inserisci i nuovi tecnici nella cultura delle prestazioni. Primo giorno: mostra la dashboard delle prestazioni. Prima settimana: assegna un compito di miglioramento delle prestazioni. Primo mese: fissa un obiettivo di prestazioni. I nuovi tecnici imparano la cultura. La cultura si mantiene.

Mettilo in pratica
sul tuo sito web.

Inizia gratis con WEMASY e crea il tuo sito in pochi minuti.