tiistai 8. marraskuuta 2016

Testaajan rooli muutoksessa - ajatuksia Ohjelmistotestaus 2016 -tapahtumasta

Osallistuin tänään Ohjelmistotestaus 2016 -tapahtumaan, tällä kertaa vain kuulijana. Puhujat olivat kaikki omalla tavallaan kiinnostavia ja tällä kertaa ohjelmassa oli aikataulutettuna myös keskustelua pareittain ja kaikkien kesken, mikä ehdottomasti auttoi jäsentämään puheita ja saamaan päivästä enemmän irti.

Yksi päivän suurista teemoista oli testaajan roolin muuttuminen. Aiheesta keskusteltiin hieman jo etukäteen facebookin puolella, ja puheenvuorot kiteyttivät asiaa hienosti muutamastakin näkökulmasta. Anssi Lehtelä toi esiin eri roolien välisen kommunikaation, luottamuksen ja yhteisen päämäärän merkitystä, sekä käytössä olevan julkaisumallin vaikutusta testaukseen kohdistuviin vaatimuksiin. Keskeinen viesti oli että testaajalla on mahdollisuus vaikuttaa näihin asioihin mm. testattavuuden parantamiseksi. Sami Söderblom esitteli ajatuksia liittyen antihaurauteen, testauksen toimintaympäristön haasteisiin ja testauskulttuurin luomiseen, tuoden esiin mm. yhteistyön ja kaaoksen sietämisen merkitystä. Maaret Pyhäjärvi kertoi mm. testiautomaatioon liittyvästä roolituksesta ja roolien välisestä yhteistyöstä. Erkki Pöyhönen puhui alihankintaan ja monitoimittajaympäristöön liittyvistä haasteista, ja Antti Niittyviita palvelukokemuksen (miten toinen osapuoli kokee kohtaamisen) merkityksestä arvon luomisessa. Päivän kruunasi Helena Jeret-Mäen puheenvuoro siitä miten kasvetaan testausasiantuntijaksi tai kasvatetaan aloittelevista testaajista sellaisia.

Keskusteluissa testaajan roolin kehityksestä keskeisenä nähtiin automaation merkityksen kasvu, kommunikointitaitojen merkityksen kasvu, sekä tarve integroida testausta paremmin kehitystiimeihin ja tuoda testausajattelua myös sellaisiin asioihin kuin tarjouspyyntöihin ja arkkitehtuurivalintoihin. Puhuttiin siitä, miten tärkeää on löytää itse oma roolinsa (siihen liittyvät vaatimukset ovat kuitenkin osin organisaatiokohtaisia), olla valmis poistumaan mukavuusalueeltaan, oppimaan uutta, etsimään tietoa ja toimimaan myös aktiivisesti muutoksen luomisessa ja ohjaamisessa. Liiketoiminnan ymmärtäminen, tavoitteiden asettaminen sekä kyky palastella unelmia tavoitettavissa oleviin askeliin nähtiin myös taitoina joista on testaajalle paljon hyötyä pyrittäessä ohjaamaan muutosta tavalla jolla testauksen merkitys softaprojekteissa ennemmin kasvaisi kuin pienenisi. Oma aktiivisuus, joustavuus sekä uskallus kysyä ja ehdottaa vievät asioita eteenpäin.

Jäin itse vielä miettimään, miksi ja miten pitkään me testaajat pohdimme omaa rooliamme. Testaus on muuttunut viime vuosien kuluessa paljon, ja oletettavasti se on muuttunut myös aikaisempina vuosina. Esimerkiksi mobiilikäyttöliittymät ja IoT tuovat tällä hetkellä monen testaajankin työhön uudenlaisia haasteita, ja tällaisten asioiden kimpussa painivien testaajien määrä lienee kasvussa. Tänään lopulta lähinnä katsoimme yhdessä taaksepäin, koska puheenvuorot liittyivät esittäjiensä omiin kokemuksiin, eivät tulevaisuudenvisioihin. Toki esitetyt ajatukset olivat paikoin melko radikaalejakin ja monissa organisaatioissa edelleen utopiaa kaukaisesta tulevaisuudesta. 

Kuitenkin, muutos toimintaympäristössämme jatkuu, ja sitä myötä jatkunee myös testaajan roolin muutoksen pohtiminen. Uutta tulee nopeasti, samalla vanha muuttuu hitaasti. Ehkä testauksen kenttä entisestään fragmentoituu tehden entistä vaikeammaksi puhua testauksesta yhtä aikaa konkreettisesti, yleistajuisesti ja koko yleisöä palvellen.

Keitä lienevät he jotka toivovat testausaiheisilta tapahtumilta puheenvuoroja testaajan roolin muutoksesta? Etsivätkö he tukea toiminnalleen aallonharjalla, uudenlaisissa toimintaympäristöissä? Hakevatko he uutta suuntaa vanhoja toimintamalleja noudattavissa yrityksissä? Vertaistukea muuttuvassa maailmassa luovimiseen? Tapoja nostaa arvoaan potentiaalisten työnantajien silmissä? Keinoja muuttaa itse maailmaa? Mitä he tavoittelevat toivoessaan tämän aiheen käsittelyä, vai toivovatko he tavoitetta?

maanantai 17. lokakuuta 2016

Kuka maksaa ja kenen kortilla?

Minulla on ikävä taipumus toivoa softilta ominaisuuksia joita niiden speksaajat eivät ole nähneet tarpeellisiksi toteuttaa. Yksi alue, jolla olen erityisen hämmästynyt valtavasta kuilusta omien toiveitteni ja vakiintuneiden toteutusten välillä liittyy verkkomaksamiseen.

Netissähän on äärimmäisen helppoa maksaa. Ei tarvitse kuin syöttää luottokorttitietonsa lomakkeelle voidakseen tehdä ostoksia mistä päin maailmaa tahansa. Monet palvelut käyttävät vakiintuneita maksamissovelluksia kuten PayPalia, mikä lisää luotettavuuden tunnetta ja helpottaa elämää kun niitä luottokorttitietoja ei tarvitse joka kerta syöttää erikseen. Myös älypuhelinten sovelluskauppoihin voi helposti tallentaa luottokorttitietonsa, minkä jälkeen ostosten tekeminen on äärimmäisen helppoa.

