Skip to main content

Projektin lopussa suoritat esimerkiksi dokumentaation arkistoinnin, laskutat asiakkaan, teet tiimisi suoritusarvioinnit ja tietysti kaikista tärkeimpänä asiana – projektin retrospektiivin.

Retrospektiivien tarkoituksena on tarkastella, miten projekti sujui ja mitä tulevissa projekteissa voitaisiin parantaa (eivätkä ne ole tekosyy järjestää 80-luvun teemajuhlia, vaikka siltä saattaakin kuulostaa).

Mikä on projektin retrospektiivi?

Projektin retrospektiivi on muodollinen tilaisuus, jossa projektin sidosryhmiä pyydetään tarkastelemaan päättynyttä projektia ja pohtimaan, mikä sujui hyvin, mikä ei sujunut niin hyvin ja mitä voitaisiin parantaa. Laaditte toimintasuunnitelman tulevien projektien ja prosessien kehittämiseksi.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

Yhtenä ketterän kehityksen keskeisistä tapahtumista eli seremonioista projektipäälliköt käyttävät retrospektiivejä arvioidakseen, miten tiimi työskentelee yhdessä, ja parantaakseen prosessiaan. Projektipäällikön on luotava turvallinen tila, jotta istunnon aikana voidaan jakaa avointa ja rehellistä (ja mahdollisesti epämiellyttävääkin) palautetta.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Miksi projektien retrospektiivit ovat tärkeitä?

Onnistunut retrospektiivi parantaa projektiprosessejasi ja lisää tulevan projektin onnistumisen todennäköisyyttä. Tässä on muitakin syitä siihen, miksi projektien retrospektiivit ovat tärkeitä:

  • Jatkuva parantaminen: Tiimi voi pohtia, mikä sujui hyvin ja mikä ei. Oppikaa virheistä ja tunnistakaa onnistumiset, joita haluatte toistaa. Kun teette tämän perusteella muutoksia prosesseihinne ja työnkulkuihinne, tiimi kehittyy ja työskentelee paremmin yhdessä ajan myötä.
  • Parempi tiimin rakentaminen ja yhteistyö: Retro antaa tiimille mahdollisuuden lähentyä. Se on turvallinen tila, jossa annetaan rakentavaa palautetta ja selvitetään, miten yhteistyötä voidaan jatkossa parantaa. Käyttäkää retroja myös onnistumisten juhlistamiseen, sillä se parantaa tiimin moraalia ja motivaatiota.
  • Parantunut ongelmanratkaisu: Tiimi voi ratkaista projektin aikana kohdattuihin haasteisiin ja esteisiin liittyviä ongelmia sekä pohtia, miten vastaavat haasteet voidaan ratkaista tulevissa projekteissa. Tiimin jäsenet voivat myös jakaa parhaita käytäntöjä keskenään, mikä parantaa heidän yhteistä tietämystään.
  • Parempi vastuunotto: Kun tiimi kokoontuu keskustelemaan siitä, mikä meni pieleen, retrot vahvistavat vastuunottoa ja kannustavat tiimin jäseniä ottamaan omistajuuden työstään. Älkää syyttäkö virheistä, vaan keskittykää siihen, mitä on muutettava, jotta samat virheet voidaan välttää tulevaisuudessa.
  • Parantunut projektisuunnittelu: Projektin aikana ilmenneiden riskien, projektioletusten, esteiden ja muiden ongelmien dokumentointi varmistaa, että voitte ottaa nämä asiat huomioon tulevien projektien projektisuunnitelmissa.

Miten projektien retrospektiivejä järjestetään

Tarkastellaan seuraavaksi käytännön vaiheita ja neuvoja tehokkaan retrospektiivi-istunnon fasilitointiin projektissasi.

Vaihe 1: Rakenna luottamuksen kulttuuri

Voi olla vaikeaa saada ihmiset olemaan avoimia ja antamaan palautetta. Se on vieläkin vaikeampaa, jos projektitiimin ja sidosryhmien välillä vallitsee epäluottamus. 

  • Arvosteltiinko palautetta aiemmin? 
  • Saivatko tiimin jäsenet tuntemaan itsensä pelotelluiksi jakaessaan ideoita ja palautetta? 
  • Ryhtyttiinkö palautteen jakamisen jälkeen kielteisiin toimiin, jotka saatettiin nähdä rangaistuksina (esimerkiksi tiettyjen etujen poistamiseen)? 
  • Pelattiinko syyllisten etsinnän peliä, jos ongelmia paljastui? 

