Priorisointia, tavoitteita ja tehtävänhallintaa

Joulukuu kului joulukiireissä, joten jäi blogin kirjoittaminen taas vähemmälle. Testaukseen liittyviä ajatuksia loppuvuosi herätteli työn lisäksi parinkin testaukseen liittyvän tilaisuuden tiimoilta.

Toinen näistä oli testausyhdistyksen järjestämä teemailta, jonka aiheena oli ajanhallinta. Teemu Vesalan ansiokkaan alustuksen pohjalta keskusteltiin erilaisista haasteista, joita oman työn aikatauluttamiseen liittyy.

Aihetta käsiteltiin monesta kulmasta, erityisesti haasteena nostettiin esiin mahdollisuudet uppoutua keskeytyksettä työhön ja toisaalta myös irtautua siitä. Keskustelu oli kiinnostavaa ja tarjosi hyviä uusia ajatuksia, vaikka monet näkökulmat muistuttivatkin minua lähinnä siitä, miksi olen nauttinut niin paljon mahdollisuudesta siirtyä isosta firmasta pieneen.

Minun ajankäytölliset haasteeni eivät tällä hetkellä liity siihen, että kalenterini täyttyisi turhista palavereista, joihin on vaellettava valtavan rakennuksen toisesta päästä toteamaan, että tapaamisen avainhenkilöt eivät ole edes tulossa paikalle. Työsähköpostini ei täyty kummoistakaan vauhtia, eivätkä työtäni rajoita byrokraattiset käytännöt, joista ei itse työn kannalta ole mitään hyötyä. Organisaation sisäisten siilojen väliset haasteet ovat muisto vain.

Sen sijaan haasteita syntyy ajankäytön priorisoinnista, tekemisen fokuksoimisesta ja tehtävänhallinnasta.


Kun on kiire saada valmista, tekemistä täytyy priorisoida. Se tarkoittaa sitä, että oleellisimmat asiat tehdään mahdollisimman hyvin, ja vähemmän tärkeät unohdetaan väliaikaisesti.

Tällaista toimintatapaa voi perustella useammallakin tavalla.

Ensiksikin, joskus deadlinet ovat ihan aitoja deadlineja. Jos ominaisuus X ei ole vielä ollenkaan käytettävissä kun sitä pitäisi esitellä messuvieraille, tai asiakkaan aikataulukriittinen asia Y pitäisi saada vietyä sillä läpi, aikataulua venyttävä pilkunviilailu tulee kalliiksi.

Toisekseen, joskus asiakkaasta on mahdotonta saada irti riittäviä tietoja jonkin toiminnallisuuden valmiiksisaattamiseksi ennen kuin hänet päästetään koekäyttämään sitä. Silloin ei välttämättä ole tarkoituksenmukaista tehdä sitä kovin pikkutarkasti heti ensimmäisellä kierroksella.

Kolmanneksi, työtä voi sisäisessäkin kehityksessä tehdä ja jaksottaa eri tavoin. Yhden päivän aikana ei voi tehdä kaikkea, eikä testausta ole mielekästä lähestyä joka kerta täsmälleen samalla tavalla. Vain pieni osa tehtävistä on sellaisia, joissa pikaisesta vilkaisusta ennen seuraavaa kontekstin vaihtamista olisi minkäänlaista hyötyä, ja siksi työtä pitäisi saada tehdä riittävän pitkinä sessioina. Toisaalta usein tauon ottaminen on välttämätöntä uusien lähestymistapojen löytämiseksi, ja siksi myös mahdollisuus vaihdella tehtävien välillä on hyvä asia. 

Nämä kaikki asiat vaikuttavat siihen, että kaikkea ei tehdä kerralla täydellisesti, vaan tietyt polut ja tietyt piirteet jäävät perusarjessa vähäisemmälle huomiolle kuin toiset.

Priorisoinnissa on kuitenkin riskinsä.

Yksi riski on vääränlainen priorisointi, eli se että keskitytään kuitenkin vääriin asioihin, tai ainakin jotain tärkeää jää huomaamatta.