Mikä minua sitten riepoo?

Käyttötapaus 1: Mainosajan ostaminen yhdistykselle


Harrastan yhdistystoimintaa ja siihen liittyen osallistun yhdistyksemme Facebook-sivun ylläpitämiseen. Silloin tällöin meillä on tapahtumia, joita on tarpeen mainostaa, ja tällä hetkellä tähän järkevin kanava on Facebook. Se tarjoaakin helpon työkalun tapahtumien maksulliseen promoamiseen PayPalin avulla.

Se mikä itseäni toteutuksessa korpeaa on, että minun oletetaan yksinkertaisesti syöttävän maksutietoni ja jäävän tyytyväisenä odottelemaan kampanjan etenemistä.

Kun ensimmäisen kerran syötän Facebookiin PayPal-tunnuksiani, minulle ei millään tavalla kerrota, edellytetäänkö minulta myös seuraavalla kerralla kirjautumista PayPal-tunnuksilla (ei edellytetä). Minulle ei myöskään kerrota, liitetäänkö PayPal-tunnukseni henkilökohtaiseen tiliini vai promottavan yhdistyksen tietoihin. Jälkimmäinen vaihtoehto toki tuntuu epätodennäköiseltä, mutta kun kuitenkin suoritan maksua yhdistyksen profiilin kautta, ja tuohon samaan profiiliin on liitetty useita henkilökohtaisia facebook-tunnuksia, minun mieleni olisi aika paljon kevyempi jos minulle ihan eksplisiittisesti kerrottaisiin, että muilla tunnuksilla kirjautuneet eivät pääse tekemään yhdistyksemme nimissä ostoksia minun luottokortillani. Toki voi olla että Facebook ei tiedä vastausta tähän kysymykseen. Joskus vähemmän tärkeät asiat vain toimivat niin kuin ne sattuvat toimimaan kenenkään ottamatta kantaa siihen miten niiden pitäisi toimia.

Sinänsä koen hieman hermostuttavaksi myös sen, että omalta facebook-tililtäni voi koska vaan tehdä PayPal-maksuja kirjautumatta erikseen PayPaliin. Olisi naiivia ajatella, että kukaan muu ei voisi koskaan kirjautua facebookiin minun käyttäjätunnuksellani. Eikä salasanaani edes tarvitse saada selville, jos vie kännykkäni. Yksi suuria pettymyksiäni iPhonen kanssa oli se että puhelimen lukituskoodiin ei saanut kuin neljä merkkiä, mikä tekee sen luvattoman avaamisen ihan mahdolliseksi. Ja jos sen saa auki, pääsee kirjautumatta käsiksi niin sähköposteihini kuin sosiaalisen median tileihini. Toki jos näin käy, facebook-mainosten ostaminen luottokorttitiedoillani on todennäköisesti huolistani vähäisin. Silti, ihan periaatteen vuoksi, nukkuisin yöni paremmin jos jokainen maksutapahtuma luottokortiltani vaatisi erikseen kirjautumisen PayPaliin. Nyt saan tämän toteutumaan vain vaihtamalla PayPal-tilini salasanaa jokaisen facebook-maksun jälkeen. Kuinka käytännöllistä!

Käyttötapaus 2: Lapsen mobiilipelit


Meidänkin talouteemme on saatu erilaisia mobiililaitteita, joihin voi ladata jos jonkinlaista peliä. Monet pelit maksavat vähän rahaa, ja ilmaispeleissäkin pelaaminen usein muuttuu mielekkäämmäksi jos ostaa siihen vähän jotain ihan oikealla rahalla. Tämä on ihan fine, olen oikein tyytyväinen jos lasteni kulutustottumukset muuttuvat aineettomampaan suuntaan, sanotaanko vaikka että taloudessamme on jo ihan riittävä määrä Lego-palikoita.

Se mikä minua riepoo, on taas kerran se, että lasteni käyttämät mobiililaitteet ottavat auliisti vastaan luottokorttitunnukseni, mutta eivät kerro, miten helppo niillä on tehdä uusia ostoksia.

Surfacen sovelluskaupan sain aikanaan toimimaan niin, että lapset kirjautuivat laitteelle omilla tunnuksillaan mutta sovelluskauppa vaati minun tunnukseni, ja tällöin maksamisen yhteydessä vaadittiin aina kirjautumista erikseen. Kännyköihin en ole löytänyt tällaista vaihtoehtoa. Oletusarvoisesti luottokorttitiedot syötetään laitteeseen suoraan, minkä jälkeen lapsi saa omilla tunnuksillaan tehdä ostoksia vapaasti.

Esimerkiksi Momio kertoo rajoittavansa käyttäjien ostoksien euromäärää jättilaskujen ehkäisemiseksi, mutta itse koen että jättilaskut eivät ole se suurin ongelma. Ne huomataan, ja niistä voi saada rahansa takaisin. Sen sijaan pienemmät ostokset voivat jäädä luottokorttilaskulta huomaamatta, ja niistäkin voi ajan mittaan kertyä melkoiset summat. Haluaisin tietää ennen kuin ostan nyt alennuksessa olevan Momio Plussan lapselleni, onko minulla tuon ostoksen jälkeen muuta tapaa estää lastani tekemästä lisää ostoksia luottokortillani kuin pyytää pankkiani mitätöimään korttini ja lähettämään minulle uuden.

Tykkään siitä perinteisestä toimintatavasta, jossa lapsen viikkorahan suuruuden päättävät vanhemmat. Avoin piikki luottokortilleni on aivan tolkuton ajatus. Sitä paitsi eikö toisen henkilön luottokortilla maksaminen ole luvatontakin, saati sitten luottokortin antaminen alaikäiselle? Vai voinko yhtä hyvin antaa lapselleni sirukorttini PIN-koodin ja pyytää häntä käymään itse sen kanssa vaikkapa vaateostoksilla?

Olenko vanhanaikainen?


