Valutazione delle prestazioni degli sviluppatori software: 6 esempi di feedback
Il feedback concreto sulle prestazioni, spesso sotto forma di “Performance Review”, svolge un ruolo centrale nello sviluppo professionale degli sviluppatori di software. In questo articolo mostriamo alcuni esempi pratici su come fornire feedback agli sviluppatori di software in diverse situazioni, come colloqui con i dipendenti, valutazioni annuali dei dipendenti o valutazioni delle prestazioni, ovvero in qualsiasi forma di colloquio e contatto diretto.
L’importanza del feedback per gli sviluppatori di software
Perché il feedback è così importante (e difficile) per gli sviluppatori di software?
Feedback motivante per sviluppatori di software introversi
Gli sviluppatori di software sono tradizionalmente più interessati a lavorare sui dettagli tecnici che a lavorare con altre persone. Può quindi essere una sfida per i manager comunicare il feedback in modo efficace e motivante, soprattutto con gli sviluppatori di software più introversi.
In qualità di manager di sviluppatori software, tuttavia, devi imparare a comunicare feedback positivi e negativi in modo costruttivo durante i colloqui di valutazione, in modo che gli sviluppatori software siano effettivamente motivati a realizzare il potenziale di sviluppo individuato. Gli esempi di feedback riportati in questo articolo ti aiuteranno a farlo.
Se ti interessa un’introduzione generale agli incontri regolari one-to-one, dai un’occhiata al nostro post sull’argomento: Una guida: 6 consigli per conversazioni 1 a 1 di successo.
Attenzione: valutare gli sviluppatori di software individualmente
Per tua informazione: gli studi dimostrano che gli sviluppatori di software sono tradizionalmente più introversi. Tuttavia, la tendenza è quella di avere tipi di personalità più diversi tra gli sviluppatori di software. Per questo motivo devi sempre esaminare e valutare quale tipo di personalità siede di fronte a te e comunicare di conseguenza.
Fonte: Evoluzione del profilo di personalità degli ingegneri del software
Feedback: Domande e sondaggi
Domande e un sondaggio per le interviste di feedback
Colloquio di valutazione per sviluppatori software: domande tipiche
Un avvertimento prima di fornirti molti esempi, modelli e frasi per il tuo colloquio con lo sviluppatore di software: naturalmente, in molte situazioni è utile guidare attraverso domande per verificare innanzitutto la comprensione comune dello status quo, non solo nel settore IT.
Ecco perché ho raccolto alcune domande per la valutazione dei dipendenti che sviluppano software:
🎯 Domande individuali per sviluppatori di software: focus
- Cosa interrompe la tua concentrazione durante il lavoro?
- Quando hai provato l'ultima volta uno stato di flow al lavoro? Quanto è facile per te entrare nel flow?
- Quando e su cosa hai notato di aver superato il tuo "Work In Progress Limit" personale? Cosa potremmo cambiare per aiutarti a raggiungere un WIP adeguato in futuro?
- Come sono distribuiti i contributi verbali nel vostro team? Come rifletti sul tuo ruolo in questo?
- Chi sono i nostri clienti come azienda e in che modo il tuo lavoro contribuisce in modo specifico a soddisfare le esigenze dei clienti?
- Quali sono le cose che vorresti imparare pensando ai tuoi colleghi all'interno e all'esterno dell'azienda?
Questo dovrebbe darti una buona idea di come affrontare un colloquio di valutazione in modo intelligente. Se desideri un’indagine specifica, posso fornirti un modello iniziale.
Colloquio di valutazione per sviluppatori di software: un’indagine
Le indagini corrispondenti possono aiutare a rendere misurabile lo sviluppo degli sviluppatori di software nel tempo.
Tuttavia, possono anche fungere da base interattiva per una discussione comune.
Il seguente sondaggio si concentra su quattro diverse aree importanti per gli sviluppatori di software. Queste affermazioni sono solitamente valutate su una scala che va, ad esempio, da 1 (fortemente in disaccordo) a 7 (fortemente d’accordo).
🪞Sondaggio per il colloquio con i dipendenti: per sviluppatori di software
- Metto in discussione il nostro lavoro in base alla mia comprensione dei nostri #TeamZiele e delle esigenze dei nostri #Kunden.
- Contribuisco in modo proattivo al miglioramento continuo del nostro team. #TeamPlay
- Conosco le sfide e i problemi dei nostri #Kunden.
- I miei compiti lavorativi di solito progrediscono molto rapidamente, anche quando è necessario un #Feedback esterno.
Nota: in questo modello di colloquio con i dipendenti, il consenso agli elementi di Health Check (questionario) viene richiesto su una scala da 1 a 7.
Come detto, nel software Echometer One-on-One troverai molti modelli che ti aiutano a sviluppare ulteriormente i dipendenti nei colloqui con i dipendenti. Soprattutto per i team agili, ci sono anche modelli che sono in parte interattivi e visivi. Puoi trovare un semplice esempio qui: dai un’occhiata al nostro strumento tramite il pulsante in basso.
Modello di colloquio individuale Software Echometer
- Dai un'occhiata alle aree indicate qui. Secondo te, dove tu e il tuo team avete il maggiore potenziale di miglioramento?
Fonte: Software per riunioni individuali Echometer
Come puoi vedere dal pulsante verde, puoi utilizzare gratuitamente questi modelli anche nel nostro strumento per incontri 1 a 1 1 Echometer. Abbiamo anche molti altri modelli di domande e interi modelli di coaching.
Nel nostro blog c’è un altro articolo, se ti interessano modelli dettagliati per diversi incontri individuali (ad es. settimanali, annuali, 1-1 con dipendenti difficili…): 15 modelli di riunione 1-1 da modificare (gratis) .
Ma ora proseguiamo con il testo: passiamo a esempi concreti e frasi per il feedback agli sviluppatori di software.
Modello per il feedback agli sviluppatori di software
Modello generale per il feedback agli sviluppatori\* di software
Evita i classici metodi di feedback come il sandwich di feedback.
Spesso, i modelli per il feedback nelle conversazioni individuali si basano sul metodo del panino. Si prega di evitarlo con gli sviluppatori di software. I “giri di parole” nelle discussioni con i dipendenti non aiutano nessuno e proprio gli sviluppatori di software spesso reagiscono in modo allergico a tali metodi (vedi: Critiche al metodo sandwich per il feedback).
Gli sviluppatori di software di solito si rendono conto, quando i manager danno un generico feedback positivo, che si tratta solo di uno strumento per far sentire meglio l’altra persona.
Fortunatamente, anche questo funziona meglio.
Radical Candor: il metodo di feedback che funziona meglio per gli sviluppatori di software
Invece di confezionare il tuo feedback in un meeting individuale con chiacchiere inutili in un panino di feedback, ti consiglio il metodo Radical Candor come base per il tuo modello di feedback. A proposito, non è utile solo nel settore dell’IT del software, ma anche in ambito privato: approfondiamo la questione.
Il candore radicale significa dare un feedback il più possibile onesto e diretto nei colloqui di valutazione. Allo stesso tempo, significa anche mostrare empatia e concentrarsi sul benessere dell’altra persona. Il candore radicale dimostra che non è necessario scegliere l’uno o l’altro: O diretto e onesto, o empatico e premuroso. Al contrario, puoi fare entrambe le cose allo stesso tempo:
Altro sotto: Che cos’è il candore radicale?
Gli sviluppatori di software ti saranno grati se andrai dritto al punto con un feedback negativo.
Modello di feedback per gli sviluppatori di software basato su Radical Candor
Questo modello si basa sul modello SBI (Situazione, Comportamento, Impatto). Ti aiuta a comunicare in modo sincero, diretto e allo stesso tempo apprezzabile.
Vedi anche “Playbook per dare un feedback”
Ecco le istruzioni per le singole parti del modello di feedback:
Modello di feedback parte 1: preparazione in anticipo
Prima di dare un feedback, prenditi qualche minuto per riflettere sui seguenti punti:
- Situazione: a quale situazione ti riferisci nello specifico?
- Comportamento: Quale comportamento hai osservato nella persona?
- Impatto: che impatto ha avuto il comportamento della persona (su di te e sugli altri)?
- Desiderio: Quale condizione vuoi raggiungere e perché? (Attenzione: non si tratta di desiderare direttamente un determinato comportamento, che fa parte della misura (vedi sotto). Si tratta piuttosto del contesto più ampio del perché l’impatto è un problema per te.)
- Azione: quali suggerimenti hai per la persona? Quali cambiamenti nel comportamento potrebbero avvicinarci allo stato desiderato? Quale supporto puoi offrire?
È meglio scrivere brevemente i punti in modo da non dimenticare nulla durante la conversazione.
Modello di feedback parte 2: iniziare la conversazione
Invece di iniziare con una lunga riunione individuale, puoi partire direttamente dalla situazione come spunto di conversazione:
- “Volevo parlarti della situazione in cui ci siamo trovati quando…”.
Descrivi la situazione e poi chiedi:
- “Ti ricordi ancora la situazione?”.
Modello di feedback parte 3: Comportamento
Poi potrai affrontare il comportamento della persona che hai osservato durante il colloquio di valutazione:
- “Hai scosso la testa per la situazione e hai detto…”.
Prima di parlare dell’effetto, dai all’altra persona la possibilità di commentare la tua percezione o il tuo ricordo:
- “Sto riflettendo correttamente dal tuo punto di vista?”.
Lascia alla persona lo spazio per descrivere la sua prospettiva sulle cose. Cerca di lasciare che entrambe le prospettive siano presenti nella stanza su un piano di parità, senza commentarle. Limitati a fare domande sul contenuto della prospettiva dell’altra persona.
Modello di feedback parte 4: Impatto
Solo in questa parte si tratta di discutere gli effetti del comportamento. All’inizio rimani il più obiettivo possibile:
- “La mia impressione è che dopo il tuo [comportamento osservato], il mio collega Marc sembrava molto offeso e non era più disposto a continuare a lavorare con noi in modo cooperativo”.
Tuttavia, se gli effetti si ripercuotono anche su di te, è importante condividere anche questo aspetto. Ovviamente devi sempre rimanere professionale, ma puoi anche mostrare il tuo lato umano:
- “Io stesso mi sono sentito onestamente in imbarazzo in quella situazione e da quel momento in poi ho trovato la conversazione sgradevole”.
Modello di feedback, parte 5: desiderio
Esprimi la tua richiesta specifica in questa parte del colloquio di valutazione:
- “Per me è importante trovare una buona base di collaborazione con il nostro collega Marc”.
Ricontestualizza il tutto:
- “E oltre a questo, è mia grande esigenza lavorare insieme per garantire il mantenimento di una buona cooperazione e di relazioni con tutte le aree specializzate limitrofe.”
Fai anche riferimento a obiettivi rilevanti che spieghino perché hai questo desiderio:
- “Solo grazie a un buon rapporto possiamo raggiungere i nostri obiettivi come squadra in questa azienda. Per me è anche importante godere di una buona reputazione come team all’interno dell’azienda”.
"Mi piace il dipendente, ma non fornisce le prestazioni desiderate. Come posso affrontare la questione nelle riunioni 1:1?"
Risolvi questa sfida
"Spesso non so se sono stato troppo duro – o troppo morbido – nei miei 1:1 per avere un impatto positivo".
Risolvi questa sfida
"Non riesco a riconoscere alcuno schema o tendenza nei miei 1:1. Tutto sembra isolato".
Risolvi questa sfidaModello di feedback parte 6: Misura
Prima di presentare le tue idee di soluzione, puoi fare delle domande aperte durante la conversazione individuale:
- “Ho alcune idee in merito. Ma prima vorrei sentire la tua opinione: Come pensi che possiamo raggiungere l’obiettivo?”.
Potrete quindi condividere le vostre idee. Concordate insieme un follow-up vincolante e specificamente definito. Mettilo per iscritto.
Modello di feedback parte 7: Rifiuto
Chiedi se il colloquio di valutazione è stato utile per l’altra persona e se ha delle domande in sospeso. Organizza un check-in per la prossima volta che parlerete dell’argomento.
Mostra il tuo apprezzamento per il dialogo aperto e ringrazia la persona per la sua comprensione e collaborazione.
Modello di feedback parte 8: Rifletti sul tuo feedback in modo retrospettivo
Alla fine di ogni sessione di feedback, dovresti porti la seguente domanda:
- Onestà: ho condiviso il mio feedback in modo onesto e il più possibile trasparente?
- Apprezzamento: la persona si sente apprezzata dal mio feedback?
Se puoi rispondere “sì” a tutte le domande, la tua sessione di feedback è andata molto bene. In caso contrario, non preoccuparti. Rifletti su come formulare le cose in modo diverso in futuro. E ancora, la maggior parte di questi consigli non si applica solo al settore informatico del software.
A questo punto, vorrei sottolineare che esiste anche un software che semplifica le discussioni di feedback e il coaching a lungo termine degli sviluppatori di software.
Il nostro software per le riunioni one-to-one ti offre diversi modelli per le riunioni dei dipendenti con gli sviluppatori di software e rende addirittura misurabile lo sviluppo dei dipendenti. Dai un’occhiata al nostro strumento e prova il seguente modello:
Niente chiacchiere, niente pause imbarazzanti. Questo modello 1:1 funziona sempre.
💬 Dal modello:
- Di quale risultato è orgoglioso e forse non l'ho notato?
- Quale piccolo cambiamento migliorerebbe immediatamente il vostro lavoro?
- A cosa vorreste dedicare più tempo al lavoro?
…
Ora iniziamo con l’aiuto di questo modello di colloquio di valutazione e facciamo qualche esempio pratico!
Esempi di feedback di incontri 1:1: Qualità del codice, proprietà
Esempi di feedback agli sviluppatori di software in incontri individuali
Esempio di feedback agli sviluppatori di software in incontri 1 a 1: qualità del codice
Con Tanja 👩🏼🦰 nel ruolo di team leader e Marc 👨🏽 nel ruolo di dipendente.
Descrivi la situazione
“Nella nostra ultima code review abbiamo esaminato la tua pull request per l’implementazione della nuova funzionalità nella dashboard. Il codice era funzionalmente corretto e soddisfaceva i requisiti.”
“Sì, ricordo!”
Comportamento osservato
“Ho commentato i passaggi che erano piuttosto complessi e difficili da leggere. Ad esempio, c’era un metodo di oltre 50 righe che combinava diverse responsabilità. Tuttavia, hai commentato questo commento solo in modo superficiale e non hai approfondito l’argomento”.
“A me il commento sembrava un suggerimento facoltativo. Sembrava troppo dispendioso in termini di tempo cambiare di nuovo la soluzione”.
Impatto
“Ad ogni modo, il tuo commento mi ha reso un po’ frustrato ad essere sincero e, invece di insistere per ottenere una correzione da parte tua, ho semplicemente migliorato il metodo da solo in seguito perché comunque avevo già pensato al codice.”
“Oh, non me ne ero accorto”.
Obiettivo e desiderio
“Il nostro obiettivo comune è garantire che il nostro codice non sia solo funzionale, ma anche manutenibile e facile da capire per tutti”.
“È esattamente come la vedo io!”.
Misure
“Qual è il tuo suggerimento su come migliorare la qualità del codice in questi casi in futuro?”.
“Mi sarebbe d’aiuto se nei commenti fosse più facile capire se un miglioramento è solo suggerito o richiesto”.
“Bene, facciamolo: lo riprenderò nella riunione del team. Inoltre, a mio avviso, è comunque necessario un follow-up da parte tua.”
“Che ne dici di passare direttamente alla programmazione a coppie per il prossimo argomento, in modo che tu possa affinare la mia comprensione dei requisiti per la qualità del codice?”.
Conclusione
“Sembrano due buoni seguiti! Allora continuiamo così. Vorrei fissare in agenda una data per la metà della prossima settimana per iniziare la programmazione in coppia”.
“Va bene, non vedo l’ora!”.
Esempio di feedback agli sviluppatori di software in incontri 1 a 1: Proprietà
Con Tanja 👩🏼🦰 nel ruolo di team leader e Marc 👨🏽 nel ruolo di dipendente.
Descrivi la situazione
«Marc, vorrei parlare con te dell’ultimo compito in cui abbiamo sviluppato la nuova funzionalità per il processo di esportazione. La funzionalità è ora attiva, ma ci sono state alcune difficoltà lungo il percorso.»
“Sì, ricordo. Cosa intendi esattamente?”
Comportamento osservato
“Ho notato che ci sono stati molti ritardi dopo che il codice è stato consegnato per il test. Ad esempio, alcuni commenti dei colleghi del QA non hanno avuto risposta per giorni. Mi è anche capitato di dovervi ricordare due volte di una revisione mancante”.
“Capisco. A dire il vero, c’erano parecchie cose in ballo e pensavo che i test sarebbero proseguiti in parallelo”.
Impatto
“In ogni caso, il risultato è stato che abbiamo dovuto rimandare il nostro intervento a causa di questo problema”.
“Oh, non me ne ero nemmeno accorto. Pensavo che ti saresti fatto sentire se ci fosse stata un’urgenza”.
Obiettivo e desiderio
“Il nostro obiettivo è ridurre al minimo i ritardi inutili e far sì che gli sviluppatori adottino una mentalità di responsabilità durante l’implementazione. Questo significa che tutti si assicurano attivamente che il loro ticket arrivi dall’inizio alla fine – e questo include anche la comunicazione con il QA”.
“Capisco cosa intendi. Voglio assolutamente che i processi si svolgano in modo più fluido”.
Misure
“Dal tuo punto di vista, cosa potremmo fare affinché tu possa agire in modo più proattivo e mostrare responsabilità in queste situazioni?”.
“Penso che sarebbe utile stabilire delle aspettative più chiare, ad esempio che io faccia un check-in giornaliero sui problemi aperti durante la fase di test. In questo modo posso assicurarmi che nulla venga lasciato in sospeso”.
“Mi sembra una buona idea. E ti suggerisco, per i prossimi compiti importanti dopo la finalizzazione del codice, di fare un breve piano su come vuoi portare avanti l’argomento fino al lancio. Puoi mostrare il piano a me o a un collega di QA”.
“Sono d’accordo. Così potrò controllare meglio le cose da solo”.
Conclusione
“Ottimo. Registriamo le due misure in questo modo: Fai dei check-in giornalieri durante la fase di test e pianifichi il follow-up per la tua prossima attività principale. È fattibile per te?”.
“Sì, è perfetto. Lo scriverò direttamente nel mio diario”.
“Ottimo. Sono sicuro che questo farà una grande differenza. Nel nostro prossimo incontro individuale daremo un’altra occhiata allo stato delle nostre misure. Grazie!”
Condurre attraverso le domande: modello per gli incontri 1:1
Una saggezza della letteratura manageriale recita: “Guida ponendo domande”. E c’è molto di vero in questo.
Se conduci regolarmente e continuamente riunioni individuali in cui rifletti insieme al dipendente sul tema del feedback (ponendo domande), i problemi non possono “accumularsi”.
Per questo motivo, vorrei fornirti un altro modello che puoi utilizzare nel nostro strumento Echometer con i tuoi dipendenti. In linea di massima, puoi utilizzare questo modello anche su base regolare.
Provali semplicemente cliccando sul pulsante qui sotto (non è necessario il login):
Inizio
- Com'è stata la tua settimana finora?
📊 Aggiornamenti sui progetti
- Come stanno andando i tuoi progetti attuali? Ci sono grandi successi o ostacoli?
- Ci sono sfide tecniche che vorresti discutere o esaminare insieme?
💻 Qualità del codice e sviluppo
- Come ti senti riguardo alla qualità del tuo lavoro ultimamente?
- Ci sono aree in cui vorresti migliorare o acquisire nuove competenze?
🤝 Team, collaborazione e prossimi passi
- Come sta andando la collaborazione nel team? Ci sono lacune di comunicazione?
- Gli strumenti e i processi che utilizziamo supportano efficacemente il tuo lavoro?
- Come immagini la tua carriera nei prossimi uno o due anni?
- Come posso aiutarti ad avere successo?
Conclusione
- Cosa ti entusiasma di più nei prossimi mesi?
- Hai altre domande o dubbi?
⁉️ Controllo dell'umore (sondaggio)
Esempi di feedback per la valutazione delle prestazioni: Lavoro di squadra, titolarità
Esempi di feedback agli sviluppatori di software nella revisione delle prestazioni
Una nota: le tradizionali valutazioni delle prestazioni tendono a essere impopolari sia tra gli sviluppatori di software che tra i manager e molti sostengono che i buoni incontri one-to-one sono sufficienti e dovrebbero sostituire le valutazioni delle prestazioni. Vedi: “Le valutazioni delle prestazioni sono inutili e insulse” di Forbes.
Tuttavia, le valutazioni delle prestazioni sono spesso ancora un formato predeterminato all’interno dell’azienda. Naturalmente, questo non deve impedirti di condurre le valutazioni delle prestazioni come un dialogo a tu per tu con i tuoi dipendenti, invece di limitarti a fare valutazioni dall’alto verso il basso. I seguenti esempi di dialogo one-to-one mostrano come può funzionare.
Nota: come già accennato, i modelli di valutazione dei dipendenti possono ovviamente aiutare a comunicare il feedback in modo costruttivo. Il seguente post del blog può esserti utile se sei più interessato all’argomento: 5 modelli per i check-in periodici dei dipendenti .
Esempio di feedback agli ingegneri del software nelle revisioni delle prestazioni: Lavoro di squadra
Con Tanja 👩🏼🦰 nel ruolo di Team Lead e Marc 👨🏽 nel ruolo di Software Engineer.
Descrivi la situazione
“Quando ho dovuto valutare la voce ‘Lavoro di squadra’ nel tuo modello di valutazione delle prestazioni, purtroppo ho potuto assegnare solo 5 punti su 10 possibili. Vorrei spiegarti questo per darti una giusta possibilit\u00e0 di migliorare in questo punto.”
“Oh, okay. Per favore, aiutami a capire.”
Comportamento osservato
“Ho notato che negli ultimi mesi ci sono state situazioni in cui la collaborazione con il team non è stata ottimale. Ad esempio, nell’ultimo sprint ci sono stati diversi casi in cui hai lavorato da solo su compiti che avrebbero potuto essere risolti meglio insieme ad altri. Un esempio specifico è stato l’integrazione della nuova API. Avevamo pensato di far lavorare insieme te e Alex, ma hai affrontato la maggior parte dei passaggi da solo e hai coinvolto Alex solo in minima parte”.
“Ho pensato che sarebbe stato più efficiente farlo velocemente da solo. Non mi ero reso conto che questo fosse considerato un problema”.
Impatto
“Tuttavia, questo ha portato a una perdita di trasparenza all’interno del team. In seguito Alex ha avuto difficoltà a partecipare a compiti correlati perché non sapeva esattamente come fosse impostata l’API. Anche altri membri del team mi hanno detto che a volte non si sentivano abbastanza coinvolti e che avevano difficoltà a ricevere supporto da te quando avevano delle domande.”
“Questo mi sorprende, ad essere sincero. Pensavo di dare una mano quando me l’avessero chiesto”.
Obiettivo e desiderio
“Il nostro obiettivo come team non è solo quello di lavorare in modo efficiente, ma anche di condividere le conoscenze e coinvolgere tutti. Questo rafforza la collaborazione e garantisce che tutti noi possiamo rappresentarci a vicenda. In futuro, vorrei che tu sfruttassi maggiormente il tuo ruolo di portatore di conoscenza all’interno del team per condividere attivamente le conoscenze e responsabilizzare gli altri membri del team. La produttività del team è più importante delle prestazioni individuali”.
“Ok, capisco cosa intendi. Credo di essermi concentrato troppo sulla mia produttività fino ad ora”.
Misure
“Cosa potrebbe aiutarti a prestare maggiore attenzione al coinvolgimento del team nel tuo lavoro e alla condivisione delle conoscenze?”.
“Potrei prendere l’abitudine di chiarire fin dall’inizio chi può lavorare sui compiti più importanti e come. Forse potremmo anche organizzare qualcosa come un kick-off per i compiti, al fine di concordare le decisioni di massima sull’architettura e identificare i compiti che qualcun altro dovrebbe svolgere da solo o che dovremmo svolgere in coppia”.
“Mi sembra una buona idea. Mi è venuta anche un’idea: che ne dici di prendere l’abitudine di non limitarti a riferire i progressi compiuti durante le nostre riunioni settimanali del team, ma di fornire attivamente approfondimenti sul codice e sulle decisioni architettoniche?”.
“È un’ottima osservazione. Questo potrebbe rendere più facile per i nostri colleghi inesperti lavorare sul mio codice in seguito”.
Conclusione
“Ottimo. Allora registreremo i follow-up nel nostro modello per la valutazione delle prestazioni:
- D’ora in poi, condividerai in modo proattivo le tue conoscenze e le tue decisioni architettoniche con il team delle Settimane.
- D’ora in poi, farai un kick-off con un altro sviluppatore per i tuoi progetti, in modo che possiate elaborare insieme la soluzione e dividervi l’implementazione.
“Mi sembra una buona idea”.
“OK. Annoterei entrambe le misure per una revisione tra due mesi. Poi possiamo discutere lo stato durante il nostro colloquio individuale e vedere come procedere.”
“Sì, e poi vediamo se riesci a migliorare il tuo punteggio di ‘lavoro di squadra’. Vorrei ottenere almeno un 8 su 10”.
“Sono felice di sentirlo! Credo assolutamente che sia realistico e ti sosterrò ogni volta che potrò”.
“Grazie!”
Esempio di feedback alle valutazioni delle prestazioni degli ingegneri del software: Proprietà
Passiamo al prossimo esempio di conversazione one-to-one, che riguarda il feedback allo sviluppatore di software sul tema della proprietà.
Come sempre con Tanja 👩🏼🦰 nel ruolo di Team Lead e Marc 👨🏽 nel ruolo di Software Engineer.
Descrivi la situazione
“Quando ho dovuto valutare la voce ‘Responsabilit\u00e0’ nel tuo modello di valutazione delle prestazioni, ho potuto assegnare solo 6 punti su 10. Vorrei spiegarti perch\u00e9 \u00e8 cos\u00ec e darti la possibilit\u00e0 di svilupparti ulteriormente in questo settore.”
“Wow, sono un po’ sorpreso. Dopotutto, ho collaborato a cos\u00ec tanti progetti come quasi nessun altro nel team. Per favore, spiegamelo.”
Comportamento osservato
“Negli ultimi mesi ho notato che spesso i tuoi compiti subiscono dei ritardi. Ci sono diversi esempi in cui i commenti del QA o le revisioni del codice sono rimasti senza risposta per un lungo periodo di tempo. Di conseguenza, i tuoi argomenti sono stati resi operativi solo dopo settimane di ritardi. Un esempio specifico è la correzione del bug dell’esportazione. Hai risposto ai commenti del QA solo dopo ripetute richieste e ci sono volute ben tre settimane prima che le modifiche venissero rese operative”.
“Sì, mi ricordo. Stavo lavorando contemporaneamente su altri due argomenti e non ho avuto modo di inserire il feedback così velocemente”.
Impatto
“Questo ha avuto un impatto sulla velocità e sulla produttività dell’intero team. Il QA ha dovuto seguire più volte il problema, con conseguenti problemi di capacità. Anche il piano di rilascio ha dovuto essere posticipato. Inoltre, si ha l’impressione che non ci si assuma la piena responsabilità di portare a termine i propri problemi, il che mette a dura prova le dinamiche del team. Alcuni membri del team mi hanno detto che non sono sicuri di poter contare su di te quando si tratta di dipendenze”.
“Oh, mi dispiace per questo. Non me ne ero accorto. Ho cercato di svolgere i compiti in parallelo, ma a quanto pare non ha funzionato bene”.
Obiettivo e desiderio
“Il mio obiettivo è che tu ti concentri su un numero minore di argomenti, ma che ti assuma la piena responsabilità di ogni compito dall’inizio alla fine. Ciò significa che non solo scriverai il codice iniziale, ma ti assicurerai anche che il feedback del QA venga elaborato tempestivamente e che l’argomento venga rispettato. In questo modo, possiamo evitare che le attività rimangano aperte più a lungo e ne blocchino altre”.
“Questo ha senso. Spesso mi sentivo sopraffatto perché avevo troppi argomenti allo stesso tempo. Forse è davvero meglio concentrarsi su un numero minore di compiti”.
Misure
“Come possiamo fare in modo che tu ti concentri su alcuni argomenti e ti assuma la responsabilità di implementarli completamente?”.
“Potrei cercare di limitarmi a un massimo di due argomenti per ogni sprint e non lavorare mai a più di tre argomenti contemporaneamente. Dovrei anche bloccare degli spazi fissi nel mio calendario per lavorare regolarmente ai commenti e alle revisioni, in modo da non lasciare nulla di intentato”.
“Mi sembra ragionevole. Inoltre, credo che sarebbe opportuno che tu potessi chiedere aiuto in modo proattivo nei nostri stand-up se stai lavorando su troppi argomenti allo stesso tempo. Di solito c’è qualcuno che può sostituirti in un argomento”.
“OK, giusto”.
Conclusione
Fissiamo queste misure come obiettivo per i prossimi due mesi:
Meno lavoro in parallelo:
- Ti occupi di un massimo di due argomenti per ogni sprint e non lavori su più di 3 argomenti in parallelo.
- Esigere un supporto attivo da parte del team durante gli stand-up
- Slot fissi nel calendario per elaborare commenti e revisioni.
“Sembra realistico. Facciamo così”.
“Ottimo. Tra due mesi, in occasione della valutazione delle prestazioni, vedremo se queste misure hanno funzionato e se potremo alzare di nuovo il tuo punteggio nella valutazione delle prestazioni per la ‘Proprietà’”.
“Grazie, Tanja. Cercherò di metterlo in pratica. Di solito ottengo sempre il massimo dei voti per quanto riguarda la ‘proprietà’. Pensi che riuscirò a raggiungere il massimo entro la prossima valutazione delle prestazioni?”.
“Sono soddisfatto di questo. Sì, credo che un rapido miglioramento sia assolutamente raggiungibile con queste misure. Discutiamo lo stato di avanzamento e se hai bisogno di supporto durante i nostri incontri quindicinali”.
“Grazie! Sì, sarei molto felice se riuscissimo a ottenere un miglioramento evidente entro poche settimane!”.
Dialogo annuale Esempi di feedback: Desiderio di cambiare ruolo
Esempi di feedback agli sviluppatori di software nella revisione annuale
Se durante l’anno hai già incontri regolari one-to-one o revisioni delle prestazioni con i tuoi sviluppatori, probabilmente non hai più bisogno di incontri annuali dettagliati. Lo scambio di prestazioni, feedback e ulteriori sviluppi dovrebbe già essere un dialogo continuo:
Tuttavia, ci sono aziende che richiedono una classica valutazione annuale.
💡
Se, come manager di sviluppatori software, hai già incontri regolari 1:1 o revisioni delle prestazioni, la revisione annuale dovrebbe essere solo una formalità:
Lo sviluppatore del software dovrebbe essere già a conoscenza del feedback e dovrebbe già lavorare sul potenziale di sviluppo.
Quindi, se come manager di sviluppatori software devi adempiere alla formalità di un incontro di fine anno (eventualmente in aggiunta ai regolari incontri one-to-one), vediamo anche un esempio di valutazione annuale di un dipendente con uno sviluppatore software.
A proposito, un altro consiglio a questo punto: Se il tuo primo incontro individuale con un nuovo dipendente è alle porte, ti consiglio il nostro articolo sull’argomento: 5 consigli per gli incontri individuali con i nuovi dipendenti .
Esempio di agenda e modello per un incontro annuale con uno sviluppatore di software
- Revisione e prestazioni
- Successi: quali progetti o compiti sono andati bene? Dove sono state superate le aspettative?
- Sfide: Cosa non ha funzionato bene e perché? Come si possono superare queste sfide in futuro?
- Riflessione: come vede lo sviluppatore le proprie prestazioni? Che feedback ha il team o il manager?
- Cooperazione e cultura di squadra
- Comunicazione: come viene percepita la collaborazione all’interno del team e con il manager?
- Atmosfera lavorativa: c’è un potenziale di miglioramento nella cultura del team o nell’ambiente di lavoro?
- Feedback sulla leadership: come può il manager supportare meglio lo sviluppatore?
- Feedback dello sviluppatore: Ci sono suggerimenti per migliorare i processi, gli strumenti o la cultura del lavoro?
- Equilibrio vita-lavoro: come ti senti rispetto al tuo attuale carico di lavoro? Ci sono straordinari o fattori di stress?
- Risorse: gli strumenti, i processi e le condizioni quadro sono sufficienti per lavorare in modo efficiente?
- Competenze, obiettivi e sviluppo
- Punti di forza: Quali competenze tecniche, metodologiche o sociali caratterizzano lo sviluppatore?
- Formazione continua: Quali nuove tecnologie o competenze vuole apprendere lo sviluppatore? Ci sono corsi, conferenze o progetti pertinenti?
- Obiettivi di carriera: A quale posizione o responsabilità mira lo sviluppatore nel medio-lungo termine? Quali sono le tappe per arrivarci?
- Focus sul progetto: su quali progetti o tecnologie lo sviluppatore vorrebbe lavorare più intensamente?
- Retribuzione
- Remunerazione legata ai risultati: è necessario adeguare lo stipendio o i bonus?
- Conclusione
- Obiettivi a breve termine: Quali sono gli obiettivi specifici da fissare per il prossimo anno?
- Accordi: Quali sono i prossimi check-in per le rispettive misure?
Il seguente è un tipico esempio di feedback all’interno di una valutazione di fine anno o di una valutazione annuale delle prestazioni: Richiesta del dipendente di cambiare ruolo.
Esempio di feedback nella riunione annuale: Desiderio di cambiare ruolo
Con Tanja 👩🏼🦰 nel ruolo di Team Lead e Marc 👨🏽 nel ruolo di Software Engineer.
Ingresso e situazione
“Marc, sono contento che oggi possiamo parlare del tuo feedback annuale e dei tuoi obiettivi. Ci sono argomenti specifici che sono particolarmente importanti per te?”
“S\u00ec, ho riflettuto sul mio sviluppo professionale. Potrei immaginare di evolvere verso l’architettura del software. Questo argomento mi attrae da tempo e vorrei approfondire le decisioni sull’architettura e la gestione strategica della tecnologia.”
“È emozionante, Marc. Mi fa piacere che tu abbia degli obiettivi così chiari. Parliamo di come possiamo prepararti a raggiungerli. Ci sono alcuni punti che credo tu debba sviluppare ulteriormente prima di fare il passo successivo”.
Fornisci un feedback
“Innanzitutto, vorrei sottolineare che quest’anno avete fatto molti progressi, soprattutto per quanto riguarda la qualità delle vostre implementazioni e la gestione delle nuove tecnologie. Avete anche dimostrato di avere un occhio di riguardo per il quadro generale, ad esempio con l’introduzione del nuovo sistema di caching”.
“Grazie, mi fa piacere sentirlo!”.
“Quando penso al ruolo di un architetto del software, tuttavia, ci sono ancora alcuni requisiti che non credo siano pienamente soddisfatti. Ad esempio, comunicare con il team e coinvolgere gli altri nelle decisioni tecniche è una componente fondamentale. Vedo ancora del potenziale per te in questo ambito. Spesso prendi decisioni in modo indipendente senza coinvolgere il team con sufficiente anticipo”.
“Ok, lo capisco. Non volevo trattenere nessuno a volte, ma mi rendo conto che non è l’ideale per il ruolo di architetto”.
Obiettivo e desiderio
“Esattamente. Un architetto software è anche un coach e un comunicatore. Si tratta di coinvolgere gli altri, comunicare concetti tecnici e sviluppare soluzioni insieme”.
“Questo ha senso. Mi rendo anche conto che non sono ancora in grado di comunicare in modo efficace i miei pensieri sull’architettura ai membri del mio team”.
Misure del piano
“Penso che possiamo lavorare insieme su questo aspetto in modo che tu possa qualificarti per il ruolo nei prossimi 6 mesi. Che ne dici di definire misure concrete?”
“Mi piacerebbe molto. Cosa hai in mente?”
“Soprattutto, vorrei che tu moderassi il processo decisionale per l’architettura del software invece di prendere le decisioni da solo. Che ne dici di moderare un kick-off sull’architettura per ciascuno dei prossimi argomenti principali? L’obiettivo sarebbe quello di supportare i colleghi nel processo decisionale e poi lasciare che siano loro stessi a implementare la soluzione”.
“Sembra buono. In questo modo imparo a esercitare la mia influenza come coach invece di implementare tutto da solo.”
“Inoltre, immagino che ci siano buoni corsi per preparare gli sviluppatori al ruolo di architetto software. In questi corsi, oltre alle hard skill, ci saranno sicuramente anche le soft skill necessarie per il ruolo.”
“S\u00ec, in realt\u00e0 ho gi\u00e0 cercato un corso.”
Conclusione
“Ottimo, allora annoter\u00f2 quanto segue per il nostro colloquio annuale:
- Obiettivo di sviluppo: architetto di software
- Misure:
- Moderazione di kick-off di architettura in un team
- Partecipazione a un corso per architetti software
Naturalmente parleremo continuamente di questi argomenti nei nostri incontri individuali, ma il prossimo check-in ufficiale sar\u00e0 alla nostra valutazione delle prestazioni tra 3 mesi.
“Sembra buono. Entro allora dovremmo aver gi\u00e0 raggiunto qualcosa.”
“Lo penso anch’io! Se nel frattempo ti vengono in mente altre cose in cui posso supportarti su questo argomento, non esitare a parlarmene in qualsiasi momento.”
“Possiamo riparlare del mio auspicato cambio di ruolo tra 3 mesi?”
“Certo, non posso prometterti nulla per quanto riguarda il cambio di ruolo. Ma ho preso nota del tuo desiderio e cercher\u00f2 di supportarti al meglio.”
“Grazie!”
Conclusione: feedback agli ingegneri del software in riunioni 1:1, revisioni delle prestazioni e valutazioni annuali.
Conclusione: feedback motivante per gli sviluppatori di software
Gli esempi e i modelli dimostrano che non deve essere così difficile dare un feedback motivante agli sviluppatori di software durante gli incontri individuali e le riunioni di fine anno, giusto? Rimani autentico e benevolo, non menare il can per l’aia e dimostra di essere interessato a una soluzione comune.
Se riesci a implementare la “Radical Candor” nelle tue conversazioni con i dipendenti e oltre, mostrando apprezzamento e onest\u00e0, la reazione potrebbe essere ancora pi\u00f9 positiva e costruttiva di quanto pensi.
Buona fortuna per le prossime sessioni di feedback!
Se ti piacciono gli hack che ti semplificano la vita, ti consiglio il nostro software Echometer. Puoi provarlo in modo completamente gratuito.
Il nostro software per le riunioni one-to-one ti offre diversi modelli per le riunioni dei dipendenti con gli sviluppatori di software e rende addirittura misurabile lo sviluppo dei dipendenti. Dai un’occhiata al nostro strumento e prova il seguente modello:
Niente chiacchiere, niente pause imbarazzanti. Questo modello 1:1 funziona sempre.
💬 Dal modello:
- Di quale risultato è orgoglioso e forse non l'ho notato?
- Quale piccolo cambiamento migliorerebbe immediatamente il vostro lavoro?
- A cosa vorreste dedicare più tempo al lavoro?
…