Toinen asia on jälkien siivoaminen deadlinen jälkeen. Jääkö tekemisen puutteista riittävät tiedot, että tekemätön työ on mahdollista muistaa dl:n jälkeen? Tuleeko se tehtyä? Onko olemassa jonkinlaista suunnitelmaa, miten epämääräiseksi jääneet asiat saadaan tarkentumaan? Onko analysoitu asiakkaan tarvetta käyttöönottoon liittyvään lähitukeen? Ymmärtävätkö kaikki, että vielä ei ole valmista, vaikka lyhyen tähtäimen tavoite saavutettiin?

Ajanhallinnan kannalta haasteellista on löytää tapa huolehtia aikataulukriittisten asioiden riittävän nopeasta etenemisestä pitäen samalla vähemmän kiireiset asiat aidosti työlistalla, niin että nekin tulevat hoidetuksi. Jatkuvalla kiireellä on tapana pitkällä aikavälillä kostautua. Teknisen velan lisäksi ongelmaksi saattaa muodostua se, että tuotteen kasvaessa pienen prioriteetin asioiden imagovaikutus voi käyttäjän silmissä kasvaa yllättävän merkitykselliseksi.

Samalla omaa tekemistä pitää osata arvioida kriittisesti. Tuliko työ tehtyä riittävän hyvin? Tuliko mieleen asioita, jotka olisi syytä lisätä backlogiin? Oliko tekeminen hyödyllistä? Mikä on oleellista siinä mitä teen, ja miten pian tätä on tarpeen arvioida uudelleen? Mikä minua juuri nyt häiritsee käsillä olevien tehtävien asettamien tavoitteiden ulkopuolella? Mitä minun juuri nyt olisi hyödyllistä opetella? Onko jotain mihin liittyen pitäisi pyytää apua?

Rutiinien keskellä on löydettävä tavat katsoa tilannetta konkreettisten tehtävien ulkopuolelta ja saada palautetta tekemästään työstä. Asettaa pidemmän tähtäimen tavoitteita ja etsiä uutta. Kyseenalaistaa.

Jotta tämä olisi mahdollista, on löydettävä säännöllisesti tilaisuuksia irtautua projektia suoraan edistävistä tehtävistä. Vähän päivittäin, ja silloin tällöin ihan kunnolla.

Näin ruuhkavuosirumban keskellä tuntuu välttämättömältä, että tähän voi varata myös ihan oikeaa työaikaa. Silti sen ajan ottaminen vaatii hieman itsekuria.


Minulle luontevin tapa jäsentää ajatuksiani on kirjoittaminen. Alkavan vuoden tavoitteisiin voisinkin asettaa aktiivisemman blogin kirjoittamisen. Aika näyttää, kuinka moni sepustukseni lopulta tulee julkaistua. Toivottavasti lopputuloksesta on iloa myös muille.

Mitä bugille tapahtuu?

Kaikki tietävät, mitä ensin tapahtuu. Testaaja lähtee käymään läpi testitapauksia, hetken päästä prosessi katkeaa. Tilanne dokumentoidaan tekstein, kuvakaappauksin, nauhoittein, miten milloinkin, kuitenkin mahdollisimman yksityiskohtaisesti. Sitten se tallennetaan bugitietokantaan ja jäädään odottamaan korjausta.

Mutta mitä sitten tapahtuu?

Testaaminen on välttämätöntä toimintavarman ohjelmiston rakentamiseksi. Joskus voi kuitenkin käydä niin, että testaus tuottaa bugeja paljon nopeammin kuin niitä ehditään korjaamaan. Yksikin testaaja saattaa raportoida kymmeniäkin bugeja päivässä, ja samaan aikaan kehittäjät ovat ehkä kiinni uusien ominaisuuksien kehittämisessä tai jopa muissa projekteissa. Tai jos bugeja korjataankin, yksittäinen korjaus saattaa avata testaajalle tien löytää monta uutta bugia. Muutamassa päivässä bugitietokanta saadaan niin täyteen, että sen perkaaminen käy työstä. Ja todella se perkaaminen vie myös aikaa. Bugien korjaamista ohjataan käymällä listaa läpi, delegoimalla ja priorisoimalla. Kehittäjät etsivät itselleen mielekkäitä kokonaisuuksia korjattaviksi. Testaaja kahlaa läpi aktiivisten bugiraporttien listaa tarkistaakseen, muistiko eilen raportoida sen yhden kummallisen bugin, jonka selvittely jäi kesken, tai etsii viime viikolla löytyneen bugin täydentääkseen sen kuvausta uudella tilanteella, jossa sama ongelma toistuu. Kenties muukin projektihenkilöstö raportoi löytämiään bugeja joko suoraan samaan tietokantaan luoden duplikaatteja, tai kyselemällä sähköpostitse testaajalta, joko olet huomannut tämän ja tämän asian. Kehittäjien tehdessä uutta toiminnallisuudet saattavat myös muuttua tavalla, jonka myötä vaivalla dokumentoituja bugeja ei enää saada toistumaan, ja niiden moniportainen käsittely vie turhaan aikaa niin kehittäjiltä kuin testaajilta.

