Kommunikaatiohukka kuriin – muista nämä viisi asiaa!

Tuotekehityksen synkässä metsässä ulvoo kommunikaatiohukka. Näin kirjoitti ystäväni Facebook-feediinsä seuratessaan väitöstilaisuuttani Oulun yliopistossa huhtikuussa 2015. Pakko tunnustaa, että kyseinen päivitys hymyilytti minua hyvinkin äänekkäästi, mutta jokaisen hyvän sutkauksen takana piilee useimmiten aimo annos totuutta! Tuotekehityksen maailmassa kieltämättä vilisee yksisarvisia, hopealuoteja ja muuta tarunhohtoista, mutta tässä tapauksessa kyse ei ole mistään karvaisesta ja pahansuovasta hirviöstä vaan tuiki tavallisesta ilmiöstä, joka on läsnä enemmän tai vähemmän jokaisessa tuotekehitysorganisaatiossa. Kommunikaatiohukan käsite on siis lähtöisin omasta väitöstyöstäni, ja ennen kuin tutustumme siihen tarkemmin, virkistäkäämme muistiamme sen suhteen, mitä hukalla oikeastaan tarkoitetaankaan!

Hukka – tuotekehityksen arvonnakertaja

Hukka on Lean-maailmasta tuttu käsite, joka tarkoittaa jotakin mikä kuluttaa resursseja, mutta ei tuota arvoa kenellekään.

Hukka eli waste on Lean-maailmasta tuttu käsite, joka yleisimmillään tarkoittaa jotakin mikä kuluttaa resursseja (aikaa, rahaa, vaivaa, jne.), mutta ei tuota mitään arvoa kenellekään, usein erityisesti asiakkaalle. Käytännössä kyse on siis jostakin tarpeettomasta. Hukan käsite on syntynyt alun perin valmistavassa teollisuudessa, tarkemmin Toyotalla, ja se on siirtynyt myöhemmin kattamaan arvoa tuottamattomia asioita myös digitaalisten tuotteiden ja palveluiden kehittämisen maailmassa. Erityisesti Mary ja Tom Poppendieck ovat ansioituneesti siirtäneet tätä käsitettä ohjelmistotuotannon maailmaan, ja he ovat tunnistaneet seuraavat tähän ympäristöön erityisesti täsmennetyt hukat. Voit vaikkapa täältä lukea niistä lisää mutta tässä alla on myös esimerkkejä siitä, miten ne voivat ilmentyä organisaatiossa:

• Osittain tehty työ (Partially done work): jotakin, mitä ei tehdä loppuun asti valmiiksi; esimerkiksi osa tarvittavista tehtävistä jää tekemättä.
• Tarpeettomat ominaisuudet (Extra features): esimerkiksi tuotteessa on ominaisuuksia, joita ei tarvita tai joita ei käytetä.
• Uudelleenoppiminen (Relearning): samaa ongelmaa ratkaistaan kerta toisensa jälkeen.
• Työn siirto (Handoffs): työ tehdään valmiiksi tiettyyn pisteeseen asti, jonka jälkeen se siirretään seuraavalle taholle jatkotyöstettäväksi. Esimerkiksi koodarit koodaavat ratkaisun ja siirtävät sen sitten testaajille testattavaksi.
• Viiveet (Delays): joudumme odottamaan jotakin tai meiltä odotetaan jotakin.
• Tehtävien vaihto (Task switching): se kuuluisa multi-tasking! Mitä useampia työtehtäviä teet samaan aikaan, sitä hitaammin kokonaisuus valmistuu. Kontekstinvaihto vie aikaa, ja virheiden ja väärinkäsitysten todennäköisyys lisääntyy.
• Virheet (Defects): erilaiset poikkeamat laadussa, ei pelkästään tuotteeseen vaan myös esimerkiksi työprosessiin liittyen.

Näiden seitsemän hukan voidaan katsoa olevan ne digitaalisen tuotekehityksen klassiset hukat, mutta toki niitä on tunnistettu muitakin. Esimerkiksi Mandic kollegoineen on tunnistanut lisää hukkia, joihin pääsee tutustumaan lukemalla heidän artikkelinsa What Is Flowing in Lean Software Development? Google Scholar hakulinkki tähän artikkeliin löytyy tästä.

Katsotaanpas seuraavaksi, millainen ilkiö se kommunikaatiohukka on ja miten se ilmenee organisaatioissa. Sen jälkeen voimme pohtia miten hukan kanssa voidaan toimia.

Mikä syö arvoa kommunikaatiossa?

Kommunikaatio-hukka on asia, joka kuluttaa kommunikaation näkökulmasta resursseja.

Kommunikaatiohukka on asia, joka kuluttaa kommunikaation näkökulmasta resursseja, mutta ei tuota sille mitään arvoa. Kommunikaatio tulee tässä yhteydessä käsittää laajemmin kuin vain ihmisten välisenä kommunikaationa; esimerkiksi dokumentit ovat sekä kommunikaation väline että kommunikaatiota itsessään.

