Ohjelmistokehittäjän tuloskatselmus: 6 esimerkkiä palautteesta
Konkreettiinen palaute suorituksesta, usein “Performance Reviews” -muodossa, on keskeisessä asemassa ohjelmistokehittäjien kehittämisessä. Tässä artikkelissa esitämme käytännönläheisiä esimerkkejä siitä, miten palautetta annetaan ohjelmistokehittäjille erilaisissa tilanteissa, kuten kehityskeskusteluissa, vuotuisissa arvioinneissa tai suoritusarvioinneissa – eli kaikissa kahdenkeskisissä keskusteluissa ja kontakteissa.
Palautteen merkitys ohjelmistokehittäjille
Miksi palaute on niin tärkeää (ja vaikeaa) ohjelmistokehittäjille?
Motivoiva palaute introvertoituneille ohjelmistokehittäjille
Ohjelmistokehittäjät ovat perinteisesti kiinnostuneempia työskentelemään teknisten yksityiskohtien parissa kuin muiden ihmisten kanssa. Siksi esimiesten voi olla haastavaa antaa palautetta tehokkaasti ja motivoivasti, erityisesti introverttien ohjelmistokehittäjien kanssa.
Ohjelmistokehittäjien esimiehenä sinun on kuitenkin opittava välittämään sekä myönteistä että kielteistä palautetta rakentavalla tavalla arviointikeskusteluissa, jotta ohjelmistokehittäjät todella motivoituvat toteuttamaan havaitsemansa kehityspotentiaalin. Seuraavat tässä artikkelissa esitetyt esimerkit palautteesta auttavat sinua tässä.
Jos olet kiinnostunut yleisestä johdannosta säännöllisiin kahdenkeskisiin tapaamisiin, tutustu aihetta käsittelevään postaukseemme: Opas: 6 vinkkiä onnistuneisiin 1-to-1-keskusteluihin.
Huomio: Arvioi ohjelmistokehittäjät yksilöllisesti
Tiedoksi: Tutkimusten mukaan ohjelmistokehittäjät ovat perinteisesti introvertteja. Suuntaus on kuitenkin kohti monipuolisempia persoonallisuustyyppejä ohjelmistokehittäjien keskuudessa. Siksi sinun tulisi aina tutkia ja arvioida, mikä persoonallisuustyyppi sinua vastapäätä istuu, ja viestiä sen mukaisesti.
Lähde: Ohjelmistoinsinöörien persoonallisuusprofiilin kehitys
Palaute: Kysymykset ja kyselyt
Kysymykset ja kysely palautehaastatteluja varten
Ohjelmistokehittäjän arviointikeskustelu: tyypillisiä kysymyksiä
Huomautus, ennen kuin annan sinulle monia esimerkkejä, malleja ja ilmauksia kehityskeskusteluusi ohjelmistokehittäjän kanssa: Monissa tilanteissa on tietysti järkevää ohjata kysymyksillä, jotta varmistetaan ensin yhteinen ymmärrys nykytilasta - ei vain IT-alalla.
Siksi olen koonnut yhteen muutamia kysymyksiä ohjelmistokehittäjien työntekijöiden arviointia varten:
🎯 1 zu 1 Fragen für Softwareentwickler: Fokus
- Was unterbricht deine Konzentration bei der Arbeit?
- Wann hast du bei der Arbeit zuletzt einen Flow-Zustand erlebt? Wie einfach ist es für dich, in den Flow zu kommen?
- Wann und woran hast du schonmal bemerkt, dass du dein persönliches "Work In Progress Limit" überschritten hast? Was könnten wir ändern, um dir in Zukunft zu helfen, ein angemessenes WIP zu erreichen?
- Wie sind die Redebeiträge im Team bei euch verteilt? Wie reflektierst du deine Rolle darin?
- Wer sind unsere Kunden als Unternehmen und wie trägt deine Arbeit speziell dazu bei, die Bedürfnisse der Kunden zu erfüllen?
- Was sind die Dinge, die du lernen möchtest, wenn du an deine Kolleg*innen im Unternehmen und darüber hinaus denkst?
Tämän pitäisi antaa sinulle hyvä käsitys siitä, miten lähestyä tällaista arviointikeskustelua älykkäästi. Jos haluatte myös tietynlaisen kyselyn, voin antaa teille alustavan mallin.
Ohjelmistokehittäjien arviointikeskustelu: tutkimus
Vastaavat tutkimukset voivat auttaa tekemään ohjelmistokehittäjien kehityksestä mitattavissa olevaa ajan mittaan.
Ne voivat kuitenkin toimia myös hyvin vuorovaikutteisena pohjana yhteiselle keskustelulle.
Seuraavassa tutkimuksessa keskitytään neljään eri osa-alueeseen, jotka ovat tärkeitä ohjelmistokehittäjille. Nämä väittämät arvioidaan yleensä asteikolla, joka vaihtelee esimerkiksi yhdestä (täysin eri mieltä) seitsemään (täysin samaa mieltä).
🪞Mitarbeitergespräch Umfrage: Für Softwareentwickler
- Ich hinterfrage unsere Arbeit basierend auf meinem Verständnis unserer #TeamZiele und der Bedürfnisse unserer #Kunden.
- Ich trage proaktiv zur kontinuierlichen Verbesserung unseres Teams bei. #TeamPlay
- Ich kenne die Herausforderungen und Probleme unserer #Kunden.
- Meine Arbeitsaufgaben machen in der Regel sehr schnell Fortschritte, auch wenn externes #Feedback notwendig ist.
Hinweis: Bei dieser Mitarbeitergespräch Vorlage wird die Zustimmung zu den Health Check-Items (Fragebogen) auf einer 1-7er Skala abgefragt.
Kuten sanottu, Echometerin kahdenkeskisestä ohjelmistosta löydät monia malleja, jotka auttavat kehittämään työntekijöitä kehityskeskusteluissa. Erityisesti ketterille tiimeille on myös malleja, jotka on osittain suunniteltu interaktiivisiksi ja visuaalisiksi. Yksinkertaisen esimerkin löydät täältä - tutustu myös työkaluumme alla olevasta painikkeesta.
Eins-zu-Eins Gesprächsvorlage Echometer Software
- Katso tässä lueteltuja alueita. Missä sinulla ja tiimilläsi on mielestäsi eniten kehityspotentiaalia?
Lähde: Echometer 1:1 -kokousohjelmisto
Kuten vihreästä painikkeesta näet, voit jopa käyttää näitä malleja maksutta 1-to-1-kokousvälineessämme Echometer. Meillä on myös monia muita kysymysmalleja ja kokonaisia valmennusmalleja.
Blogissamme on toinen artikkeli, jos olet kiinnostunut yksityiskohtaisista malleista erilaisia kahdenkeskisiä tapaamisia varten (esim. viikoittain, vuosittain, 1-1 vaikeiden työntekijöiden kanssa…): 15 testattua 1-1 kokousmallia muokattavaksi (ilmainen) .
Mutta nyt jatkamme eteenpäin – siirrytään konkreettisiin esimerkkeihin ja ilmaisuihin ohjelmistokehittäjille annettavaa palautetta varten.
Malli palautetta varten ohjelmistokehittäjille
Yleinen malli ohjelmistokehittäjille annettavaa palautetta varten\*
Vältä klassisia palautemenetelmiä, kuten palautevoileipää.
Usein kahdenkeskisten keskustelujen palautemallit perustuvat voileipämenetelmään. Vältä tätä ohjelmistokehittäjien kanssa. Pitkät puheet työntekijöiden kanssa eivät auta ketään, ja erityisesti ohjelmistokehittäjät reagoivat usein allergisesti tällaisiin menetelmiin (katso: Palautetta koskevan sandwich-menetelmän kritiikki).
Ohjelmistokehittäjät ymmärtävät yleensä, että kun esimiehet antavat yleistä positiivista palautetta, se on vain keino saada toinen henkilö tuntemaan olonsa paremmaksi.
Onneksi sekin toimii paremmin.
Radikaali avoimuus: palautemenetelmä, joka toimii paremmin ohjelmistokehittäjille
Sen sijaan, että paketoisit kahdenkeskistä tapaamisesi palautetta turhaan hölynpölyyn voileipäpalautteessa, suosittelen käyttämään Radical Candor -menetelmää palautemallistasi pohjana. Se ei ole hyödyllinen vain ohjelmistoalan IT-teollisuudessa, vaan myös yksityiselämässä – mennäänpä syvemmälle.
Radikaali avoimuus tarkoittaa mahdollisimman rehellisen ja suoran palautteen antamista arviointikeskusteluissa. Samalla se tarkoittaa myös empatian osoittamista ja keskittymistä toisen ihmisen hyvinvointiin. Radikaali rehellisyys osoittaa, että sinun ei tarvitse valita jompaakumpaa: Joko suora ja rehellinen tai empaattinen ja huomaavainen. Sen sijaan voit tehdä molempia samanaikaisesti:
Lisää alla: Mitä on radikaali rehellisyys?
Ohjelmistokehittäjät ovat kiitollisia, jos menet suoraan asiaan negatiivisen palautteen kanssa.
Radikaaliin avoimuuteen perustuva palautemalli ohjelmistokehittäjille
Tämä malli perustuu SBI-malliin (Situation, Behaviour, Impact). Se auttaa sinua viestimään vilpittömästi, suoraan ja kuitenkin arvostavasti.
Katso myös “Palautteen antamisen pelikirja”
Seuraavassa on palautemallin yksittäisten osien ohjeet:
Palautemalli osa 1: Valmistelu etukäteen
Ennen kuin annat palautetta, mieti muutama minuutti seuraavia kohtia:
- Tilanne: Mihin tilanteeseen viittaat erityisesti?
- Käyttäytyminen: Minkälaista käyttäytymistä havaitsit henkilöstä?
- Vaikutus: Mitä vaikutuksia henkilön käytöksellä oli (sinuun ja muihin)?
- Toive: Minkä tilan haluat saavuttaa ja miksi? (Huomio: Kyse ei ole tietyn käyttäytymisen suorasta toivomisesta – se on osa toimenpidettä (katso alla). Kyse on pikemminkin laajemmasta kontekstista, miksi vaikutus on sinulle ongelma.)
- Toiminta: Mitä ehdotuksia sinulla on kyseiselle henkilölle? Millaiset muutokset käyttäytymisessä voisivat viedä lähemmäs tavoitetilaa? Mitä tukea voit tarjota?
Kannattaa kirjoittaa asiat lyhyesti ylös, jotta et unohda mitään haastattelun aikana.
Palautemalli osa 2: Keskustelun aloittaminen
Sen sijaan, että aloittaisit pitkällisen kahdenkeskisen palaverin palautevoileivän, voit nyt aloittaa suoraan tilanteesta keskustelun aloittajana:
- “Halusin puhua kanssasi siitä tilanteesta, kun me …”
Kuvaile tilanne ja kysy sitten:
- “Muistatko vielä tilanteen?”
Palautemalli osa 3: Käyttäytyminen
Sen jälkeen voit käsitellä henkilön käyttäytymistä, jonka olet havainnut arviointikeskustelussa:
- “Ravistit päätäsi tilanteesta ja sanoit…”
Ennen kuin puhut vaikutuksesta, anna toiselle henkilölle mahdollisuus kommentoida käsitystäsi tai muistiasi:
- “Kuvaanko tätä oikein sinun näkökulmastasi?”
Anna henkilölle tilaa kuvata näkökulmaansa asioihin. Yritä antaa molempien näkökulmien olla tasavertaisina tilassa kommentoimatta niitä. Rajoita itsesi esittämään kysymyksiä toisen henkilön näkökulman sisällöstä.
Palautemalli osa 4: Vaikutus
Ainoastaan tässä osassa keskustellaan käyttäytymisen vaikutuksista. Pysy aluksi mahdollisimman objektiivisena:
- “Vaikutelmani oli, että kollegani Marc vaikutti loukkaantuneelta sen jälkeen, kun sinä [havaitsit käyttäytymistä], eikä hän enää halunnut jatkaa yhteistyötä kanssamme.”
Jos vaikutukset kuitenkin vaikuttavat myös sinuun, on tärkeää kertoa myös tästä. Tietenkin sinun on aina pysyttävä ammattimaisena, mutta voit myös näyttää inhimillisen puolesi:
- “Itse olin rehellisesti sanottuna nolona siinä tilanteessa, ja keskustelu oli siitä lähtien epämiellyttävä.”
Palautemalli osa 5: Toiveet
Ilmaise erityinen pyyntösi arviointikeskustelun tässä osassa:
- “Minulle on tärkeää, että löydämme jälleen hyvän pohjan yhteistyölle kollegamme Marcin kanssa.”
Laita se uudelleen asiayhteyteen:
- “Sen lisäksi on suuri tarpeeni, että teemme yhteistyötä varmistaaksemme, että pidämme yllä hyvää yhteistyötä ja suhteita kaikkien naapurimaiden erikoisalojen kanssa.”
Mainitse myös asiaankuuluvat tavoitteet, jotka selittävät, miksi sinulla on tämä halu:
- “Vain hyvien suhteiden avulla voimme saavuttaa tavoitteemme tiiminä tässä yrityksessä. Minulle on myös tärkeää, että meillä on hyvä maine tiiminä yrityksessä.”
"Pidän työntekijästä, mutta hän ei suoriudu toivotulla tavalla. Miten voin puuttua tähän 1:1-palavereissa?"
Ratkaise tämä haaste
"En useinkaan tiedä, olinko liian kova – vai liian pehmeä – 1:1-keskusteluissa, jotta minulla olisi ollut myönteinen vaikutus."
Ratkaise tämä haaste
"En pysty tunnistamaan mitään malleja tai suuntauksia 1:1-keskusteluissani. Kaikki vaikuttaa irralliselta."
Ratkaise tämä haastePalautemalli osa 6: Mittaaminen
Ennen kuin esittelet omia ratkaisuideoitasi, voit esittää avoimia kysymyksiä kahdenkeskisessä keskustelussa:
- “Minulla on muutama ajatus tästä. Mutta haluaisin ensin kuulla sinun mielipiteesi: Miten mielestänne voisimme saavuttaa tavoitteen?”
Voit sitten jakaa ideasi. Sopikaa yhdessä sitovasta ja tarkkaan määritellystä jatkotoimesta. Kirjaa tämä kirjallisesti.
Palautemalli osa 7: Hylkääminen
Kysy, oliko arviointikeskustelusta hyötyä toiselle henkilölle ja onko hänellä vielä avoimia kysymyksiä. Järjestä tarkistuskeskustelu seuraavalle kerralle, jolloin puhutte aiheesta.
Osoita arvostavasi avointa vuoropuhelua ja kiitä henkilöä hänen näkemyksestään ja yhteistyöstään.
Palautemalli osa 8: Pohdi palautettasi jälkikäteen.
Jokaisen palautekeskustelun päätteeksi sinun tulisi kysyä itseltäsi seuraava kysymys:
- Rehellisyys: Olenko jakanut palautteeni rehellisesti ja mahdollisimman kaunistelematta?
- Arvostus: Tunteeko henkilö itsensä arvostetuksi palautteeni perusteella?
Jos voit vastata kyllä kaikkiin kysymyksiin, palautekeskustelusi sujui hyvin. Jos ei, älä huoli. Pohdi, miten voit muotoilla asiat toisin tulevaisuudessa. Ja vielä kerran, useimmat näistä vinkeistä eivät koske vain ohjelmisto-IT-alaa.
Tässä vaiheessa haluaisin huomauttaa, että on tietenkin olemassa myös ohjelmistoja, joilla voidaan yksinkertaistaa vastaavia palautekeskusteluja ja myös ohjelmistokehittäjien pidempiaikaista valmennusta.
Yksilökokousohjelmistomme tarjoaa erilaisia malleja työntekijöiden ja ohjelmistokehittäjien tapaamisiin ja tekee työntekijöiden kehityksestä jopa mitattavissa olevaa. Tutustu työkaluumme ja kokeile seuraavaa mallia:
Ei small talkia, ei kiusallisia taukoja. 🥱 Tämä 1:1-malli yksinkertaisesti toimii aina.
💬 Mallista:
- Mistä saavutuksesta olet ylpeä, jota en ehkä ole huomannut?
- Mikä pieni muutos parantaisi välittömästi työtäsi?
- Mihin haluaisit käyttää enemmän aikaa työssäsi?
…
Aloitetaan nyt tämän arviointikeskustelumallin avulla ja käydään läpi muutama käytännön esimerkki!
Esimerkkejä 1:1-palaveripalautteista: Koodin laatu, omistajuus
Esimerkkejä ohjelmistokehittäjille kahdenkeskisissä tapaamisissa annetusta palautteesta
Esimerkkipalaute ohjelmistokehittäjille 1-to-1-kokouksissa: Koodin laatu
Tanja 👩🏼🦰 on tiimin vetäjä ja Marc 👨🏽 työntekijän roolissa.
Kuvaile tilanne
”Viimeisessä koodikatselmuksessamme tarkastelimme vetopyyntöäsi uuden ominaisuuden toteuttamiseksi koontinäytössä. Koodi oli toiminnallisesti oikein ja täytti vaatimukset.”
”Kyllä, muistan sen!”
Havaittu käyttäytyminen
“Kommentoin kohtia, jotka olivat melko monimutkaisia ja vaikeita lukea. Esimerkiksi eräässä menetelmässä oli yli 50 riviä, jossa yhdistettiin useita vastuualueita. Kommentoit tätä kommenttia kuitenkin vain pintapuolisesti etkä käsitellyt sitä sen enempää.”
“Minusta kommentti kuulosti vapaaehtoiselta ehdotukselta. Ratkaisun muuttaminen uudelleen tuntui liian aikaa vievältä.”
Vaikutus
“Joka tapauksessa kommenttisi sai minut rehellisesti sanottuna hieman turhautuneeksi, ja sen sijaan, että olisin vaatinut sinulta korjausta, paransin menetelmää jälkikäteen itse, koska olin jo muutenkin ajatellut koodin.”
“En tiennyt sitä.”
Tavoite ja halu
“Yhteisenä tavoitteenamme on varmistaa, että koodimme on paitsi toimivaa myös ylläpidettävää ja helposti ymmärrettävää kaikille.”
“Juuri niin minä näen sen!”
Toimenpiteet
“Mikä on ehdotuksesi siitä, miten voimme jatkossa parantaa koodin laatua sujuvammin tällaisissa tapauksissa?”
“Minua auttaisi, jos kommenteista olisi helpompi nähdä, ehdotetaanko parannusta vai vaaditaanko sitä.”
”Hyvä, tehdään niin – otan sen uudelleen esille tiimikokouksessa. Lisäksi mielestäni se tarvitsee silti myös seurantaa sinun puoleltasi.”
“Mitä jos siirryttäisiin seuraavassa aiheessa suoraan pariohjelmointiin yhdessä, jotta voisit terävöittää ymmärrystäni koodin laadun vaatimuksista?”
Päätelmä
“Tuo kuulostaa kahdelta hyvältä jatko-osalta! Pidetään se sitten sellaisena. Haluaisin asettaa päiväkirjaani päivämäärän ensi viikon puoliväliin, jolloin aloitamme pariohjelmoinnin.”
“Hyvä on, odotan sitä innolla!”
Esimerkkipalaute ohjelmistokehittäjille 1-to-1-kokouksissa: Omistajuus
Tanja 👩🏼🦰 on tiimin vetäjä ja Marc 👨🏽 työntekijän roolissa.
Kuvaile tilanne
”Marc, haluan puhua kanssasi viimeisestä tehtävästä, jossa kehitimme uuden ominaisuuden vientiprosessia varten. Ominaisuus on nyt käytössä, mutta matkan varrella oli joitain haasteita.”
”Kyllä, muistan sen. Mitä tarkoitat tarkalleen?”
Havaittu käyttäytyminen
“Huomasin, että koodin testaamisen jälkeen oli useita pitkiä viiveitä. Esimerkiksi joihinkin QA-kollegoiden kommentteihin vastattiin vasta päivien kuluttua. Lisäksi kävi niin, että jouduin muistuttamaan kahdesti puuttuvasta tarkistuksesta.”
“Hmm, ymmärrän. Rehellisesti sanottuna siellä oli aika paljon meneillään, ja luulin, että testaus jatkuisi rinnakkain.”
Vaikutus
“Tuloksena oli, että meidän oli lykättävä käyttöönottoa tämän ongelman vuoksi.”
“Voi, en edes tajunnut tuota. Luulin, että ottaisit yhteyttä, jos jokin asia olisi kiireellinen.”
Tavoite ja halu
“Tavoitteenamme on minimoida tarpeettomat viivästykset ja saada rakennuttajat omaksumaan omistajuusajattelu toteutuksen aikana. Tämä tarkoittaa sitä, että jokainen varmistaa aktiivisesti, että hänen tikettinsä pääsee läpi alusta loppuun –, ja siihen kuuluu myös yhteydenpito QA:n kanssa.”
“Ymmärrän, mitä tarkoitat. Haluan ehdottomasti, että prosessit sujuisivat sujuvammin.”
Toimenpiteet
“Mitä voisimme sinun näkökulmastasi tehdä, jotta voisit toimia ennakoivammin ja osoittaa vastuullisuutta tällaisissa tilanteissa?”
“Minusta auttaisi, jos asettaisimme selkeämmät odotukset, esimerkiksi sen, että tarkastan päivittäin avoimet ongelmat testausvaiheessa. Näin voin varmistaa, ettei mitään jää tekemättä.”
“Kuulostaa hyvältä. Ja ehdottaisin, että koodin viimeistelyn jälkeen teet seuraavissa tärkeimmissä tehtävissä lyhyen suunnitelman siitä, miten haluatte viedä aiheen läpi live-julkaisuun asti. Voit näyttää suunnitelman minulle tai QA-kollegalle.”
“Sovittu. Sitten voin itse pitää asioita paremmin silmällä.”
Päätelmä
“Hienoa. Tallennetaan nämä kaksi toimenpidettä näin: Teet päivittäisiä tarkistuksia testausvaiheen aikana ja suunnittelet seurantaa seuraavaan tärkeään tehtävään. Onko se sinulle toteutettavissa?”
“Kyllä, se sopii. Kirjoitan sen suoraan päiväkirjaani.”
“Hienoa. Olen varma, että sillä on suuri merkitys. Seuraavassa kahdenkeskisessä tapaamisessamme tarkastelemme uudelleen toimenpiteidemme tilaa. Kiitos!”
Johtaminen kysymysten avulla: malli 1:1-kokouksia varten
Johtamiskirjallisuuden viisaus kuuluu: johda kysymällä kysymyksiä. Ja siinä on paljon perää.
Jos pidät säännöllisesti ja jatkuvasti kahdenkeskisiä tapaamisia, joissa pohdit yhdessä työntekijän kanssa palautetta (esittämällä kysymyksiä), ongelmat eivät voi “kasautua” .
Siksi haluaisin antaa sinulle toisen mallin, jota voit käyttää Echometer-työkalussamme työntekijäsi kanssa. Periaatteessa voit käyttää tätä mallia myös säännöllisesti.
Kokeile niitä klikkaamalla alla olevaa painiketta (kirjautumista ei tarvita):
Aloitus
- Miten viikkosi on sujunut tähän asti?
📊 Projektipäivitykset
- Miten nykyiset projektisi sujuvat? Onko suurempia onnistumisia tai esteitä?
- Onko teknisiä haasteita, joista haluat keskustella tai joita haluat pohtia yhdessä?
💻 Koodin laatu ja kehitys
- Miltä sinusta on tuntunut työsi laatu viime aikoina?
- Onko alueita, joilla haluat kehittyä tai oppia uusia taitoja?
🤝 Tiimi, yhteistyö ja seuraavat vaiheet
- Miten yhteistyö sujuu tiimissä? Onko viestintäaukkoja?
- Tukevatko käyttämämme työkalut ja prosessit työskentelyäsi tehokkaasti?
- Miten näet urasi seuraavan 1–2 vuoden aikana?
- Miten voin auttaa sinua menestymään?
Lopetus
- Mitä odotat eniten tulevina kuukausina?
- Onko sinulla muita kysymyksiä tai huolenaiheita?
⁉️ Tunnelmatarkistus (kysely)
Esimerkkejä suorituskyvyn arvioinnin palautteesta: Tiimityö, omistajuus
Esimerkkejä ohjelmistokehittäjille annettavasta palautteesta suorituskyvyn arvioinnissa
Huomautus: Perinteiset suoritusarvioinnit eivät yleensä ole suosittuja sekä ohjelmistokehittäjien että johtajien keskuudessa, ja monet väittävät, että hyvät kahdenkeskiset tapaamiset ovat riittäviä ja että niiden pitäisi korvata suoritusarvioinnit. Ks: “Suoritusarvioinnit ovat turhia ja loukkaavia”, Forbes.
Suoritusarvioinnit ovat kuitenkin usein edelleen ennalta määrätty muoto yrityksessä. Tämä ei tietenkään saisi estää sinua käymästä suoritusarviointeja vuoropuheluna silmätasolla työntekijöidesi kanssa sen sijaan, että rajoitut ylhäältä alaspäin suuntautuviin arviointeihin. Seuraavat esimerkit kahdenkeskisestä vuoropuhelusta osoittavat, miten se voi toimia.
Huomautus: Kuten jo mainittiin, työntekijöiden arviointimallien avulla voidaan tietenkin antaa palautetta rakentavasti. Seuraavasta blogikirjoituksesta voi olla apua, jos aihe kiinnostaa sinua enemmän: 5 mallia työntekijöiden säännöllisiä tarkastuksia varten .
Esimerkkipalaute ohjelmistosuunnittelijoille suorituskykyarvioinneissa: Tiimityö
Tanja 👩🏼🦰 toimii tiimin johtajana ja Marc 👨🏽 ohjelmistoinsinöörinä.
Kuvaile tilanne
”Kun minun piti arvioida kohtaa ‘Tiimityö’ suorituskykyarviointipohjassasi, pystyin valitettavasti antamaan vain 5 pistettä maksimista 10. Haluaisin selittää tämän sinulle, jotta sinulla olisi reilu mahdollisuus parantaa itseäsi tässä kohdassa.”
”Ai, okei. Ole hyvä ja auta minua ymmärtämään tämä.”
Havaittu käyttäytyminen
“Olen huomannut, että viime kuukausina on ollut tilanteita, joissa yhteistyö tiimin kanssa ei ole ollut optimaalista. Esimerkiksi viime sprintissä oli useita tapauksia, joissa työstit tehtäviä yksin, vaikka ne olisi voitu ratkaista paremmin yhdessä muiden kanssa. Yksi konkreettinen esimerkki oli uuden API:n integrointi. Olimme harkinneet, että sinä ja Alex työskentelisitte sen parissa yhdessä, mutta otit useimmat vaiheet yksin ja otit Alexin mukaan vain minimaalisesti.”
“Ajattelin, että olisi tehokkaampaa tehdä se nopeasti itse. En tajunnut, että tätä pidettiin ongelmana.”
Vaikutus
“Tämä johti kuitenkin siihen, että tiimi menetti avoimuutensa. Alexilla oli myöhemmin vaikeuksia päästä mukaan asiaan liittyviin tehtäviin, koska hän ei tiennyt tarkalleen, miten API oli asetettu. Sain myös muilta tiimin jäseniltä palautetta siitä, että he eivät joskus tunteneet olevansa tarpeeksi mukana ja että heidän oli vaikea saada sinulta tukea, kun heillä oli kysyttävää.”
“Rehellisesti sanottuna se yllättää minut. Luulin auttavani, kun minua pyydetään.”
Tavoite ja halu
“Tiiminä tavoitteenamme ei ole ainoastaan työskennellä tehokkaasti, vaan myös jakaa tietoa ja ottaa kaikki mukaan. Tämä vahvistaa yhteistyötä ja varmistaa, että voimme kaikki edustaa toisiamme. Toivoisin, että hyödyntäisit tulevaisuudessa entistä enemmän rooliasi tiedon kantajana tässä tiimissä, jotta voisit aktiivisesti jakaa tietoa ja voimaannuttaa muita tiimin jäseniä.” Näin voit tehdä. Tiimin tuottavuus on tärkeämpää kuin yksilöllinen suorituskyky.”
“Okei, ymmärrän mitä tarkoitat. Luulen, että olen vain keskittynyt tähän mennessä liikaa omaan tuottavuuteeni.”
Toimenpiteet
“Mikä voisi auttaa sinua kiinnittämään enemmän huomiota tiimin osallistamiseen työhösi ja tiedon jakamiseen?”
“Voisin ottaa tavaksi selventää heti alussa, kuka voi työskennellä suurempien tehtävien parissa ja miten. Ehkä voisimme myös järjestää jonkinlaisen kick-offin tehtäviä varten, jotta voisimme sopia tärkeimmistä arkkitehtuuripäätöksistä ja yksilöidä tehtävät, jotka jonkun muun pitäisi tehdä yksin tai jotka meidän pitäisi jopa tehdä pariohjelmointina.”
“Kuulostaa hyvältä. Minulla on myös ajatus: mitä jos ottaisit tavaksesi paitsi raportoida edistymisestä viikoittaisissa tiimipalavereissamme, myös antaa aktiivisesti näkemyksiä koodista ja arkkitehtuuripäätöksistä?”
“Tuo on hyvä huomio. Se voisi helpottaa kokemattomien kollegojemme työskentelyä koodini parissa myöhemmin.”
Päätelmä
“Hienoa. Sitten kirjaamme jatkotoimet tulosarvioinnin malliin:
- Tästä lähtien jaat tietämystäsi ja arkkitehtuuripäätöksiäsi proaktiivisesti tiimin kanssa Weeklysissä.
- Tästä lähtien teet jokaisesta aiheestasi kick-offin toisen kehittäjän kanssa, jotta kehitätte ratkaisun yhdessä ja jaatte toteutuksen keskenänne.
“Kuulostaa hyvältä.”
”OK. Kirjaan molemmat toimenpiteet muistiin kahden kuukauden päästä tapahtuvaa tarkastelua varten. Sitten voimme keskustella tilanteesta kahdenkeskisessä tapaamisessamme ja katsoa, miten jatkamme.”
“Niin, ja katsotaan sitten, pystytkö parantamaan tiimityöskentelypisteitäsi. Haluaisin saada vähintään 8 pistettä 10:stä.”
“Olen iloinen kuullessani tuon! Uskon ehdottomasti, että se on realistista, ja tuen sinua kaikin mahdollisin tavoin.”
“Kiitos!”
Esimerkkipalaute ohjelmistosuunnittelijoiden suorituskyvyn arviointiin: Omistajuus
Siirrymme seuraavaan esimerkkiin kahdenkeskisestä keskustelusta, jossa käsitellään ohjelmistokehittäjälle annettavaa palautetta omistajuudesta.
Kuten aina, Tanja 👩🏼🦰 toimii tiimin johtajana ja Marc 👨🏽 ohjelmistoinsinöörinä.
Kuvaile tilanne
”Kun minun piti arvioida kohtaa ‘Oma-aloitteisuus’ suorituskykyarviointipohjassasi, pystyin antamaan vain 6 pistettä maksimista 10. Haluan selittää sinulle, miksi näin on, ja antaa sinulle mahdollisuuden kehittyä tällä alueella.”
”Vau, tämä yllättää minut hieman. Olenhan osallistunut niin moniin aiheisiin kuin tuskin kukaan muu tiimissä. Selitäthän minulle.”
Havaittu käyttäytyminen
“Viime kuukausina olen huomannut, että tehtävissänne on usein viiveitä. On useita esimerkkejä siitä, että QA-kommentit tai koodin tarkistukset ovat jääneet sinulta vastaamatta pitkäksi aikaa. Tämän seurauksena aiheesi ovat lähteneet käyttöön vasta viikkoja kestäneiden viivästysten jälkeen. Yksi konkreettinen esimerkki oli viennin bugikorjaus. Vastasit QA:n palautteeseen vasta toistuvien pyyntöjen jälkeen, ja muutosten käyttöönotto kesti yhteensä kolme viikkoa.”
“Kyllä, minä muistan. Työstin samaan aikaan kahta muuta aihetta enkä ehtinyt syöttää palautetta niin nopeasti.”
Vaikutus
“Tämä vaikutti koko tiimin nopeuteen ja tuottavuuteen. QA:n oli seurattava asiaa useita kertoja, mikä sitoi heidän kapasiteettiaan. Myös julkaisusuunnitelmaa jouduttiin lykkäämään. Lisäksi tuntui siltä, että et ota täyttä vastuuta asioiden viimeistelystä, mikä rasittaa tiimin dynamiikkaa. Jotkut tiimin jäsenet ovat kertoneet minulle, etteivät he ole varmoja, voivatko he luottaa sinuun, kun on kyse riippuvuuksista.”
“Voi, olen pahoillani siitä. En tajunnut sitä. Yritin tehdä tehtävät rinnakkain, mutta ilmeisesti se ei onnistunut niin hyvin.”
Tavoite ja halu
“Tavoitteeni on, että keskityt vähemmän aiheisiin, mutta otat täyden vastuun jokaisesta tehtävästä alusta loppuun. Tämä tarkoittaa, että et ainoastaan kirjoita alkuperäistä koodia vaan myös varmistat, että QA-palaute käsitellään nopeasti ja että aihe pysyy aikataulussa. Näin vältämme sen, että tehtävät jäävät pidemmäksi aikaa auki ja estävät muita.”
“Siinä on järkeä. Tunsin usein olevani hukkumaisillaan, koska minulla oli liian monta aihetta samaan aikaan. Ehkä on todella parempi keskittyä harvempiin tehtäviin.”
Toimenpiteet
“Miten saisimme sinut keskittymään muutamaan aiheeseen ja ottamaan vastuun niiden toteuttamisesta täysimääräisesti?”
“Voisin yrittää rajoittaa itseni enintään kahteen aiheeseen sprinttiä kohden ja työskennellä vain kolmen aiheen parissa samanaikaisesti. Minun pitäisi myös varata kalenteriini kiinteitä aikavälejä kommenttien ja arvostelujen säännölliselle työstämiselle, jotta mikään ei jäisi tekemättä.”
“Kuulostaa järkevältä. Lisäksi minusta olisi hyvä, jos voisit pyytää ennakoivasti apua stand-upeissamme, jos käsittelet liian monia aiheita samanaikaisesti. Yleensä pitäisi löytyä joku, joka voi ottaa aiheen haltuunsa sinulta.”
“Okei, reilua.”
Päätelmä
Asetetaan nämä toimenpiteet tavoitteiksi seuraaville kahdelle kuukaudelle:
Vähemmän rinnakkaista työtä:
- Otat vastuullesi enintään kaksi aihealuetta sprinttiä kohden, etkä työskentele samanaikaisesti yli kolmen aihealueen parissa.
- Vaadi tiimiltä aktiivista tukea stand-up-tapaamisissa.
- Kiinteät ajat kalenterissa kommenttien ja arvostelujen käsittelyyn.
“Kuulostaa realistiselta. Tehdään se niin.”
“Hienoa. Voimme nähdä kahden kuukauden kuluttua tulosarvioinnissa, ovatko nämä toimenpiteet toimineet, ja voimmeko nostaa luokitustasi tulosarvioinnissa jälleen “omistajuuden” tasolle.”
“Kiitos, Tanja. Pyrin toteuttamaan sen käytännössä. Sain ennen aina parhaat arvosanat ‘omistajuudesta’. Luuletko, että saan sen taas seuraavaan tulosarviointiin mennessä?”
“Olen tyytyväinen siihen. Kyllä, uskon, että nopea parannus on ehdottomasti saavutettavissa näillä toimenpiteillä. Keskustellaan kahden viikon välein pidettävissä kahdenkeskisissä tapaamisissamme tilasta ja siitä, tarvitsetko tukea.”
“Kiitos! Kyllä, olisin iloinen, jos voisimme saada aikaan huomattavaa parannusta muutaman viikon kuluessa!”
Vuosittainen vuoropuhelu Esimerkkejä palautteesta: Toive roolimuutoksesta
Esimerkkejä ohjelmistokehittäjille annettavasta palautteesta vuositarkastuksessa
Jos pidätte jo säännöllisiä kahdenkeskisiä tapaamisia tai suoritusarviointeja kehittäjienne kanssa vuoden aikana, yksityiskohtaisia vuosikokouksia ei luultavasti enää tarvita. Suorituskykyä, palautetta ja jatkokehitystä koskevan keskustelun pitäisi olla jo nyt jatkuvaa:
On kuitenkin yrityksiä, jotka vaativat klassista vuosittaista arviointia.
💡
Jos ohjelmistokehittäjien esimiehenä sinulla on jo säännöllisiä 1:1-palavereja tai suoritusarviointeja, vuosittaisen arvioinnin pitäisi olla vain muodollisuus:
Ohjelmistokehittäjän pitäisi jo olla tietoinen palautteesta ja hänen pitäisi jo työskennellä kehityspotentiaalin parissa.
Jos siis ohjelmistokehittäjien esimiehenä sinun on täytettävä loppuvuoden kokouksen muodollisuus (mahdollisesti säännöllisten kahdenkeskisten tapaamisten lisäksi), käydään läpi myös esimerkki vuosittaisesta työntekijän arvioinnista ohjelmistokehittäjän kanssa.
Muuten, toinen vinkki tässä vaiheessa: Jos ensimmäinen kahdenkeskinen tapaaminen uuden työntekijän kanssa on aivan nurkan takana, voin suositella aihetta käsittelevää artikkeliamme: 5 vinkkiä kahdenkeskisiin tapaamisiin uusien työntekijöiden kanssa .
Näyte esityslista & malli ohjelmistokehittäjän kanssa pidettävää vuosikokousta varten
- Arviointi ja suorituskyky
- Onnistumiset: Mitkä hankkeet tai tehtävät sujuivat hyvin? Missä kohdin odotukset ylitettiin?
- Haasteet: Mikä ei toiminut niin hyvin ja miksi? Miten nämä haasteet voidaan voittaa tulevaisuudessa?
- Pohdinta: Miten kehittäjä näkee oman suorituksensa? Mitä palautetta tiimi tai esimies antaa?
- Yhteistyö ja tiimikulttuuri
- Viestintä: Miten yhteistyö koetaan tiimin sisällä ja esimiehen kanssa?
- Työilmapiiri: Onko tiimikulttuurissa tai työympäristössä parantamisen varaa?
- Palaute johtamisesta: Miten johtaja voi tukea kehittäjää paremmin?
- Palaute kehittäjältä: Onko ehdotuksia prosessien, työkalujen tai työkulttuurin parantamiseksi?
- Työ- ja yksityiselämän tasapaino: Miltä nykyinen työmääräsi tuntuu? Onko ylitöitä tai stressitekijöitä?
- Resurssit: Ovatko välineet, prosessit ja toimintaedellytykset riittävät tehokkaaseen työskentelyyn?
- Asiantuntemus, tavoitteet ja kehitys
- Vahvuudet: Mitkä tekniset, metodologiset tai sosiaaliset taidot ovat tyypillisiä kehittäjälle?
- Lisäkoulutus: Mitä uusia teknologioita tai taitoja kehittäjä haluaa oppia? Onko olemassa asiaankuuluvia kursseja, konferensseja tai hankkeita?
- Uran tavoitteet: Mihin tehtävään tai vastuualueeseen kehittäjä pyrkii keskipitkällä tai pitkällä aikavälillä? Mitkä vaiheet johtavat sinne?
- Hankekeskeisyys: Minkä hankkeiden tai teknologioiden parissa kehittäjä haluaisi työskennellä intensiivisemmin?
- Palkkaus
- Suoritukseen perustuva palkitseminen: Onko palkkaa tai bonuksia tarpeen mukauttaa?
- Päätelmä
- Lyhyen aikavälin tavoitteet: Mitä konkreettisia tavoitteita olisi asetettava tulevalle vuodelle?
- Sopimukset: Mitkä ovat kunkin toimenpiteen seuraavat tarkastukset?
Seuraavassa on tyypillinen esimerkki palautteesta, joka annetaan loppuvuoden tai vuotuisen suorituskyvyn arvioinnin yhteydessä: Työntekijän pyyntö tehtävän vaihtamisesta.
Esimerkki palautteesta vuosikokouksessa: Toive roolin muutoksesta
Tanja 👩🏼🦰 toimii tiimin johtajana ja Marc 👨🏽 ohjelmistoinsinöörinä.
Sisääntulo ja tilanne
”Marc, on hienoa, että voimme tänään puhua vuosipalautteestasi ja tavoitteistasi. Onko sinulla tiettyjä aiheita, jotka ovat sinulle erityisen tärkeitä?”
”Kyllä, olen miettinyt jatkokehitystäni. Voisin kuvitella kehittyväni ohjelmistoarkkitehtuurin suuntaan. Aihe on kiehtonut minua jo pitkään, ja haluaisin syventyä arkkitehtuuripäätöksiin ja strategiseen teknologian hallintaan.”
“Se on jännittävää, Marc. Olen iloinen, että sinulla on niin selkeät tavoitteet. Puhutaanpa siitä, miten voimme valmistella sinua niihin. On muutamia kohtia, joissa sinun on mielestäni kehitettävä edelleen, ennen kuin otamme seuraavan askeleen.”
Anna palautetta
“Ensinnäkin haluan korostaa, että olette edistyneet paljon tänä vuonna erityisesti toteutustenne laadussa ja uusien tekniikoiden käsittelyssä. Olette myös osoittaneet, että teillä on silmää laajemmalle ulottuville, esimerkiksi uuden välimuistijärjestelmän käyttöönoton myötä.”
“Kiitos, mukava kuulla!”
“Kun ajattelen ohjelmistoarkkitehdin roolia, on kuitenkin vielä joitakin vaatimuksia, jotka eivät mielestäni täyty tällä hetkellä täysin. Esimerkiksi viestintä tiimin kanssa ja muiden osallistuminen teknisiin päätöksiin on keskeinen osa. Näen siinä edelleen potentiaalia. Teet usein päätöksiä itsenäisesti ottamatta tiimiä mukaan tarpeeksi aikaisin.”
“Okei, ymmärrän sen. En halunnut joskus pidättää ketään, mutta ymmärrän, ettei se ole ihanteellista arkkitehdin roolissa.”
Tavoite ja halu
“Juuri niin. Ohjelmistoarkkitehti on myös valmentaja ja viestijä. Kyse on siitä, että hän saa muut mukaan, kommunikoi teknisistä käsitteistä ja kehittää ratkaisuja yhdessä.”
“Siinä on järkeä. Ymmärrän myös, etten pysty vielä kommunikoimaan arkkitehtuuria koskevia ajatuksiani yhtä tehokkaasti tiimini jäsenille.”
Suunnitelman toimenpiteet
“Uskon, että voimme työskennellä yhdessä, jotta saatte pätevyyden tehtävään seuraavan kuuden kuukauden aikana. Mitä jos määrittelemme konkreettiset toimenpiteet?”
“Mielelläni. Mitä sinulla on mielessäsi?”
“Haluaisin ennen kaikkea, että sinä ohjaisit ohjelmistoarkkitehtuuria koskevaa päätöksentekoprosessia sen sijaan, että tekisit päätökset itse. Miten olisi, jos moderoisit arkkitehtuurin aloituskokouksen jokaisesta seuraavasta tärkeästä aiheesta? Tavoitteena olisi tukea kollegoita päätöksentekoprosessissa ja antaa heidän sitten itse toteuttaa ratkaisu.”
”Hyvä juttu. Näin opin käyttämään vaikutusvaltaani valmentajana sen sijaan, että toteuttaisin kaiken itse.”
”Lisäksi uskon, että on olemassa hyviä kursseja, joilla kehittäjiä valmistellaan ohjelmistoarkkitehdin rooliin. Näillä kursseilla käsitellään varmasti hard skills -taitojen lisäksi myös roolissa tarvittavia soft skills -taitoja.”
”Kyllä, olen itse asiassa jo etsinyt kurssin.”
Päätelmä
”Hienoa, kirjaan vuosikeskusteluumme seuraavaa:
- Kehitystavoite: Ohjelmistoarkkitehti
- Toimenpiteet:
- Arkkitehtuurin käynnistysvaiheiden moderointi tiimissä
- Osallistuminen ohjelmistoarkkitehtien kurssille.
Keskustelemme näistä aiheista tietysti jatkuvasti kahdenkeskisissä tapaamisissamme, mutta seuraava virallinen tarkistuspiste olisi sitten suorituskykyarvioinnissamme 3 kuukauden kuluttua.”
”Kuulostaa hyvältä. Siihen mennessä pitäisi olla jo jotain saavutettuna.”
”Niin minäkin uskon! Jos mieleesi tulee välillä muita asioita, joilla voin tukea sinua tässä asiassa, ota minuun yhteyttä milloin tahansa.”
”Voimmeko sitten 3 kuukauden kuluttua puhua uudelleen suunnittelemastani roolin vaihdosta?”
”Toki, en voi tietenkään luvata mitään roolin vaihdon suhteen. Mutta kirjasin toiveesi ylös ja yritän tukea sinua parhaani mukaan.”
“Kiitos!”
Johtopäätös: Palaute ohjelmistosuunnittelijoille 1:1-palavereissa, suorituskyvyn arvioinneissa ja vuosittaisissa arvioinneissa.
Johtopäätös: Motivoiva palaute ohjelmistokehittäjille
Esimerkit ja mallit osoittavat, että ei tarvitse olla kovin vaikeaa antaa motivoivaa palautetta ohjelmistokehittäjille kahdenkeskisissä tapaamisissa ja loppuvuoden kokouksissa, eikö niin? Pysy aitona ja hyväntahtoisena, älä kiertele ja osoita, että olet kiinnostunut yhteisestä ratkaisusta.
Jos onnistut toteuttamaan “Radical Candor” -periaatetta työntekijöiden kanssa käymissä keskusteluissa ja sen ulkopuolella osoittamalla arvostusta ja rehellisyyttä, reaktio voi olla jopa positiivisempi ja rakentavampi kuin luuletkaan.
Onnea seuraaviin palautekeskusteluihinne!
Ja jos pidät elämääsi helpottavista hakkeroinneista, suosittelen Echometer-ohjelmistoamme. Voit kokeilla sitä täysin ilmaiseksi.
Yksilökokousohjelmistomme tarjoaa erilaisia malleja työntekijöiden ja ohjelmistokehittäjien tapaamisiin ja tekee työntekijöiden kehityksestä jopa mitattavissa olevaa. Tutustu työkaluumme ja kokeile seuraavaa mallia:
Ei small talkia, ei kiusallisia taukoja. 🥱 Tämä 1:1-malli yksinkertaisesti toimii aina.
💬 Mallista:
- Mistä saavutuksesta olet ylpeä, jota en ehkä ole huomannut?
- Mikä pieni muutos parantaisi välittömästi työtäsi?
- Mihin haluaisit käyttää enemmän aikaa työssäsi?
…