Maksamiseen liittyen on helppo keksiä muitakin potentiaalisia ongelmia. Itse kuitenkin näen keskeisimpänä sen, miten varmaankin käytettävyyttä kovasti ajatellen tällaiset workflowt tehdään mahdollisimman helpoiksi. Käyttäjää ei häiritä asioilla jotka voisivat saada hänet kyseenalaistamaan, kannattaako luottokorttitietojaan tuupata ihan joka paikkaan. Onko tämä alennus todella sen arvoinen, että jätän taas kerran luottokorttipiikkini jossakin auki?

Ennen aikaan kirjautumistietoihin suhtauduttiin vakavasti, nykyään monilla on niin valtava määrä kirjautumista vaativia järjestelmiä että sitä helposti huokaisee helpotuksesta kun uuteen järjestelmään voikin kirjautua suoraan Google-tilin tai Facebook-tilin avulla, tai tunnukset voi tallentaa selaimen muistiin.

Olisi kuitenkin hyvä, jos järjestelmät aina mahdollistaisivat myös vanhanaikaisen, varovaisen käyttötavan.

En näe kovin vaarallisena, jos joku saa selville tunnukseni vaikkapa verkko-Hesariin tai johonkin nettikauppaan, josta tilaaminen onnistuu vain maksamalla ostokset verkkopankissa. Koen hyvin huolestuttavana, että nuo tunnukseni ovat paremmin suojassa kuin luottokorttitietoni.

Ja tästä syystä olen se natsimutsi jonka lapset jäävät paitsi monesta sellaisesta, joka "kaikilla muilla" kuulemma on.

sunnuntai 2. lokakuuta 2016

Mixed thoughts about context and diversity

This is a strange post in many ways. First of all I usually blog in Finnish because I feel the English speaking testing blogosphere is quite well populated without me unlike the Finnish one, and that's why my intention is to stick with Finnish. Only this time it's not an option because my thoughts are related to a conversation conducted in English. Secondly, my goal in this blog has been to mainly stick with subjects that are quite concretely related to work and this time I'm definitely not doing that. Third, this is a subject that is actually none of my business, I'm just having difficulties keeping my mouth shut. It's about the slide incident, which I did not witness as it happened, I've just been reading about in twitter and in many blog posts, the most relevant ones being from the people who are the actual parties of the incident, Maaret Pyhäjärvi and James Bach.

I'm one of those nice people who like to try to see good in other people even when they behave badly. So I'm not going to speculate on anyones intentions on this issue. I really don't know about that, I'm just under impression that the interpretation of the slide may have been influenced by older incidents. That's what we humans do, we interpret other peoples intentions by how they make us feel and how we see their behavior in respect to our current view of the world and our impression of the person who we are observing. (If you are interested to read more about these phenomena, google Correspondent inference theory.) And this affects on both sides of the incident.

All I'm saying about what happened is that in my opinion the slide would have been ok if it had been given another title not mentioning Maaret. The contents of the slide may tell a lot about the presenter himself and with that title it also gives impressions about his views on Maaret as a person. But even after reading James' explanation on it I find it really hard to see how it tells anything about Maaret, who explains the misinterpretations in her most recent blog post about the incident.

So what makes me curious is how come it is possible to make such big misinterpretations about another persons point of view.

I can't help but to take a rather feminist approach on the subject. There are three clear aspects in the incident that bring to mind the concept of priviledge.

I understand that this is an approach that easily raises difficult emotions so I start by a disclaimer that I fully understand that there may be aspects by which the situation is quite the opposite or by which the situation can be viewed as an argument between two equals. But I find these three aspects quite crucial when considering how the testing community is shaping it self. Who will feel priviledged to be included and who will feel safe to contribute. So these thoughts go beyond Maaret and James and the slide. They are questions to the community on what should be the role of diversity in the future of testing.

The gender talk


When a woman is accused by a man of avoiding debate and valuing niceness over facing facts we are pretty much in the heart of gender stereotypes. It could be that the accuser makes his interpretations through lenses of gender stereotypes, or it is possible that he fails to see how the world works differently for a woman than for a man.

When it comes to how you can build your role in a work environment, the gender issue can actually make a huge deal on how you can get your ideas through. Men may need to have a role of a strong and fearless leader to be taken seriously when raising surprising issues. But a woman is expected to treat people nicely and support men. We are supposed to let men take the leaders role, and when we feel that they are leading us in wrong direction, we are not supposed to speak out about that but rather feed hints to let them realize the situation and make right conclusions themselves. A woman talking like a man is pretty easily stigmatized as a bitch and after that it becomes difficult to get any type of interaction to proceed like things should proceed between adults.

Of course there are huge differences between people and workplaces, most people I've had the pleasure to work with have treated me more as a person (or as a tester) than as a woman, but when facing a new team you always have to be aware that there may be someone who has issues with getting feedback from a woman.

So when we talk about building a testers role as a person who gives feedback that should lead to someone changing the code or changing specifications or expectations or anything, we need to have views from both genders.

But I don't see a reason to highlight that difference. Taking how much we talk about being context driven, it should be obvious that when listening to conference talks we all choose the advice that suit us best. And the more diverse the presented views are, the more chances that everyone will find something useful.


The culture talk


In twitter the conversation has been quite much about whether nice and authentic are contradictory or not. This brings us to the culture talk.

We Finns are raised to value honesty and straight talk. Traditionally we don't do small talk and we don't say polite things unless we really mean them. Finnish writer Jari Tervo has compared us to autistic people, arguing that many things that are related to the spectrum of autism are pretty normal for us Finns.

A story tells about a Finnish manager who delivered a speech in Italy about the situation of their company. Understanding that the Italian employees were not used to such straight words about negative issues he ended his speech saying "I know this didn't sound nice but at least I was being honest." The Italians found this hilarious.

The social rules are very culture specific, and when a Finn talks about growing to being a kinder person towards others, you should interpret it from a perspective that it's a Finn speaking. Naturally you have to know some Finnish people to be aware of this. It is understandable that an American does not know about the peculiarities of the Finnish culture, after all we are an extremely small minority in the global perspective.

