Tuija Riekkinen // June 18 2015

Työtä yhdessä ja erikseen, osa 3

Myytti 3 – Etätiimiä on vaikeaa motivoida

Tarua, sillä tiimin motivointi ei ole kiinni siitä näetkö heitä päivittäin. Voi olla, että on ihmisiä, jotka arvostavat sitä, että esimies käy henkilökohtaisesti tervehtimässä joka aamu, mutta yksin sillä ei motivaatiota ylläpidetä.

Seuraavat ajatukset tietotyöntekijän motivoinnista eivät millään muotoa ole vain etätiimiä koskevia, mutta haluan tuoda ne esille, koska kokemukseni mukaan etätiimin voi pitää motivoituneena samoilla eväillä kuin lähitiiminkin.

Tietotyöntekijää motivoi loppujen lopuksi yksinkertaiset asiat:

Tiedät mitä sinulta odotetaan
Voit vaikuttaa siihen mitä teet
Tehtäväsi ovat sopivan haastavia suhteessa osaamistasoosi
Tavoitteet ovat saavutettavissa ja sinulla on mahdollisuus onnistua
Saat tarvittaessa tukea ja palautetta

Periaatteessa listasta voisi merkitä useamman tehtävän vain neuvomalla, että suunnitelkaa enemmän. Mutta koska kaikki suunnittelevat ja motivaatio-ongelmia silti on, haluan sen sijaan haluan tuoda esille muutaman yleisen epäkohdan suunnitteluprosessista.

On tavattoman epämotivoivaa, jos suunnittelu jätetään liian yleiselle tasolle eikä tehtäviä pilkota järkevän kokoisiksi tehtäviksi. Usein tähän yhdistetään “arvioitko montako prosenttia tästä hommasta on tehty” -tyyppinen nollaraportointi. Liian yleiselle tasolle suunnittelu jää, jos tiimiä ei hyödynnetä suunnittelussa. Suunnitelkaa siis yhdessä.

Sovelluskehityksessä tai esimerkiksi verkkopalvelu-projektissa on myös paljon tehtäviä, joiden edistäminen ei ole teknisen tiimin asia. Jos tavoitetta ei pilkota pienempiin tehtäviin, nämä voivat jäädä näkymättömäksi eivätkä ne edisty eikä oikeasti valmista tule.

Etätiimissä näkyvyys ison tehtävän pienempiin osasiin on olennaisen tärkeää. Konteksti säilyy, mutta pienempiin tehtäviin on helpompi tarttua eli tavoitteet ovat saavutettavissa.

Kun tehtävä on pilkottu, sen edistymistä voi seurata ja sen tekeminen on huomattavasti motivoivampaa, kun tehtävän voi merkitä tehdyksi. Siitäkin huolimatta, että se oli vasta tehtävä 1/10 matkalla isompaa tavoitetta.

Vaikka työkalut eivät pelaa peliä puolestasi, ne auttavat. Esimerkiksi Trello on hyvä ja tarpeeksi yksinkertainen työkalu tehtävien laatimiseen, pilkkomiseen, priorisointiin ja edistymisen seurantaan.

Usein käy niin, ettei tiimiä pyydetä mukaan suunnitteluun ja tehtävien pilkkomiseen, vaan heitä pyydetään valmiiseen (liian ylätasolle jäävään) suunnitelmaan työmääräarvio.

Vaikka äkkiseltään luulisit, se ei suinkaan ole kuuluisaa omaan työhön vaikuttamista, vaan hätäistä arpomista ja toivomista, että vastaus miellytti kysyjää.

Huomattavasti järkevämpää ajankäyttöä on siis osallistaa tiimi suunnitteluun tai pyytää heitä miettimään ratkaisuvaihtoehtoja suunnitelman eri tehtäviin – se on heidän työtänsä ja sitä he haluavat tehdä, eivät toimia työmääräarvio-automaatteina.

Lisäksi voit yllättyä siitä, ettei kaikki viisaus asukaan vain niiden päässä, jotka tehtävän tai tavoitteen alunperin määrittelivät (ja iloisena bonuksen saat tuosta työstä johonkin konkreettiseen perustuvan työmääräarviokin, jos sellaisen välttämättä haluat).

Onnistumisen ilmapiiri tehdään kovalla työllä

Kukaan ei halua mahdottoman tehtävän eteen. Silti tätä tapahtuu sovelluskehitysmaailmassa koko ajan. Paskat speksit, jotka muuttuvat koko ajan. Tee siinä sitten jotain valmista ja koe onnistumista.

Sovelluskehitys on todella raakaa duunia. Onnistuminen vaatii koko ketjulta kovaa työtä.

Kun tuotekonsepti puretaan yksittäisiin toiminnallisuuksiin ja siitä vielä pienempiin toteuttaviin yksiköihin, on yksityiskohtien määrä infernaalinen.

Toisaalta ihmisen kyky käsitellä yksityiskohtia on rajallinen ja selkeä speksi on selkeä ainoastaan speksin tekijän näkökulmasta.

Tämän ymmärtäminen ja ennen kaikkea hyväksyminen on edellytys onnistumisen ilmapiirille ja hyvien käytäntöjen rakentamiselle.

Itse hahmotin roolini sovelluskehitystiimin vetäjänä ja konseptisuunnittelijana kahden kolmio avulla.

Toinen kolmio seisoo kärjellään, kuten se liikennemerkki, joka pyytää väistämään.