Jos vastasit johonkin näistä kysymyksistä kyllä, nämä ovat varmoja syitä siihen, miksi tiimissä voi olla epäluottamusta ja haluttomuutta avoimuuteen.

Miten siis saat ihmiset olemaan avoimia ja jakamaan palautetta? Miten rakennat luottamuksen kulttuurin ja saat ihmiset tuntemaan, että he ovat turvallisessa tilassa?

kuva kahdesta saksanpähkinästä kuvaamassa tiimin jäsenten saamista ulos kuorestaan projektien retrospektiivejä varten
Ihmisten saaminen avautumaan on yksi projektin retrospektiivin vaikeimmista osista.

Voit kokeilla seuraavia keinoja:

  • Kannusta avoimeen ja rehelliseen viestintään: Varmista, että tiimisi kokee olevansa arvostettu ja tärkeä. He ovat halukkaampia avautumaan ja jakamaan ajatuksiaan, jos he tietävät, ettei heitä sivuuteta tai syrjäytetä.
  • Luo mahdollisuuksia yhteistyöhön: Näitä voivat olla päivittäiset projektin tilannekatsaukset tai projektin ulkopuoliset tehtävät, kuten tiimiytymisharjoitus. Jos ihmisille annetaan mahdollisuuksia tehdä yhteistyötä, heidän on helpompi viestiä.
  • Tee palautteesta osa tiimin toimintakulttuuria: Ohjelmistokehitysprojekteissa on tavallista, että tiimin muut jäsenet vertaisarvioivat tiimin jäsenten koodia osana säännöllistä kehitysprosessia. Etsi projektistasi vastaavia mahdollisuuksia ja varmista, että tiimi antaa ja saa säännöllisesti sekä myönteistä että kielteistä palautetta.

Vaihe 2: Määritä, millaista palautetta haluat kerätä

Projektin aikana tapahtuu paljon, joten retrospektiivin aikana on runsaasti mahdollisuuksia kerätä monenlaista palautetta. Tämä on hyvä asia, mutta se voi myös tuntua ylivoimaiselta.

Kun suunnittelet retrospektiiviä, määrittele, millaista palautetta haluat osallistujilta. 

Yritä määritellä teemoja, joista haluat kerätä palautetta, kuten:

  • Tiimin suoriutuminen: Miten tiimi suoriutui projektin aikana? Saavutettiinko määräajat? Oliko työn laatu hyvä?
  • Viestintä ja sidosryhmien osallistaminen: Jaettiinko tieto oikeille henkilöille oikeaan aikaan ja oikeita työkaluja käyttäen? Oliko tietoa liikaa vai liian vähän?
  • Projektin tuotos: Vastaisiko projektin tuotos sidosryhmien odotuksia? Miksi tai miksi ei?
  • Projektin prosessit ja työkalut: Auttoivatko jotkin prosessit projektin onnistumista vai vaikeuttivatko ne sitä? Puuttuiko prosesseja tai oliko niitä liikaa? Oliko projektissa käytetyistä ketterän kehityksen työkaluista hyötyä vai haittaa?

Vaihe 3: Varaa projektin retrospektiiville oma ajankohta

Varaa ja aikatauluta retrospektiivi erikseen projektin arviointia varten. Jos mahdollista, pyri aikatauluttamaan tilaisuus ja lähettämään kalenterikutsut (tai ennakkovarausmerkinnät) muutamaa viikkoa etukäteen.

Kun aikataulutat retrospektiiviä, lähetä myös asialistasi kutsun mukana (palaamme tähän pian).

Lisää kutsuun myös osallistujia koskevat odotukset (esimerkiksi jos osallistujien on suoritettava ennen kokousta tehtäviä, kuten tietyn ohjelmistotyökalun lataaminen).

Projektin retrospektiivikokouksen asialista

Retrospektiivin ei tarvitse olla erityisen monimutkainen toiminto. Projektin retrospektiivin tarkoituksena on kerätä projektista palautetta, jotta seuraavia projekteja voidaan kehittää jatkuvasti. 

