Gli OKR (Objectives and Key Results) sono il framework di definizione degli obiettivi che allinea le ambizioni individuali, di team e aziendali — con Obiettivi qualitativi che descrivono la direzione ambiziosa e Risultati Chiave quantitativi che misurano il progresso che definisce se l'obiettivo è stato raggiunto. Nei contesti di prodotto e operazioni, gli OKR focalizzano il lavoro sui miglioramenti più impattanti piuttosto che sulla mera attività.
?
Come dovrebbero i team di prodotto e operazioni scrivere OKR che siano realmente utili piuttosto che burocratici?
La maggior parte delle implementazioni di OKR fallisce non perché gli OKR siano un cattivo framework, ma perché gli OKR sono scritti male — risultando in ambizioni vaghe senza risultati misurabili o obiettivi di attività (spedirò X funzionalità) che si mascherano da metriche di risultato. Buoni principi per la scrittura degli OKR: Gli Obiettivi devono essere ispiratori e direzionali: "Diventare il leader indiscusso della gestione della conoscenza per i team CS del mercato medio" — non "Migliorare la knowledge base". L'obiettivo dovrebbe creare focus e motivazione quando letto senza contesto. I Risultati Chiave devono essere basati sull'outcome e misurabili in modo binario: i KR dovrebbero esprimere cosa cambia nel mondo se l'obiettivo viene raggiunto — non cosa farà il team. KR CATTIVO: "Lanciare la funzionalità di ricerca semantica della knowledge base" (attività). KR BUONO: "Ridurre il tasso di ricerca con risultati nulli della knowledge base dal 18% a meno dell'8% entro il Q4" (outcome). Il KR cattivo può essere completato lanciando una funzionalità difettosa; il KR buono è completabile solo se la funzionalità funziona effettivamente. Il principio del 70% di "stretch": gli OKR dovrebbero essere impostati a un livello in cui raggiungere il 100% sarebbe una sorpresa — i team che raggiungono sempre il 100% dei loro OKR li stanno impostando in modo troppo sicuro. L'ideale è un raggiungimento del 70-80%, indicando sia una definizione ambiziosa degli obiettivi sia un progresso genuino. Anti-pattern da eliminare: OKR che sono KPI con obiettivi (mantenere una metrica vs. migliorarla); OKR che sono progetti travestiti da outcome; troppi OKR (> 3 obiettivi e > 4-5 KR per team per trimestre diluiscono il focus invece di crearlo).
?
Come vengono gli OKR cascati dal livello aziendale al livello di team senza creare un sistema rigido top-down?
Il cascading degli OKR collega gli OKR dei singoli team agli OKR a livello aziendale a cui contribuiscono — creando allineamento senza micromanagement. Principi di cascading: OKR aziendali per primi: il team esecutivo definisce 3-5 OKR a livello aziendale per il trimestre prima che i team scrivano i propri. Derivazione degli OKR di team: i team identificano come il loro lavoro contribuisce agli OKR aziendali — i loro obiettivi dovrebbero essere la versione a livello di team del contributo a uno o più obiettivi aziendali. Questo è "allineato" non "dettato" — i team hanno autonomia nel definire come contribuiscono. Alcuni OKR di team potrebbero non mappare a un OKR aziendale (lavoro di infrastruttura, sviluppo del team) — questi sono validi ma dovrebbero essere una minoranza. Evitare la trappola del cascading: richiedere che ogni KR di team si colleghi matematicamente a un KR aziendale crea una rigidità burocratica che costringe i team a distorcere il loro lavoro per adattarsi all'aggregazione. La connessione dovrebbe essere esplicita ma qualitativa ("il KR del nostro team contribuisce al KR X aziendale perché la riduzione dell'AHT contribuisce direttamente alla riduzione del CPT"). Revisioni di allineamento degli OKR: a metà trimestre, una revisione degli OKR inter-team (facilitata da Product Ops) identifica le interdipendenze — dove il KR di un team dipende dalla consegna di un altro team. Far emergere queste dipendenze previene sorprese di fine trimestre in cui un team raggiunge il proprio lavoro contributivo ma il KR non è raggiungibile perché il team dipendente non ha consegnato in tempo.
?
Come dovrebbero essere valutati gli OKR a fine trimestre e quali decisioni dovrebbe informare la valutazione?
La valutazione degli OKR (chiamata anche "scoring") a fine trimestre è una valutazione onesta del progresso — non una revisione delle prestazioni. La distinzione è importante perché confondere i punteggi degli OKR con la valutazione delle prestazioni porta i team a impostare OKR sicuri piuttosto che ambiziosi. Approcci di valutazione: Scala 0.0–1.0: ogni KR è valutato da 0 (nessun progresso) a 1.0 (completamente raggiunto). Il framework OKR originale di Google mira a 0.7 come punteggio medio: 0.0–0.3 = troppo ambizioso o nessun progresso; 0.4–0.6 = progresso significativo ma insufficiente; 0.7–0.9 = eccellente, leggermente "stretched"; 1.0 = raggiunto o impostato in modo troppo sicuro. Soglia binaria: per i KR con una misurazione specifica definita (ridurre X da Y a Z), la valutazione è semplice: misurare la metrica alla fine del trimestre e assegnare un punteggio in base a quanto del miglioramento dichiarato è stato raggiunto (punteggio = miglioramento effettivo / miglioramento target). Decisioni post-valutazione: i punteggi degli OKR informano quattro decisioni. Decisioni sull'obiettivo (ci siamo avvicinati abbastanza da considerare questo obiettivo direzionalmente raggiunto? Continuiamo con esso il prossimo trimestre o cambiamo?); Decisioni sullo scope (i KR sono stati impostati in modo troppo ambizioso o troppo sicuro? Usare questa calibrazione nella scrittura degli OKR del prossimo trimestre); Decisioni sull'allocazione delle risorse (quali OKR di team abbiamo raggiunto? Quel team potrebbe essere pronto per una sfida più grande); Decisioni su cosa celebrare (0.7+ su un KR "stretch" merita di essere menzionato nell'all-hands — la visibilità del raggiungimento degli OKR crea una cultura attorno alla definizione di obiettivi ambiziosi).
Sfida di Conoscenza
Hai padroneggiato Implementazione degli OKR per Prodotto e Operazioni? Ora prova a indovinare la parola di 5 lettere correlata!
Digita o usa la tastiera