Tee pre-mortem Jirassa: löydä julkaisuriskit ennen niiden toteutumista
Tuo lyhyessä tiimikeskustelussa esiin mahdolliset epäonnistumiset, vertaa seurauksia ja sovi, kuka pienentää kutakin riskiä.
Julkaisu voi näyttää Jirassa valmiilta, vaikka tiimillä on kirjaamattomia huolia. Toteutus on lähes valmis, testaus käynnissä ja julkaisupäivä lähestyy. Joku epäilee vanhojen asiakastilien käyttäytyvän eri tavalla. Toinen pelkää tuen selittävän uudet valinnat väärin.
Pre-mortem antaa huolille hyödyllisen lähtökohdan: kuvittele julkaisun jo menneen huonosti ja kuvaa sitten syyt. Harjoitus helpottaa mahdollisista epäonnistumisista puhumista ennen kuin tiimi on kiireinen niiden korjaamisessa.
Tässä oppaassa teemme käytännön pre-mortemin kuvitteelliselle asiakasportaalijulkaisulle ja järjestämme tulokset Power Packin Risk & Pre-Mortem Grid -työkalussa. Tuloksena on pieni riskijoukko, jolla on selvät vastuuhenkilöt, varoitusmerkit ja lieventävät työt.
Valitse julkaisulle tarkka tulos
Tiimimme lisää sähköpostiasetukset asiakasportaaliin. Asiakkaat voivat ottaa valinnaiset tilisähköpostit käyttöön tai pois käytöstä ja saavat edelleen välttämättömät viestit. Maya vastaa tuotetuloksesta, Leo toteuttaa muutoksen, Priya johtaa testausta ja Sam valmistelee tuen.
He valitsevat pre-mortemin paikaksi Jira-tehtävän, joka kuvaa julkaisun yhteisen tuloksen. Liittyvät toteutus- ja testitehtävät pysyvät linkitettyinä tavallisen Jira-prosessin kautta. Keskustelun pitäminen julkaisutehtävän vieressä antaa ihmisille selvän paikan palata siihen.
Ennen tapaamista Maya kirjoittaa yksinkertaisen rajauksen: arvioidaan asiakaskokemus, sähköpostitoiminta ja tuen valmius asetusvalintojen ensimmäiseen julkaisuun. Tiimi tarkastelee julkaisua ja ensimmäistä käyttöviikkoa. Raja estää keskustelua muuttumasta kaikkien mahdollisten portaaliongelmien katselmoinniksi.
Kuvittele epäonnistuminen ennen ratkaisukeskustelua
Aloita konkreettisella kysymyksellä: ”Julkaisusta on viikko. Asiakkaat ovat hämmentyneitä, tukipyynnöt lisääntyneet ja käyttöönotto on pitänyt keskeyttää. Mitä tapahtui?” Kuvitellun tuloksen pitää olla riittävän epämukava herättääkseen ajatuksia ilman, että epäonnistumista pidetään väistämättömänä.
Anna jokaiselle muutama hiljainen minuutti kirjoittaa mahdolliset syyt itsenäisesti. Näin testaajan huoli tai tuen havainto pääsee mukaan ennen kuin ensimmäinen itsevarma selitys hallitsee keskustelua. Pyydä kuvattavia syitä yleisten toteamusten kuten ”laatu oli heikko” sijaan.
Jakakaa sitten tilanteet vuorotellen. Kerää ensimmäisellä kierroksella huolet ja selkeytä niiden merkitys. Säästä väittely parhaasta ratkaisusta myöhemmäksi. Osallistujan pitäisi voida nostaa hankala mahdollisuus joutumatta heti puolustamaan täyttä korjaussuunnitelmaa.
- Nykyiset asiakkaat näkevät asetuksia, jotka eivät vastaa heidän nykyisiä sähköpostivalintojaan.
- Käyttöliittymä antaa ymmärtää, että välttämättömät sähköpostit voi poistaa käytöstä.
- Tukiohjeet kuvaavat valintoja, jotka muuttuivat ennen julkaisua.
- Asetuspäivitys näyttää onnistuneelta, vaikka taustalla oleva muutos epäonnistuu.
Nämä ovat esimerkin kuvitteellisia tilanteita. Oman listan pitäisi tulla ihmisiltä, jotka ymmärtävät työn, riippuvuudet ja asiakaskokemuksen. Power Pack kirjaa keskustelun; tiimi arvioi, mitä voi tapahtua.
Muuta huolet tunnistettaviksi riskikuvauksiksi
Hyödyllinen riski kuvaa mahdollisen tapahtuman ja sen seurauksen. ”Migraatio” on aihe. ”Nykyiset asetusarvot muunnetaan väärin, joten osa asiakkaista saa valinnaisia sähköposteja, joiden he odottivat loppuvan” on tutkittava tilanne.
Yhdistä päällekkäisyydet kadottamatta erilaisia seurauksia. Useat vanhoja tilejä koskevat huolet voivat johtua yhdestä syystä. Harhaanjohtava nimi ja epäonnistunut tallennus voivat molemmat hämmentää asiakasta, mutta vaativat eri tarkistukset ja kannattaa yleensä pitää eri riskeinä.
Kysy jokaisen tilanteen kohdalla, mitä tiimi huomaisi varhain. Varhainen hälytysmerkki on havaittava asia, joka ansaitsee huomiota. Esimerkissämme ero nykyisten tiliasetusten ja ehdotettujen migraatioarvojen välillä on hyödyllisempi kuin ”asiakkaat voivat valittaa”. Sen voi tarkistaa ennen julkaisua.
| Nykyiset asetukset muunnetaan väärin | Asiakkaat saavat ei-toivottuja valinnaisia sähköposteja | Esimerkkitili näyttää eron migraatioharjoituksen jälkeen |
| Välttämättömien sähköpostien sanamuoto on epäselvä | Asiakkaat odottavat viestien loppuvan, vaikka se ei ole mahdollista | Tarkistaja tulkitsee valinnan koskevan kaikkia sähköposteja |
| Tukiohje jää jälkeen | Tuki antaa vääriä ohjeita | Julkaisuehdokas poikkeaa ohjeen kuvakaappauksista |
Sovi todennäköisyyden ja vaikutuksen merkitys
Power Pack tarjoaa 3×3- tai 5×5-matriisin ja laskee vakavuuspisteet kertomalla todennäköisyyden vaikutuksella. Käytä pisteitä keskustelun ja järjestämisen tukena. Kyse on subjektiivisesta arviosta, ei ennusteesta epäonnistumisten määrästä tai odotetun tappion laskennasta.
Ensimmäiseen tapaamiseen tiimimme valitsee 3×3-matriisin ja sopii yksinkertaiset arvosanojen merkitykset. Todennäköisyys yksi tarkoittaa vähäistä nykyistä näyttöä; kaksi uskottavaa mutta tutkittavaa tilannetta; kolme vahvoja syitä odottaa tapahtumaa ilman toimia. Nämä ovat tiimin työmääritykset.
Vaikutus määritellään asiakkaan ja julkaisun seurausten kautta. Yksi tarkoittaa rajallista haittaa, kaksi merkittävää jatkotoimia vaativaa häiriötä ja kolme vakavaa asiakasongelmaa tai syytä keskeyttää julkaisu. Toinen tiimi voi tarvita eri määritelmät omaan ympäristöönsä.
Priya arvioi väärän migraation todennäköisyydeksi kaksi ja vaikutukseksi kolme, jolloin pisteitä tulee kuusi. Tiimi käsittelee arvion taustaoletukset: uutta muunnosta ei ole vielä harjoiteltu edustavilla vanhoilla tileillä. Puuttuva näyttö on tärkeämpää kuin luvun näennäinen tarkkuus.
Pidä asteikko samana ensimmäisiä riskejä verratessa. Matriisikoon vaihtaminen skaalaa nykyiset arviot uudelleen, joten tarkista sijainnit tarkkuuden muuttuessa. Uutta sijaintia ei pidä sekoittaa uuteen julkaisutietoon.
Lisää riskit Power Packiin
Avaa Power Pack valitussa Jira-tehtävässä ja valitse Risk & Pre-Mortem Grid. Käytä lämpökarttaa arvioiden jakautumisen näkemiseen ja riskirekisteriä kohtien tarkistamiseen. Voit lisätä riskin matriisisolusta, jos tiedät jo sen alustavan todennäköisyyden ja vaikutuksen.
Kirjaa kullekin kohdalle otsikko, epäonnistumistilanne, varhainen hälytysmerkki ja luokka. Lisää sovitut arviot, lieventämissuunnitelma ja vastuuhenkilö. Power Pack tukee myös lieventämisen tarkistuspisteitä, tilaa ja valinnaista Jira-tehtäväviitettä.
Vastuuhenkilö voi olla Jira-käyttäjä tai ulkoinen henkilömerkintä. Valitse joku, joka koordinoi vastatoimen ja tuo puuttuvan näytön tiimille. Henkilön nimeäminen matriisiin ei luo Jira-tehtävää, osoita nykyistä tehtävää hänelle tai anna pääsyä siihen.
Tarkista tallennustila ennen päivitetyn matriisin pitämistä jaettuna. Muutokset tallennetaan tehtävään, eikä paikallinen tila tai uudelleenyritys vahvista kollegan jo näkevän uusinta kohtaa.
Anna jokaiselle tärkeälle riskille käytännön vastatoimi
”Testaa perusteellisesti” on vaikea seurata. Migraatioriskiin Priya ehdottaa harjoitusta edustavilla nykyisillä tilitiloilla ja sen jälkeen syntyvien asetusten vertailua odotettuun sähköpostitoimintaan. Leo tutkii poikkeamat. Priya pysyy riskin vastuuhenkilönä ja tuo tuloksen julkaisukatselmointiin.
Jaa vastatoimi edistymistä näyttäviin tarkistuspisteisiin. Tiimi voi valita edustavat tapaukset, suorittaa harjoituksen, tarkistaa erot ja kirjata jäljelle jäävän epävarmuuden. Tarkistuspisteet jäsentävät toimintaa, kun varsinainen näyttö pysyy liittyvässä testi- tai toteutustyössä.
Jos lieventäminen tarvitsee oman Jira-tehtävän, luo ja osoita se tavallisessa työnkulussa ja lisää avain sitten riskin viitteeksi. Viite helpottaa yhteyden seuraamista; se ei luo työtä automaattisesti tai hallitse sen toimitusta.
Palaa tilaan näytön muuttuessa
Power Pack tarjoaa tilat Identified, In Progress, Mitigated ja Accepted. Käytä Identified-tilaa tilanteen kirjaamisen jälkeen ja In Progress -tilaa jonkun työskennellessä aktiivisesti vastatoimen parissa. Sovi odotettu näyttö ennen riskin kuvaamista Mitigated-tilassa.
Accepted voi kuvata tietoista päätöstä jatkaa jäljellä olevan riskin kanssa. Maya voi esimerkiksi hyväksyä pienen tukidokumentaation aukon Samin vahvistettua tilapäisen vastauksen saatavuuden. Kirjaa peruste ja palaa siihen oletusten muuttuessa. Hyväksynnän pitäisi olla ymmärretty päätös, ei tapa siistiä matriisia.
Kysy julkaisukatselmoinnissa vastuuhenkilöiltä hälytysmerkeistä, lieventämisen tuloksista ja jäljellä olevasta epävarmuudesta. Tarkista itsenäisesti jokainen merkittävä rajausmuutos, uusi riippuvuus tai odottamaton testitulos. Päivitä arviot näytön sitä puoltaessa ja selitä arvion muuttuminen.
Voit viedä matriisin Markdown- tai CSV-muodossa suunnittelukeskusteluun. Ilmoita Jira-tehtävä ajantasaisen rekisterin tarkistuspaikaksi. Jaettu vienti on tilannekuva eikä välttämättä enää vastaa tiimin uusinta arviota.
Käytä tapaamista muuttamaan seuraavia tapahtumia
Täytetty matriisi on hyödyllinen, kun se vaikuttaa valmisteluun. Portaalitiimillemme pre-mortem tuottaa migraatioharjoituksen, selkeämmän tekstin ja tarkistuksen tukiohjeen vastaavuudesta julkaisuehdokkaaseen. Jokainen toimi käsittelee tiettyä työntekijöiden esiin nostamaa epäonnistumistilannetta.
Aloita yhdestä julkaisusta, lyhyestä ohjatusta keskustelusta ja pienestä merkityksellisten riskien joukosta. Pidä tilanteet, vastuuhenkilöt ja vastatoimet näkyvissä Jira-tehtävän vieressä Power Packilla. Tuo rekisteri seuraavaan julkaisukeskusteluun, jossa tiimi voi arvioida, mikä todella muuttui.
Aiheeseen liittyvät artikkelit
Pidä päätöslokia Jirassa: muista, miksi valitsitte tämän lähestymistavan
Kirjaa Jira-päätösten tausta, vaihtoehdot ja seuraukset. Luo hyödyllinen päätösloki Power Packilla ja tiedä, milloin valintaa kannattaa arvioida uudelleen.
Hallitse sidosryhmien hyväksyntöjä Jirassa: tee hyväksyntätila selväksi
Anna jokaiselle sidosryhmän tarkistukselle selkeä rajaus, nimetty hyväksyjä ja näkyvä tila. Pidä hyväksynnät ymmärrettävinä julkaisutyön muuttuessa.
Ota yhteyttä
Kysyttävää artikkelista? Keskustellaan teknisistä tavoitteistanne.