Huomasin, että oli järkevää, että minulla oli hanskassa iso kuva eli kolmion leveä pää. Tiesin, että mikä asia liittyi mihinkin ja mitä milläkin toiminnallisuudella tavoiteltiin jne. Tätä tietoa ei kannata tietenkään pantata, se kannattaa dokumentoida, mutta samalla hyväksyä, että todennäköisempää on se, että joku kysyy asiaa sinulta kuin menee lukemaan dokumentin. Minun tehtäväni oli vastata väsymättä kysymyksiin.

Kehittäjälle on olennaista ymmärtää mikä liittyy mihinkin, kun asiaan liittyvää toiminnallisuutta kehitetään, mutta kovalevyä on turha täyttää silloin kaikella muulla.

Sitten tulee se toinen kolmio. Se seisoo kärki ylhäällä. Se taas kuvastaa sitä, että konseptoinnissa ja määrittelyssä yksityiskohtien miettiminen on loppujen lopuksi aika pieni duuni verrattuna yksityiskohtiin, joita seuraavat vaiheet joutuvat miettimään.

Esimerkiksi kun konseptoija piirtää rautalankaan napin, pitää graffaajan muistaa miettiä, että miltä näyttää aktiivinen nappi, entäs ei-aktiivinen ja millainen hover- ja latausefekti tarvitaan. Puhumattakaan mitä kaikkia “corner-caseja” kehittäjä joutuu miettimään, kun toiminto, joka käynnistyy napin painalluksesta, kehitetään.

Kun kolmiot asetetaan päällekkäin, syntyy tasapaino. Kaikilla on taatusti tarpeeksi yksityiskohtia päässään, mutta kaikilla vain ne oman tehtävän suorittamisen kannalta olennaiset.

Palaute – mitä se oikeastaan edes on

En ole itse taustaltani tekninen. Niinpä en voi puuttua liian yksityiskohtaisesti siihen miten kehittäjät ratkaisevat asioita. Hyville kehittäjille tämä on huomattavasti motivoivampaa kuin tilanne, missä mukana tiimissä on kontrollifriikki arkkitehti, joka määrittelee hyvin tarkasti miten asiat toteutetaan. Toisin sanoen, kehittäjät voivat vaikuttaa paljon omaan työhönsä.

Jos kehittäjät (tai yleisemmin asiantuntijat) pallottelevat asioita paljon ja vääntävät asioista pitkään, muista, että tämä on pelkästään positiivinen juttu. Myös koodin katselmointi on kehittäjille tärkeä prosessi eikä siihen kannata mennä nillittämään, että onko tämä oikeasti tarpeellista.

Keskustelut, katselmoinnit ja refactoroinnit vievät aikaa, mutta ajankäyttöäkin kannattaa katsella hiukan laajemmasta perspektiivistä. Mielestäni tuollainen kommunikointi on nimenomaan sitä kuuluisaa palautetta, jota kaikki tietotyöntekijät työstään haluavat. Jos kukaan ei katselmoinnissa vaivautuisi kommentoimaan ja puuttumaan joskus jopa epäolennaisuuksiin, voisi toiselle osapuolelle tulla tunne, että vissiin ketään ei kiinnosta. Se on muuten turhauttava tunne.

Käsite “palaute” ymmärretään liian suppeasti. Useasti se on sitä, että muistiko pomo kiittää tai että miten se rakentava palaute annetaan, vaikka nuo eivät ole ollenkaan niitä jokapäiväisiä pieniä palautteita, mitä ihmiset toivovat saavansa.

Minusta monessa ammatissa kannattaisi ottaa oppia kehittäjien katsemointikäytännöstä. Kissa kiitoksella elää, mutta konsepti paranee vain sparraamalla.

Haastavuuden tasapainon löytäminen

Työtehtävien haastavuus on hankalasti hallittava asia, sillä joskus tehtävälistaan tulee myös simppeleitä hommia. Työn yleiseen haastavuuteen voi vaikuttaa ainakin siten, etteivät puutteellinen suunnittelu tai liian tiukat aikataulut tee tehtävistä mahdottomia.

Kannattaa muistaa, että hyvän kehittäjän (tai asiantuntijan) tavoite on tehdä laadukasta työtä. Jos jatkuvasti vaadit heiltä aikataulupaineiden vuoksi riman alitusta, muuttuu työ pian väärällä tavalla haastavaksi.

Työskentelin yli vuoden konseptisuunnittelijana ja tuotekehityksen vetäjänä sovelluskehitys-projektissa, jossa suurin osa tiimistä työskenteli etänä (Venäjällä ja Serbiassa). Vuoden aikana ymmärsin, että aidon etätyökulttuurin omaksuminen on yritykselle merkittävä kilpailuetu ja omat ennakkoluuloni etätyötä kohtaan karisivat vauhdilla pois kyydistä.

Etätyö määritellään Suomessa lähes kategorisesti “silloin tällöin kotoa tehtäväksi työksi”. Artikkelisarjassa Etätyön myytit haluan omalta osaltani murtaa etätyötä leimaavia myyttejä. Vaikka toimintaympäristönä kirjoitusten esimerkeissä onkin sovelluskehitys, uskon että toimintamalleja voi soveltaa myös muussa tietotyössä.

Ja jos et minua usko, lue kirja Remote – office not required (Jason Fried, David Heinemeier) ja valaistu.

Lue artikkelisarjan aikaisemmat kirjoitukset Myytti 1 – Etätyö on työntekijän etu, ei yrityksen ja Myytti 2 – Etätiimi = Ulkoistus = Kustannussäästö

More from Tuija Riekkinen