Nämä viisi kommunikaatiohukkaa ja näiden kuvaukset ovat seuraavat:

1. Aktiivisen osallistumisen puute (Lack of involvement): keskeisten roolien läsnäolon puuttuminen tilanteissa, joissa heidän osallistumisensa on elintärkeää tuotekehityksen ohjaamisen ja palautteen antamisen kannalta. Esimerkiksi Scrum-prosessin eri seremoniat tai laajemmin vaikkapa SAFe:n PI-suunnittelu ovat tilanteita, joissa tämä hukka ja sen luomat haasteet realisoituvat.
2. Jaetun ymmärryksen puute (Lack of shared understanding): kommunikoivat osapuolet eivät jaa samanlaista ymmärrystä tai kokemusta käsiteltävästä asiasta. Tämä lisää kommunikaatiotarvetta ja väärinkäsitysten mahdollisuutta. Tällainen tilanne syntyy usein silloin, kun toimitaan ulkoisten tiimien kanssa, siiloutuneessa organisaatiossa ja myös silloin kun liiketoiminnan ja tuotekehityksen henkilöt kommunikoivat keskenään.
3. Vanhentunut tieto (Outdated information): aiheeseen liittyvä kommunikaatio ei pohjaudu viimeisimpään tietoon asiasta. Tätä tapahtuu organisaatioissa monella tasolla. Varmasti jokainen on ollut tilanteessa, jossa ongelmaa ratkaistaan sähköpostikeskustelussa, joka sisältää kymmeniä viestejä. Jossakin vaiheessa keskustelua ongelman ratkaisu aloitetaan ja myöhemmin viestiketjuun on tullut useita viestejä, joissa tilanteeseen on löydetty uusia relevantteja näkökulmia tai jopa parempi ratkaisuvaihtoehto. Myös esimerkiksi tuotejohto saattaa tehdä tuotteisiin liittyviä päätöksiä vanhentuneeseen tietoon perustuen.
4. Rajoitettu pääsy tietoon (Restricted access to information): tarvittava tieto ei ole sitä tarvitsevien saatavilla. Tämä ei tarkoita sitä, etteikö tieto olisi olemassa vaan sitä, että sitä tarvitsevilla ei ole esimerkiksi oikeuksia sen hyödyntämiseksi. Esimerkiksi yrityksen eri tuote- tai projektiorganisaatioilla tai yksiköillä ei ole pääsyä toistensa tietoihin. Pääsy tietoon voi olla rajoitettua myös saman yksikön sisällä.
5. Hajallaan oleva tieto (Scattered information): tarvittava tieto on hajallaan useissa paikoissa, mikä tekee sen etsimisestä vaikeaa ja aikaa kuluttavaa. Tietoa löytyy wikeistä, intrasta, dokumentinhallintajärjestelmistä, sähköposteista, muistivihkoista, post-it lapuilta, jne. Tämä on todella yleinen, aikaa ja hermoja syövä ilmiö.

Uskallan väittää, että lähes jokainen organisaatio kamppailee näiden ongelmien kanssa, ja pystyt varmasti tunnistamaan muitakin esimerkkejä näistä arvonsyöjistä! ”Tunne vihollisesi” kirjoitti muuan Sun Tzu jo jokin aika sitten, ja kun onnistumme tässä se antaa meille yliotteen vainoajistamme. Kurkataanpa sitten, miten hukka saadaan häkkiin.

Arvovarkaat kiikkiin!

Aluksi on hyvä muistaa, että jokaisessa prosessissa tulee aina olemaan hukkaa ja että aina emme voi jostain syystä poistaa sitä. Tällöin puhutaan Tyypin 1 hukasta, eli sellaisesta joka vain on osa prosessia. Usein tällaiset hukat ovat sellaisia, että ne esiintyvät jossain sellaisessa osassa arvoketjua, mihin me emme voi vaikuttaa. Esimerkiksi omat prosessimme voivat olla hyvinkin virtaviivaisia, ja isoimmat hukat esiintyvät vaikkapa kumppaneidemme prosesseissa ja arvovirroissa. Näissä tapauksissa hukan poistaminen on usein joko mahdotonta tai erittäin työlästä, ja vaatii kunnollista vaihtoehtokustannusten analyysiä. Joskus myös lainsäädännölliset näkökulmat luovat hukkaa, jota emme voi poistaa. Tyypin 2 hukan vaikutuksia taas voimme lieventää tai jopa poistaa ne kokonaan!

Näitä yllämainittuja kommunikaatiohukkia voidaan lieventää vaikkapa seuraavilla toimenpiteillä:

• Aktiivisen osallistumisen puute: tuotekehitys hyötyy usein yksinkertaisista säännöistä. Voimme sopia, että tarvittavien roolien osallistuminen tärkeisiin seremonioihin on pakollista. Tämä puolestaan tarkoittaa sitä, että näissä rooleissa toimivilla henkilöillä tulee olla riittävästi kapasiteettia toimia roolissa asianmukaisesti. Vaikkapa tuoteomistajana työskentelevän tulee saada riittävästi aikaa työskennellä roolissaan mutta myös ymmärtää se, että rooli vaatii tätä.
• Jaetun ymmärryksen puute: tämän taklaaminen vaatii, kenties ironisestikin, paljon vuorovaikutusta ja kommunikaatiota. Kyse on tiedon välityksestä ja sen konvergoinnista, eli yhteisen ymmärryksen hakemista. Joskus tarpeet ovat hyvinkin pieniä, esimerkiksi terminologian ja käsitteiden jakamista, toisaalta myös isoja ja merkittäviä, vaikkapa uudet teknologiat ja rakennettavan tuotteen ominaispiirteet ja sovellusalueen erityispiirteet. Tiedon jakamisen on oltava usein hyvinkin systemaattista ja ennen kaikkea aktiivista. Esimerkiksi killat (Communities of Practice), koulutukset, työpajat, asiakkaiden ja käyttäjien havainnointi, sekä tehtäväkierto toimivat hyvinä mekanismeina osaamisen levittämiselle. Liiketoiminnan ja tuotekehityksen välisen yhteistyön tulisi luonnollisesti olla niin läheistä kuin mahdollista sillä tämä mahdollistaa myös sen, että osapuolet oppivat ymmärtämään toisiaan paremmin.
• Vanhentunut tieto: vanhentunut tieto on myös puutteellista tietoa, ja jälleen voimme laatia yksinkertaisia perussääntöjä. Lean-maailmasta löytyy käsite Last Responsible Moment, eli se ajanhetki jolloin meidän on viimeistään tehtävä päätös asiasta. Riippuen kommunikoitavan asian luonteesta, (esimerkiksi tuotteeseen liittyvät päätökset, virhetilanteet, kriittiset asiat, hankinnat) voidaan niille määritellä tämä viimeinen ajanhetki, jolloin päätös on tehtävä, ja tähän asti ilmiöstä kerätään tietoa niin paljon kuin mahdollista. Kommunikoitavan asian luonne voi asettaa myös vaatimuksia sille, millaisten kommunikaatiokanavien kautta asiaa edistetään.
• Rajoitettu pääsy tietoon: tähän sopii erinomaisesti se periaate, että kaiken tiedon on oltava läpinäkyvää ja kaikkien saatavilla, ellei sen salaamiseksi tai rajoittamiseksi ole olemassa erittäin hyvää syytä. Miettikää siis erittäin tarkasti, onko tiedon rajoittamiselle olemassa erittäin painavaa syytä.
• Hajallaan oleva tieto: tähän haasteeseen voidaan vastata yhteisesti sovituilla toimintatavoilla, joissa määrittelemme yksinkertaisilla säännöillä mihin tieto tallennetaan. Voimme sopia käyttävämme esimerkiksi ainoastaan vaikkapa Confluence-sivustoa sinä yhtenä totuuden lähteenä (single source of truth) mihin tarvittava tieto kerätään. Usein näiden sääntöjen noudattamista tulee aluksi seurata hyvinkin tarkasti. Esimerkiksi retrospektiiveissa voidaan aivan hyvin nostaa esille se, olemmeko noudattaneet yhteisesti sovittuja sääntöjämme. Kannattaa muistaa, että uusien toimintatapojen juurtuminen saattaa kestää hyvinkin pitkän aikaa!

Miten hukka houkutellaan esiin?

Hukka on vain oire, jona pullonkaula ilmenee, ja tämän hukan juurisyy tulee selvittää!

Emme tarvitse tähän syöttejä, vaan meillä on käytössämme tarkoitukseen vallan loistavia työkaluja! Arvoketjukartoitus, eli Value Stream Mapping on vallan loistava visualisointitekniikka, jota voidaan soveltaa mihin tahansa prosessiin. Tämä prosessi yksinkertaisesti piirretään yhdessä tarvittavien osallistujien kanssa ja tämän prosessin aikana tunnistamme sen pullonkaulat ja myös keinot minimoida niitä. Vaikka tekniikka on lähtöjään valmistavasta teollisuudesta, olemme soveltaneet sitä erittäin menestyksekkäästi myös digitaalisissa tuotekehitysympäristöissä. Kannattaa ehdottomasti muistaa, että hukka on vain oire, jona pullonkaula ilmenee, ja tämän hukan juurisyy tulee selvittää. Tähän yksi hyvä ja halpa keino on kysyä viisi kertaa miksi? (5 Why’s). Myös Kanban – taulu on erinomainen reaaliaikainen työkalu prosessin toiminnan hahmottamiseen!

Hukkien ja niiden poistamisen kanssa kannattaa vielä muistaa se, että niiden tunnistamiseen tulee osallistua kaikkien niiden roolien jotka prosessin kanssa työskentelevät. Hukkien ja niiden syiden poistamisen kanssa kannattaa olla hyvin varovainen, sillä yhden mörkö saattaa siis olla jollekin toiselle kullanarvoinen yksisarvinen!