But when interpreting another persons intentions it would be good to understand that their cultural context may be very different and that affects on their views. The point where they started their journey was different, and therefore even if their direction is different than yours they may actually be coming closer to you. And if they are actually diverted away from you it may be because that's the only reasonable direction in their culture. A tester from India probably sees niceness quite differently than Finns or Americans.

So I would claim that some important aspects of a testers role are culture specific. Though we all have some idea about American culture we don't all live in it. If conferences are supposed to serve the needs of all testers, there should also be cultural diversity. This is not nourished by emphasizing the interpreted defectiveness of another persons views but concentrating in sharing what are the key points in each speakers own perspective.

The language talk


One more aspect is our mutual language. The most commonly spoken language in the world is probably bad English, as most of us speak some other language as our native tongues.

Language gives us the building blocks of thinking. It forms how we experience emotions, what phonems we are able to distinguish and how we comprehend the world around us. When you switch to another language, you also need to switch to another way of categorizing things. There are surprisingly few words for which the translation is not context specific, which is quite well demonstrated in the nine meanings of "kuusi palaa".

The fact that not all of us are communicating in our native languages emphasizes the importance of explaining our most essential words. It is important to be specific and to discuss the differences of concepts. But it also makes it important to understand that a careless choice of words does not always mean that the other person is deliberately choosing the meaning that comes to your mind. With Maaret this is not a big issue as she speaks and writes very fluently in English, but nevertheless she does not have the priviledge to express herself on her native tongue. How she is treated affects on other peoples willingness to open their mouths.

If we want to support diversity, we need to be able to do the refinement of words in a kind manner. Picking on a person for single words is one way to make sure that the pool of people sharing their thoughts publicly does not get new members easily.

So where are we heading?


To me one of the most fascinating things about testing is diversity. There are so many contexts to which to apply the empirical approach of a tester. So many ways of working and so many ways to position oneself in respect to other roles. So much to learn and so many views to take to sharpen ones mind. And even though the software industry is very male dominant, in testing we have many women both doing the silent work and leading the way.

One of the most revolutional ideas of the industry has been stating that there are no best practices. Another mind blower for me has been "QA stands for Question Asker" which I learned at a Janet Gregory workshop last year. We are working on a craft where discipline and systematic thinking meet curiosity, creativity and intuition.

So the question is, is the testing community willing to live up to these ideas? To accept that what's best for me may not work for you but we can still learn from one another. To question rather than suppress. To convince by sharing ones best, not by judging what feels difficult to understand. To cherrish diversity instead of letting only the priviledged speak for the industry.

And if it is, are there actions to be taken to achieve this?

sunnuntai 25. syyskuuta 2016

Tunnelmia Testing Assemblyn jälkeen

Osallistuin tällä viikolla Helsingissä järjestettyyn Testing Assembly -tapahtumaan. Tiistaina vietin päiväni James Lyndsayn workshopissa opettelemassa tutkivaa testausta ja keskiviikkona olin yksi seminaaripäivän puhujista.

Mitä jäi käteen?

Workshop paitsi tarjosi viihdyttävän koulutuspäivän ja uusia kontakteja myös syvensi ymmärrystä tutkivasta testauksesta ja antoi kirjavinkkejä sekä joukon kiinnostavia linkkejä joiden takaa hakea työkaluja ja lisää tietoa testauksen tueksi. Kiinnostavaa oli myös oppia, millä tavoin yhdessä testaava testaustiimi voi järjestäytyä ja millaisia rooleja ryhmästä löytyä, sekä tietysti päästä kokeilemaan näitä käytännössä. Pieniä ajatussiemeniä syntyi joiden pohjalta pyrin kirjoittamaan jotain blogiinkin syksyn mittaan.

Myös seminaaripäivästä jäi paljon mieleen. Esimerkiksi Aleksis Tulosen puheenvuoro nosti esiin perustavanlaatuisia kysymyksiä, kuinka paljon oikeasti tiedämme siitä miten ja millaisissa olosuhteissa käyttäjät softaa käyttävät, ja miten tärkeää on ymmärtää, miksi uusia ominaisuuksia tehdään, sekä saada keskustella toteutukseen liittyvistä valinnoista.

Sain keväällä Ohjelmistotestaus 2016-tapahtumassa hieman moitteita siitä että en puhunut puheenvuorossani tarpeeksi paljon testauksesta (puheeni liittyi oman työn myymiseen ja jalansijan luomiseen ympäristössä jossa testauskulttuuria ei välttämättä vielä ole), joten oli jännittävää mennä taas puhumaan vähän niin kuin ohi aiheen, sosiaalipsykologiasta eikä testauksesta. Tästä näkökulmasta olikin aika riemastuttavaa löytää monista päivän puheenvuoroista ihan samoja asioita, joista olin puhunut keväällä tai joista puhuin tällä kertaa.

Kaikenkaikkiaan päivän aikana kuuntelemieni esitysten ajatukset voisi kiteyttää niin, että testaajan tärkeimmät taidot liittyvät itse testaamisen ohella empatiaan, aktiiviseen kuunteluun, kyselemiseen ja kommunikaatiotaitoihin. Täytyy yrittää ymmärtää, mitä ja miksi ollaan rakentamassa. Täytyy osata kyseenalaistaa ja uskaltaa seurata vaistojaan ja empiirisiä havaintojaan vaikka organisaatio ei siihen tukisikaan, Täytyy olla rohkeutta poistua mukavuusalueeltaan ja ottaa vastuu omasta ammatillisesta kehittymisestään, oppia jatkuvasti jotain uutta. Täytyy rakentaa yhteistyötä, jotta testauksesta saadaan aidosti positiivinen voimavara organisaatiossa,  ja täytyy osata esittää asiansa rakentavasti ja täsmällisesti. Tulevaisuudessa nämä taidot ovat entistä tärkeämpiä, kun yhä suurempi osa mekaanisemmasta testauksesta pystytään automatisoimaan. Näihin ajatuksiin toivon että omakin esitykseni osaltaan tarjosi rakennetta ja ideoita miten kehittyä paremmaksi työyhteisön rakentajaksi.