Seuraavassa on esimerkkiasialista, jota voidaan käyttää ja mukauttaa kokouksen keston mukaan:

  1. Tervetuloa ja johdanto: Tervetuloa osallistujat tilaisuuteen, esittele vetäjä ja kerro tilaisuuden tarkoitus ja tavoitteet
  2. Yleiskatsaus palautteen keräämiseen: Esitä lyhyt yhteenveto siitä, miten palautetta kerätään tilaisuuden aikana (suullisesti, kirjallisesti, hybridimuodossa, nimettömänä jne.) ja mitä työkaluja käytetään (virtuaalinen valkotaulu, keskustelu pyöreän pöydän ääressä jne.)
  3. Tilaisuuden pelisääntöjen kertaaminen: Kerro osallistujille mahdollisista pelisäännöistä (esimerkiksi: palautteen tulee olla rakentavaa ja rehellistä, sekä myönteistä että kielteistä palautetta tulee antaa jne.)
  4. Palautteen kerääminen: Kirjaa kerättäväksi haluamasi palaute valitsemallasi työkalulla.
  5. Palautteen tarkasteleminen osallistujien kanssa: Käykää läpi kaikki kerätty palaute (hyvät, huonot ja rumat). Tässä tilaisuuden osassa palaute tulisi ainoastaan esitellä. Tiettyjä palautekohtia koskevat kysymykset ja keskustelu tulisi rajata vähäisiksi (näin varmistetaan, että ehditte käydä läpi kaiken palautteen eikä aika kulu yhteen tai kahteen kohtaan)
  6. Palautteesta ja kysymyksistä keskusteleminen: Kerää osallistujien ajatukset, mielipiteet ja vastaukset. Ovatko he samaa mieltä palautteesta? Onko tarpeen jakaa lisätietoja tai asiayhteyttä? Keskustelkaa tuloksista ja kirjatkaa ne.
  7. Parannustoimien ja seuraavien vaiheiden suunnittelu: ideoikaa palautteen perusteella projektiryhmälle oppeja ja toimenpiteitä, joiden avulla voidaan tehdä parannuksia. Toistuvien tai monimutkaisten ongelmien kohdalla kannattaa tehdä nopea perussyyn analyysi, jotta voidaan selvittää, miksi ongelma ilmenee. Pyytäkää vapaaehtoisia ottamaan vastuulleen mahdolliset jatkotoimet tai parannuskohteet.
  8. Palautteen ja parannusten yhteenveto: Tee ennen tilaisuuden päättämistä lyhyt yhteenveto ja korosta kokousmuistioihin kirjattua palautetta sekä mahdollisia seuraavia vaiheita tai toteutettavia toimenpiteitä.
  9. Kiitokset ja tilaisuuden päättäminen: Kiitä osallistujia heidän ajastaan ja palautteestaan. Kerro mahdollisesti järjestettävien jatkotilaisuuksien tiedot. Kerro lisäksi, minne tilaisuuden aikana kerätty palaute tallennetaan ja voivatko osallistujat saada sen myöhemmin käyttöönsä (esimerkiksi jaetulla Google Drivella).

Projektien retrospektiiveja koskevat usein kysytyt kysymykset

Tässä on joitakin usein kysyttyjä kysymyksiä projektien retrospektiiveistä. Jos etsit perusteellista tietoa ketteristä menetelmistä yleisemmin, harkitse ketterän menetelmän sertifiointia.

Mikä on sprintin retrospektiivin ja projektin retrospektiivin ero?

Sprintin retrospektiivi on ketterään työnkulkuun kuuluva tapahtuma, joka toteutetaan sprintin tai iteraation lopussa. Sprintin retrospektiivin tarkoituksena on tarkastella, mitä parannuksia seuraavien ja tulevien sprinttien prosesseihin voidaan tehdä.

Koska sprintit ovat ajallisesti rajattuja tapahtumia (kestoltaan yleensä 2 viikosta kuukauteen), sprintin retrospektiivi tuottaa palautetta ja parannusehdotuksia projektin aikajanan lyhyeltä ajanjaksolta, kun taas projektin retrospektiivissä tarkastellaan koko projektia: mikä sujui hyvin, mikä ei sujunut hyvin ja mitä parannuksia tulevissa projekteissa voidaan tehdä.

Pitäisikö asiakkaan osallistua?

Se riippuu siitä, millaista palautetta haluat kerätä projektin retrospektiivin aikana. Jos haluat palautetta projektin viestinnästä, sidosryhmien osallistamisesta ja tuotoksista, vastaus on kyllä. Jos palaute koskee projektiryhmän suoriutumista, ehkä, mutta todennäköisesti ei. Päätös on projektipäällikön ja ryhmän harkinnassa.

Kenen pitäisi vetää projektin retrospektiivi?

Projektipäällikkö tai Scrum Master toimii yleensä retrospektiivin vetäjänä, mutta kuka tahansa projektiryhmän jäsen, joka on halukas vetämään tilaisuuden, voi tehdä sen. Jos retrospektiivissä saattaa tulla esiin kielteistä tai kiistanalaista palautetta, kannattaa harkita puolueetonta ulkopuolista vetäjää.