Ei kuulosta ihan hirveän tehokkaalta.

Soppa saadaan kasvamaan entisestään, kun kirjataan bugeina kaikki testaushavainnot, ja oletetaan, että ne hoituvat kehittäjien ja testaajien välisellä pingiksellä.

Testaaja ei kuitenkaan yleensä ole projektipäällikkö, ei suorassa yhteydessä asiakkaaseen eikä vastuussa määrityksestä tai vaikkapa käyttöliittymäsuunnittelusta. Tarkentavat kysymykset, joiden oleellinen sisältö on "pitääks tää oikeesti tehdä?" tai "mitä tää määrityksen kohta oikeesti tarkoittaa?" pitäisi ohjata jonnekin muualle. Esimerkiksi suoraan asiakkaalle. Testaaja kun ei voi yksinään antaa kehittäjälle lupaa oikaista.

Miten tilanteen sitten saisi pysymään hanskassa?

Bugien löydettävyyttä parannetaan paitsi hyvällä nimeämisellä myös linkityksillä (esim. käyttötapauksiin) ja luokitteluilla (esim. mihin toiminnallisuuteen liittyy). Sotkun syntymistä voi vähentää myös niin, että sovitaan tarkkaan testauksen tavoitteet, ja vain niihin liittyviä bugeja raportoidaan. Jätetään se kaikesta jännästä nipottaminen vähän myöhempään, kun keskeisimmät asiat toimivat. (Tämä toki tarkoittaa, että testaukseen on oltava käytettävissä riittävästi kalenteriaikaa, eli testaus on aloitettava heti kun toteutus on siinä vaiheessa, että testaaminen on mielekästä.) Voidaan myös jakaa testaushavainnot esim. bugeihin, keskeneräisiin toiminnallisuuksiin ja lähdemateriaalien ongelmiin, ja sopia näille toisistaan poikkeavat käsittelytavat. Kunhan projektissa mietitään, mitä testaukselta aikuisten oikeasti halutaan, ja miten organisoimalla se saadaan mahdollisimman hyvin tukemaan ja mahdollisimman vähän tukkimaan kehitystä.

Jos kaikki oikeasti tietävät, ettei olla vielä stabilointivaiheessa, on hyvä jos testaaja voi työskennellä kehittäjien lähellä, jolloin tieto kulkee myös ilman bugitietokantaa. Kysymyksiä on silloin helppo pallotella suullisesti, ja arvioida yhdessä, miten paljon testauspanoksia kannattaa laittaa mihinkin toiminnallisuuteen juuri nyt. Tätä keskustelua on toki mahdollista käydä sähköisestikin, jos vain kaikki osapuolet ymmärtävät sen olevan yhteinen etu.

Lopulta tärkeää on myös se, ettei pelätä nostaa kissaa pöydälle. Jos toteutuksen ja testauksen lähdemateriaaleissa kuten määrityksessä on ongelmia, joiden takia ei ole mielekästä jatkaa, tieto tästä pitää saada mahdollisimman pian etenemään sinne, missä asioista päätetään. Ongelmien raportoiminen ei koskaan saa hilpeää vastaanottoa, mutta tämä asia ei yleensä odottamalla parane.Näiden maton alle lakaistujen asioiden esiin nostaminen on yksi testauksen tärkeimmistä tehtävistä, ja niiden edistämiseen onkin löydyttävä kanavat, joita käyttäen ongelmat myös ratkotaan.