Parasta tapahtumassa oli taas mahdollisuus tavata tuttuja, tutustua uusiin ihmisiin ja keskustella. Erityisesti kun on itse organisaationsa ainoa testaaja, on tärkeää päästä silloin tällöin ympäristöihin joissa on mahdollisuus päivittää ajatteluaan muiden testaajien keskellä. Kohtuuhintainen tutorial-päivä ja seminaaripäivä yhdessä luovat mainion kokonaisuuden tähän. Suuret kiitokset järjestäjille! Open space- keskustelut valitettavasti jäivät minulta tällä kertaa kokematta, toivottavasti ensi vuonna saan mahdollisuuden osallistua niihinkin.

Ja kenties ensi kerralla voisin sitten puhua ihan oikeasti testauksesta :)

torstai 15. syyskuuta 2016

Hei, me mobattiin!

Tänään teimme vihdoin sen mistä on silloin tällöin varovasti keskusteltu: kokeilimme mob-koodausta. Olin kesällä lukaissut Maaret Pyhäjärven ja Llewellyn Falcon kirjan mobbauksesta, ja syksyni on alkanut testiautomaatiopainotteisesti. Oma ohjelmointiosaamiseni on hieman hataraa siihen, että saisin itsekseni aikaan ylläpidettävää ja helposti laajennettavaa automaatiota työkaluksi valitsemallamme Canopylla. Se on vieras myös suurimmalle osalle tiimistä. Koska automaatio on meidän kaikkien yhteinen asia, tuntui luontevalta kokeilla mobbausta aiheen tiimoilta.

Olin ehtinyt rakentaa omaan käyttööni jonkin verran ei-niin-kovin-kaunista automaatiokoodia testidatan luomiseen, ja samalla jäsentää ajatuksiani sen suhteen, mitä tavoitteita minulla on automaation suhteen. Lisäksi Canopyn paremmin tunteva kehittäjä oli rakentanut jonkin verran automaatiota. Näiden pohjalta lähdimme liikkeelle tavoitteena oppia käyttämään Canopya sekä tietenkin luoda sitä ylläpidettävää automaatiota.

Mobbaus on meille kaikille käytännössä uutta, eikä se vielä ensimmäisellä sessiolla muodostunut täysin luontevaksi. Tehtävän yksinkertaisuus ja suuret erot osaamisessa Canopyn käyttöön näkyivät myös eroina siinä, miten paljon kukakin oli äänessä. Vaikutelmaksi jäi, että kehittäjät kokivat tekemisen hieman hitaaksi tällä tekniikalla, ja muutaman minuutin välein vaihtuva kirjurinpesti tuntui myös oudolta jo ihan kerralla käytettävissä olevan ajan lyhyyden vuoksi. Tämä ei selvästikään ollut rakkautta ensi silmäyksellä. Toisaalta loppukeskustelumme perusteella sessiossa oli paljon hyvää.

Positiivista oli paitsi minun automaatiotavoitteideni eteneminen, myös se, että Canopyn opettelu selvästi toi kehittäjille paljon ajatuksia siitä, miten he voisivat hyödyntää sitä omassa työssään. Todettiin, että mobbaus sopii hyvin uuden opetteluun yhdessä, ja saatiin aikaan hyvää keskustelua siitä, miten automaatiota lähdetään kehittämään ja mihin kaikkeen sitä voisi käyttää. Vaikka en edelleenkään kutsuisi itseäni automaatio-osaajaksi, kokemus lisäsi paljon myös omaa ymmärrystäni juuri niistä automaatiokoodin rakentamisen periaatteista, joista koin vielä aamulla olevani hyvin pitkälti pihalla. Keskustelu sekä ajattelun ja kirjoittamisen irrottaminen toisistaan tekee työskentelystä helpommin seurattavaa verrattuna tilanteeseen, jossa yksi perehdyttäjä tekee ja selittää tekemistään. Lisäksi oma muistijälki tulee vahvemmaksi kun saa ihan itse konkreettisesti tehdä sitä opeteltavaa asiaa.

Tällaisena suht lyhyenä sessiona mobbaus oli kuulemma myös ihan kivaa (ja sitä se oli minustakin). Ns. oikeiden töiden tekemiseen parikoodaus ja yksilötyöskentely ovat selvästi edelleen suositumpia lähestymistapoja. Nähtiin kuitenkin, että mobbaus voisi olla hyvinkin toimiva lähestymistapa erityisesti refaktorointiin, ja backlogilta löytyikin jo yksi lappu jonka tiimoilta tekniikkaa harkittiin kokeiltavan. Nyt kun ensimmäinen askel on otettu ja mobbausta on kokeiltu, kynnys seuraavan session järjestämiseen on varmasti jo matalampi.

Mobattavien tehtävien valinta tälle porukalle vaikuttaa kuitenkin haasteelliselta. Kun mobbaus itsessään on uutta ja ihmeellistä, tekniikan opettelun kannalta olisi hyvä että käsillä oleva tehtävä ei olisi kovin monimutkainen. Tämän päivän perusteella tuntuu kuitenkin siltä, että yhteisen ajan käyttäminen helppojen tehtävien parissa aiheuttaa monilla meistä jonkinasteista turhautumista. Tämän ongelman voittamiseen ei liene muuta lääkettä kuin pitää sessiot suhteellisen lyhyinä niin kauan kuin tekniikka ei ole luontevaa. Lienee myös parasta silmäillä mobbauksesta kertova kirja läpi uudelleen nyt kun aihe on itselle hieman konkreettisempi.

keskiviikko 25. toukokuuta 2016

Testaajan muuttuva rooli ja Ohjelmistotestaus 2016

Tänä vuonna sain tilaisuuden puhua Ohjelmistotestaus 2016 tapahtumassa, ja hyödynsin samalla mahdollisuuden osallistua tapahtumaan kokonaisuudessaan. Päivistä jäi hyvä fiilis, oikeastaan kaikki esiintyjät onnistuivat tarjoamaan jotakin pohdittavaa, vaikka kaikkien aiheet eivät tietenkään omaan tilanteeseeni verraten olleet niin relevantteja. Koin tilaisuuden myös mukavan kokoiseksi: kun porukkaa ei ollut valtavaa määrää, juttuseuraa oli jotenkin luontevampaa etsiä, ja taukokeskustelut olivatkin antoisia. Ekstraohjelmana pääsin vielä kuuntelemaan Anssi Lehtelän harjoituspuhetta testattavuudesta Nordic Testing Daysin esitystä varten. Nyt pääni viliseekin uusia ajatuksia, jotka toivottavasti ehdin jalostaa itselleni läheisempään muotoon ennen kuin ne pääsevät liikaa haalistumaan.