Eräässä organisaatiossa, jossa työskentelin aiemmin, projektipäälliköitä pyydettiin vetämään muiden organisaation projektiryhmien retrospektiivejä puolueettoman vetäjän varmistamiseksi. Samalla oman projektiryhmän projektipäällikkö pystyi osallistumaan tilaisuuteen täysipainoisesti sidosryhmänä.

Mitä työkaluja voin käyttää projektin retrospektiiviin?

Organisaatioiden käytettävissä on useita erinomaisia ketterän projektinhallinnan ohjelmistotyökaluja retrospektiivien toteuttamiseen. Tässä muutamia suosituksia.

Verkkoyhteistyö ja virtuaaliset valkotaulut
  • Miro tai Mural: molempien työkalujen avulla käyttäjät voivat luoda virtuaalisia valkotauluja ja työskentelyalustoja, joille ryhmät voivat lisätä palautettaan. Ihanteellisia etäryhmille.
  • IdeaBoardz: maksuton ja helppokäyttöinen työkalu, jonka avulla käyttäjät voivat luoda mukautettavia verkkotauluja retrospektiivejä varten ja kerätä palautetta nimettömästi virtuaalisten muistilappujen avulla.

Tutustu myös muihin yhteistyökaluihin (ketteriin projekteihin tai muihin tarkoituksiin).

Retrospektiiviohjelmistot
  • Atlassian Confluence: verkkopohjainen yhteistyötila, jossa on valmiita retrospektiivipohjia. Hyvä työkalu, jos organisaatio käyttää muita Atlassian-tuotteita, kuten Jiraa
  • GoRetro: mukautettava ketterän kehityksen retrospektiivien työkalu, joka tarjoaa useita maksuttomia pohjia
Kasvokkain tai paikan päällä toteutettaviin retrospektiiveihin
  • Valkotaulu ja pyyhittävät valkotaulutussit
  • Post-it-laput
  • Fläppipaperi
  • Kamerapuhelin, jolla voi ottaa kuvia valkotauluista tai fläppipapereista myöhempää tallentamista ja jakamista varten

Mikä on retrospektiivin, opittujen asioiden käsittelyn ja projektin jälkiarvioinnin ero?

Opittujen asioiden käsittely muistuttaa projektin retrospektiiviä. Jos käytät vesiputousmenetelmää projektin toteuttamiseen, opitut asiat käsitellään projektin päättämisvaiheessa. Tarkoituksena on dokumentoida hyödylliset opit ja havainnot, joita tulevat projektiryhmät voivat hyödyntää toimintansa parantamisessa.

Retrospektiivit ovat peräisin Scrum– eli ketterän kehityksen menetelmästä, ja niitä toteutetaan yleensä inkrementin eli ”sprintin” päättyessä. Niiden tarkoituksena on pyytää ryhmää pohtimaan, mikä sujui hyvin, mikä ei sujunut hyvin ja mitä valmistuneen inkrementin perusteella voitaisiin parantaa.

Retrospektiivien tavoitteena on löytää parannuksia, jotka voidaan toteuttaa välittömästi, kun taas opittujen asioiden käsittely tuottaa lähtötietoja tulevia parannuksia varten. Jos projekti on päättynyt ennenaikaisesti (joko se peruutettiin ennen suunniteltua päättymistä tai sitä ei saatu onnistuneesti päätökseen), voidaan tehdä jälkiarviointi sen selvittämiseksi, mitä projektin aikana tapahtui.

Onko projektin retrospektiivi tehtävä projektin lopussa?

Ei – projektin retrospektiivi voidaan ja pitäisi tehdä missä tahansa projektin vaiheessa. Jos merkittävä virstanpylväs tai vaihe on saatu päätökseen, retrospektiivin järjestäminen voi olla järkevää. Samoin retrospektiivin voi tehdä, jos projektin aikana on tapahtunut jotain odottamatonta. Tärkeintä on, että palaute kerätään ja että tarvittavat parannukset toteutetaan sovittujen vaiheiden ja toimenpiteiden avulla.

Mitä seuraavaksi?

Lue lisää retrospektiivejä ohjaavista ketteristä periaatteista sekä alkuperäisestä Ketterän kehityksen manifestista, jossa nämä periaatteet määriteltiin, ja liity DPM:n jäseneksi saadaksesi pääsyn Slackissa käytäviin ketteryyttä (ja paljon muuta) käsitteleviin keskusteluihin yhdessä satojen muiden digitaalisten projektipäälliköiden kanssa!