Oma puheenvuoroni liittyi testaajan roolin muuttumiseen ja perustelemiseen tilanteessa jossa kenties perinteiset vesiputousmallilla toimivat testaustiimit maastamme vähenevät, rekrytointia tehdään kenties aikaisempaa enemmän yrityksiin joissa testausta ei niin hyvin ymmärretä, ja ketterät toimintatavat vaativat muutenkin vähän toisenlaisia taitoja. (Tauolla sain kuitenkin palautetta että puhumani asiat olivat ajankohtaisia myös ainakin yhdessä yrityksessä, jossa testauksella oli pitkät perinteet ja vakiintunut asema, koska testaajien on esimerkiksi ansaittava erikseen jokaisen uuden kehittäjän luottamus.) Samaa aihepiiriä eri näkökulmista käsitteli muutama muukin esiintyjä, ja sitä pohdittiin myös paneelikeskustelussa.

Yksi ajatus esityksessäni liittyi siihen, miten testaaminen ja testaajan rooli voidaan nähdä monella tavalla, erityisesti sellaisten silmin jotka eivät itse ole testaajia. Muiden esityksiä kuunnellessa vahvistui entisestään ajatus, miten erilaisia asioita testaus ja testaajan rooli voivat tarkoittaa myös meille testaajille. Tämä tekee haasteelliseksi puhua seminaareissa testauksesta tavalla, jossa konkretia yhdistyisi kaikkien kuulijoiden kannalta relevanttiin asiaan. Toisaalta moni nykypäivän IT-osaaja vaihtaa työpaikkaa suht tiuhaan, ja sitä kautta hyötyy myös tarinoista jotka eivät itselle ole juuri nyt ajankohtaisia. Jotenkin konkreettisten aiheiden löytäminen tuntuu kuitenkin esiintyjille vaikealta - tässä täytyy itsekin jatkoa ajatellen pohtia tapoja parantaa tilannetta. 

Tällä kertaa konkretian puolesta itselleni antoisin esitys oli Maaret Pyhäjärven esitys ryhmäohjelmoinnista (mob programming), josta sain vihjeitä joiden pohjalta kokeilla tekniikkaa myös omassa tiimissä (plus kirjavinkki jonka kautta hakea lisää ymmärrystä aiheesta). Hyvin konkretiaan menivät myös Katri Halla-Ahon esitys riskipohjaisesta testauksesta, jossa käytiin esimerkein läpi riskianalyysia ja miten sitä voidaan hyödyntää testauksen suunnittelussa ja seurannassa, sekä Karla Niemisen esitys testaajan keskustelutaidoista. Lisäksi testiautomaatioon liittyen käsiteltiin melko konkreettisiakin asioita sekä Jari Mäkeläisen että Disa Kakon esityksissä, joista ensimmäinen tarjosi sekä vinkkejä (kuten automaattitestien liittäminen samaan versiohallintaan missä varsinainen koodikin on) että sitä tuskaa mitä tiedon lisäämisestä tässä maailmassa yleensäkin seuraa (kuten automaatiotyökalujen valtava määrä ja monet tekijät jotka vaikuttavat työkalujen soveltuvuuteen eri käyttötarkoituksiin), jälkimmäinen enemmänkin näkymää niihin kipukohtiin, joita liittyy jokseenkin täydellisen erilaiseen toimintaympäristöön kuin missä itse työskentelen.

Osa esityksistä toi esiin hajautetun tuotannon haasteita. Kotimaisen monitoimittajaympäristön ongelmiin tarjottiin ratkaisuksi eri firmoista tulevien tekijöiden tuomista samaan tilaan tekemään yhteistyötä (joko muodostamaan yhteisen projektitiimin kokoaikaisesti, tai sitten erillisessä integraatiovaiheessa), mikä omien kokemusteni perusteella kuulosti mainiolta idealta. Kansainvälisessä toimintaympäristössä tämä ei ole niin helppoa, esimerkkinä kuitenkin kerrottiin myös tarina siitä, miten scrum on saatu toimimaan tilanteessa jossa tuoteomistaja, projektipäällikkö ja scrum masterit olivat Suomessa, kehittäjät ja testaajat taas Intiassa. Pidän itse melkoisena saavutuksena, että tällaisista lähtökohdista voidaan tulla kertomaan onnistumisista, kun ei se agileen siirtyminen aina ole ihan helppoa niissäkään organisaatioissa, joissa kaikki työskentelevät saman katon alla.

Testaukseen kohdistuvat vaatimukset riippuvat paljon myös toimialasta, esim. nettiviihdealalla AB-testaus ja virheiden päästäminen tietoisesti päiväksi tuotantoon (silloin kun lätkän MM-kisat eivät ole käynnissä) voi olla järkevä toimintatapa, toisena ääripäänä esimerkiksi potilasturvallisuus saattaa jättää niukemmin liikkumavaraa sen suhteen, miten lähellä täydellistä tuotantoon vietävän softan tulee olla. Mobiilitestauksen haasteet kasvavat hiljaksiin jokaisen uuden Android-laitteen myötä, ja esimerkiksi IoT nostaa esiin uudenlaisia kysymyksiä, joita myös testauksen kehittämisessä on tarpeen perusteellisesti pohtia. Maailma muuttuu vauhdilla, ja niin myös se, millaisia taitoja testaamiseen voi tarvita. Testauksen tulevaisuudennäkymistä tuntuikin olevan yhteisymmärrys siitä, että vaatimustaso testaajan osaamista kohtaan on kasvamaan päin.

Renessanssi-nerous alkaa siis olla mahdotonta ohjelmistotestauksen kentällä. Puhtaasti testaustekniikoiden näkökulmasta erilaisten mahdollisten taitojen kirjo on valtava, ja lisäksi monella toimialalla on tarpeen erikoistua juuri tuon alan haasteisiin pärjätäkseen itsenäisenä testaajana. Vaikka ei olisikaan innostunut tilannetekijäohjatusta testauksesta, testaus on väistämättä monella tavalla kontekstisidonnaista, ja vaihtoehtoisia konteksteja on valtava määrä.

Testauksen tulevaisuuden kannalta onkin tärkeää, miten me testaajat itse osaamme tehdä näkyväksi toimintakenttämme kompleksisuutta. Käytyjen keskustelujen perustella testiautomaation valtava tarve liittyy osin ohjelmistotuotannon valtavaan määrään, jossa vain pieneen osaan maailman projekteja riittää niitä teräsmies-kehittäjiä, joiden koodi on niin kaunista ja virheetöntä ettei sen jatkokehittäminen vaadi kummoistakaan regressiotestiarsenaalia. Keskinkertaisten, kelvollisten ja kehnompien kehittäjien jälkien paikkailu taas vaatii melkoisia batman-testaajia, mutta heitäkään ei joka firmaan riitä. 

Kysymys kuuluukin, onko automaation auvoisuutta rummuttavassa maailmassamme ymmärretty riittävän hyvin testaajan arvo, se kuinka paljon yksilön oppimiseen on oltava valmis sijoittamaan jotta hänestä voisi kehittyä batman-testaaja, ja ollaanko hänelle tuon tason saavutettuaan valmiita maksamaan vastaavia summia kuin teräsmies-kehittäjälle? Kuinka me testaajat voisimme paremmin näyttää tekemisemme arvon ja ne mahdollisuudet, joiden tavoittamiseen tarvitsemme lisää pelimerkkejä? Ja kuinka mahdollistamme jatkossakin keltanokka-testaajien pääsyn alalle, että heidän tuleva arvonsa nähtäisiin riittävän suureksi, jotta heidänkin työssäoppimiseensa ja kouluttamiseensa kannattaa panostaa?

sunnuntai 15. toukokuuta 2016

Kieliversiot

Muutama vuosi sitten kokeilin lyhyen pätkän kotirouvan elämää Saksassa. Mieheni oli väliaikaisesti töissä Freiburgissa, ja me lasten kanssa vietimme kesän siellä hänen kanssaan. Oma saksankielentaitoni ei ole kovin kaksinen, mutta "lebensmitteldeutch" riitti suhteellisen hyvin arkiseen kaupassa ja torilla asioimiseen, ja kielitaidon loppuessa kesken asiat saatiin käytännössä aina hoidettua niin että minä puhuin englantia ja toinen osapuoli saksaa.

Suurimmat kielellisen turhautumisen hetkeni koinkin erilaisten nettipalveluiden käyttäjänä. Koska olimme Saksassa, jokainen kansainvälinen palvelu jonka sivustolle menin, tarjosi minulle oletuksena saksankielistä sivustoa. Ja koska Saksassa pärjää vain osaamalla saksaa, näistä palveluista ei koskaan löytynyt mahdollisuutta vaihtaa sivuston kieltä englanniksi. Siispä esimerkiksi asensin tietokoneeseeni Spotifyn ymmärtämättä sopimusehtoja. Kun tilasin lapsilleni crocseja, sain mm. selville että ko. merkin saksalaisen verkkokaupan valikoima poikkesi hieman suomalaisen verkkokaupan valikoimasta, mutta kenkien toimitusosoitetta ei ollut kuitenkaan rajoitettu maantieteellisesti.

Kun on itse ollut testaamassa verkkosivustoja, joissa on "tietenkin" vähintään kolme kieliversiota Suomessa asuvien ihmisten tarpeisiin, tuntuu hassulta, että yritykset, joilla täytyy olla olemassa jokaiselle myyntiartikkelilleen lukuisia kieliversioita, eivät tule ajatelleeksi että joku heidän sivustonsa käyttäjä saattaisi haluta asioida muulla kuin saksan kielellä ottaessaan palveluun yhteyttä Saksasta. (Toki tuntuu myös hassulta, että jos nettikaupat on rajattu kieliversioihin sillä ajatuksella, että asiakas saisi aina tuotteensa lähimmästä varastosta, tuo rajaus koskee nimenomaan asiointikieltä eikä toimitusosoitetta.) Toisaalta, kieliversioita testanneena ymmärrän myös, että niiden lisääminen on vähän sama asia kuin tuettujen selainten lisääminen - pienet muutokset lisäävät työmäärää yllättävän paljon.

Tässä listattuna muutamia asioita, joita kannattaa miettiä kieliversioita testattaessa:
  • Löytääkö käyttäjä kielenvaihtotoiminnon?
  • Mihin käyttäjä ohjautuu vaihtaessaan kieltä? Jos sivun pitäisi pysyä samana millä käyttäjä on kieltä vaihtaessaan (mikä on omasta mielestäni käyttäjäystävällisin vaihtoehto, sisäsivuille kuitenkin yleensä päädytään siksi että ollaan kiinnostuneita juuri sen sivun sisällöstä), mitä tapahtuu jos ko. sivulta puuttuu tuo toinen kieliversio?
  • Jos saman sivun eri kieliversiot ovat julkaisujärjestelmän näkökulmasta sama sivu, vaikuttaako pääkieliversion puuttuminen siihen miten ko. sivun muut kieliversiot toimivat? 
  • Onko yhteisiä elementtejä, jotka näkyvät samanlaisina kaikissa kieliversioissa? Jopa yhteiset kuvat voivat aiheuttaa ongelmia. Näkyykö käyttöliittymässä väärän kielisiä tekstejä?
  • Tehdäänkö käyttäjästä kielen perusteella oletuksia (esim. osoitteen maa-tieto, kansalaisuus), ovatko ne ko. palvelun kannalta mielekkäitä oletuksia, ja ovatko ne käyttäjän vaihdettavissa jos oletukset ovat virheellisiä?
  • Löytyykö palvelusta kokonaisuuksia, joihin mennessä kielivalinta nollautuu?
  • Näkyvätkö kielikohtaiset erikoismerkit (å, á jne) oikein?
  • Miten sanojen pituudet vaikuttavat käyttöliittymän elementteihin? Esim. mahtuvatko nappien tekstit nappeihin, tai hajoaako leiska kun joku elementti on isompi tai pienempi kuin mitä graafikko oli ajatellut? Onko muita ulkoasullisia eroja kieliversioiden välillä, esim. etusivun elementtien käytössä tai navigaatiolinkkien määrässä, ja miten hyvin ne toimivat?
  • Yllättävätkin asiat voivat olla hajalla kieliversiokohtaisesti. Kieliversioihin päteekin pitkälti sama asia kuin selaimiin, testaajan ei kannata keskittyä ensisijaisesti samaan kuin mitä kehittäjä käyttää.
Tuleeko mieleen muuta olennaista?

sunnuntai 17. huhtikuuta 2016

Testattavuudesta ja omien rajojen tunnustamisesta

Testaajan rooli nähdään helposti puutteiden etsimisenä muiden tekemisistä. Kun koodi on kehittäjän mielestä riittävän hyvä ollakseen valmis, testaajan tehtävä on tavallaan löytää kaikki merkitykselliset kysymykset, joita ei ole vielä esitetty tai joihin ei ainakaan ole vielä löydetty vastauksia. Tyypillisesti ajatellaan kysymyksen olevan siitä, toimiiko ominaisuus ja vastaako se speksejä. Näkökulmia on kuitenkin monia muitakin. Löytääkö käyttäjä toiminnallisuuden? Ymmärtääkö hän, mitä se tekee? Eteneekö prosessi riittävän sujuvasti? Selviääkö järjestelmä riittävän hyvin raskaista operaatioista? Mitä muutokset tarkoittavat testattavuuden, ylläpidettävyyden tai tietoturvallisuuden näkökulmasta?

Yhden ihmisen voi olla vaikea löytää kaikkia kulmia, joista kysymyksiä voi esittää. Oma osaaminenkaan ei välttämättä riitä kaikkeen. Siksi on tärkeää tunnistaa omat rajansa ja puutteensa ja miettiä, miten niiden yli on mahdollista päästä. Joskus vastaus voi olla tiedon etsiminen, jotta oma näkemys ja osaaminen laajenisi. Joskus vastaus voi olla avun pyytäminen.

Minä kokeilin pari viikkoa sitten esittää tiimille testaukseen liittyvän ongelman, jota en itse pystynyt ratkaisemaan. Saimme aikaan mainion keskustelun testattavuudesta, sekä tavoista mahdollistaa nykyistä paremmin testiautomaation rakentaminen. Suunnittelupöydällä on nyt jo aikaisemminkin pohdittu mutta keskustelumme jälkeen prioriteetiltään noussut muutos, joka toivottavasti parantaisi yhden keskeisen toiminnon käytettävyyttä, sekä vähentäisi testausta vaativien prosessikulkujen määrää. Automaation rakentamiseen liittyviä ongelmia on ratkottu yhdessä, työ on vielä kesken, mutta se kaikkein perustavanlaatuisin este on jo saatu purettua.

On mahtavaa saada työskennellä ympäristössä, jossa ongelmista ollaan valmiita tekemään yhteisiä, ja jossa niihin myös halutaan löytää ratkaisut.

Minä näen testaajan työn keskeisenä tarkoituksena auttaa kehittäjiä työssään. Tärkeää on myös muistaa, miten monin tavoin kehittäjät voivat auttaa testaajaa tekemään työnsä paremmin.


maanantai 4. huhtikuuta 2016

Kun aika ei vain riitä - hajanaisia ajatuksia

Talvi on kulunut töissä vauhdikkaasti. Tuotteemme on ollut poikkeuksellisessa myllerryksessä, jonka myötä sen toimintalogiikka on jatkossa aikaisempaa helpommin yleistettävissä uusiin tarpeisiin. Käyttöliittymän kautta katsoen muutokset ovat suuria, mutta konepellin alla on tapahtunut paljon enemmän. Nyt muutos on vihdoin saatu kokonaisuudessaan tuotantoon, ja tuotekehityksessä voidaan taas palata normaalimmille urille. Kiire ei toki mihinkään ole häviämässä, uutta pitää tehdä koko ajan, ja rosoja viilailla siistimmiksi. Pitää ottaa askel taakse, katsoa kokonaisuutta kriittisesti ja löytää paikat joissa on kenties oiottu liikaa.

Arki vie helposti mennessään, tekeminen taantuu suorittamiseksi. Taustalla kulkee kuitenkin koko ajan ajatus siitä, miten asioita voisi tehdä paremmin, mitä uutta pitäisi oppia. Kiireessä ne ajatukset eivät vain aina pääse kiteytymään niin nopeasti kuin toivoisi. Eikä työ ole ainut, mikä vie. Lapset tarvitsevat aikaa, harrastukset ja vapaaehtoistyö vievät aikaa. Nukkuakin täytyy, nykyään aika paljonkin. Kaikkeen ei vain ehdi.

Omaa ammatillista kehittymistäkin voi miettiä monella tavalla. Mihin suuntiin haluan syventää, mihin laajentaa. Jälkimmäisessä mahdollisuudet tuntuvat nyt lähes rajattomilta, mutta kaikkiin tilaisuuksiin ei voi tarttua kerralla, tai muuten fokus hajoaa ja se perustyö jää retuperälle.

Myös jakamisen tavat mietityttävät. Pitäisikö kirjoittaa muutakin kuin blogia? Riittääkö aika osallistua johonkin, missä on ulkoa annetut aikataulut? Saisinko aikaan enemmän, jos minulla olisi dl? Mistä minulla on tarpeeksi sanottavaa, ja osaanko muotoilla sen kiinnostavasti?

Nämä pohdinnat saivat yllättävää vauhtia, kun minut kutsuttiin puhujaksi Ohjelmistotestaus 2016 -tapahtumaan. Tuntuu aika huikealta saada tällainen tilaisuus, kun listalta myös puuttuu joitakin nimiä joiden esityksiä mielelläni kuulisin. Odotan mielenkiinnolla, mitä tästä tulee.

sunnuntai 10. tammikuuta 2016

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.