Menestyvien yritysten voimat voidaan jakaa kolmeen kategoriaan: liiketoimintaan, teknologiaan ja laatuun. Organisaatiot seuraavat yleensä rahaa, joten niiden huomio kohdistuu luonnostaan liiketoimintaan. Budjetit laaditaan, tavoitteet asetetaan ja mittarit ovat käytössä. Teknologia on yleensä organisaation ytimessä, sillä sitä pidetään ratkaisuna ja menestyksen edellytyksenä.
Jani Lundan
Työskentelen DevOps-muutosjohtajana yli 20 vuoden kokemuksella erilaisissa laatuun liittyvissä projekteissa, aina muutoshankkeista testaukseen. Minua innostaa auttaa yrityksiä parantamaan laatua monin eri tavoin. En tarkastele laatua pelkästään teknisestä näkökulmasta, vaan ennen kaikkea kulttuurisen näkökulman kautta. Mielestäni muutoksen toteuttaminen on aina ensisijaisesti sidoksissa kulttuuriin.
Liiketoiminta, teknologia ja laatu – menestyvien yritysten kolme voimaa
Kolmesta voimasta laatu jää usein kahden muun varjoon, ja sitä pidetään ”välttämättömänä pahana”. Vaikka laatu olisi määritelty paperilla esimerkiksi ISO-sertifikaattien muodossa, se on silti rakennettava ja toteutettava käytännössä. Ei ole tavatonta, että laatu kärsii ensimmäisenä, kun tarvitaan esimerkiksi kustannussäästöjä. Tällöin johdon huomio ja fokus kohdistuvat usein pääasiassa liiketoimintaan ja teknologiaan laadun kustannuksella.
Jos laatu joskus nousee johdon huomion kohteeksi, tilanne on yleensä jo niin huono, että käsillä on ”laatukriisi”. Kyse voi olla esimerkiksi skandaalista, joka laskee osakekurssia, tilaajien siirtymisestä kilpailijoille tai kassavirtaan vaikuttavista kehitysongelmista.
Laatu ei ole sama asia kuin laadunvarmistus tai testaus
Tarpeen tullen minua pyydetään usein auttamaan esiin nousevien laatuongelmien ratkaisemisessa. Asiakkaillemme tämä tarkoittaa testausprosessin parantamista tai testausta tukevien toimintojen rakentamista. Molemmat ovat erittäin tärkeitä osia laatua, mutta usein törmään tilanteeseen, jossa ongelmat eivät ratkea laadunvarmistusta (QA) tai testausta parantamalla. Miksi näin on?
Suurin este on se, ettei laatua ymmärretä ohjelmistoyrityksissä. Se nähdään usein asiana, joka saavutetaan kehitysprosessin sivussa, tai monissa tapauksissa laadun ajatellaan olevan sama asia kuin laadunvarmistus tai testaus.
Jotta laatua voidaan aidosti parantaa, organisaation on ymmärrettävä, että laatu, laadunvarmistus ja testaus liittyvät toisiinsa, mutta eivät ole sama asia. Jokaiseen niistä on myös panostettava sen sijaan, että niiden odotetaan tapahtuvan itsestään.
Usein virheellinen ajattelutapa on, että laatu on QA-osaston vastuulla eikä kenenkään muun organisaatiossa tarvitse välittää siitä tai tukea sen rakentamista kehityksessä.
Toinen merkki tästä on se, että suuren epäonnistumisen kohdatessa kysytään, kuka vastaa testauksesta, sen sijaan että ongelmia etsittäisiin muualtakin kehitysprosessista.
Ravintolaesimerkki
Selventääkseni laatua aloitan aina toteamalla, että se on abstrakti käsite, jota ei voi määritellä vain yhdeksi asiaksi. Laatu on jotain tärkeää jollekin tärkeälle taholle. Käytän mielelläni ravintola-alan esimerkkiä näkökulman havainnollistamiseksi.
Tässä esimerkissä on kaksi ravintolaa, jotka valmistavat ja myyvät ruokaa asiakkaille. Ensi silmäyksellä ne eivät eroa toisistaan kovinkaan paljon. Kun kuitenkin tarkastelemme niiden liiketoimintamalleja, voimme nähdä myös ravintoloiden erilaiset laatuvaatimukset.
Oletetaan, että toisella niistä on kolme Michelin-tähteä ja toinen on erikoistunut pikaruokaan. Michelin-ravintolan tavoitteena on hienostunut elämys, kun taas toinen keskittyy hintaan, asioinnin helppouteen ja palvelun nopeuteen.
Kuvittele olevasi asiakas kyseisessä Michelin-ravintolassa ja saavasi annoksesi kahdessa minuutissa. Miltä se tuntuisi? Tuntuisiko sinusta, että saat rahoillesi vastinetta? Tuntuisiko se laadukkaalta? Todennäköisesti ei. Puolen tunnin odotus olisi sinulle luultavasti täysin hyväksyttävä. Kuvittele nyt odottavasi kuuden euron hampurilaistasi pikaruokaravintolan drive-thrussa puoli tuntia. Vastaisiko palvelu odotuksiasi? Tuntuisiko se laadukkaalta?
Kun pohdimme edellä olevia esimerkkejä ja vertaamme niitä ajatukseen, että laatu on sama asia kuin laadunvarmistus ja testaus, näemme ajattelun absurdiuden. Ravintolaesimerkissä vastaava ajattelutapa tarkoittaisi, että laatu on sitä, että ravintolan ruoka tarjoillaan sopivaan aikaan. Tällainen ajattelu jättää kuitenkin paljon huomiotta. Todellisuudessa testaus on vain yksi osa laatua.
Laatu on paljon muutakin kuin testausta
Laatua pohtiessamme meidän pitäisi laajentaa näkökulmaamme, sillä se todella kattaa kaiken yrityksessä.
Kun teemme liiketoimintaa ja teknologiaa koskevia suunnitelmia ja päätöksiä, meidän ei pitäisi unohtaa laatua, vaan rakentaa sitä samalla tavalla. Meidän pitäisi pohtia, mitä laatu merkitsee yrityksellemme ja mitä haluamme sillä saavuttaa.
Laatu koskettaa kaikkea, ei vain tuotetta. Esimerkiksi:
Miten johdat yritystä?
Mitä ja miten viestit?
Mitä ostat ulkopuolelta ja mitä rakennat itse?
Miten kehität tuotettasi?
Miten julkaiset tuotteesi?
Miten toimitat tuotteesi?
Miten loppuasiakkaat käyttävät tuotettasi?
Miten tuki hoidetaan?
Laatu on niin monitahoinen käsite, että sen hallitseminen on haastavaa, mutta juuri se tekee siitä myös niin kaunista.
Laatu ei ole koskaan samanlaista kahdelle yritykselle eikä myöskään kahdelle ihmiselle. Yrityksen näkökulmasta se voi kuitenkin nostaa liiketoimintasi uusiin korkeuksiin tai upottaa sen unohduksiin. Laadukkaan tuotteen rakentaminen ja siitä viestiminen asiakkaille voivat tuoda pitkäkestoisia hyötyjä.
Mistä aloittaa?
Neuvoni on tarkastella laadun parantamisen prosessia koko organisaatiossa. Mitä laatu tarkoittaa kokonaisuudessa? Mitä meillä on jo käytössä? Mihin haluamme päästä? Miten voimme saavuttaa määritellyt tavoitteet? Jaa ne sitten vastuualueiksi ja rooleiksi, jotka edistävät laatua yrityksessä.
Jos keskityt vain laadunvarmistukseen tai testaukseen, et pääse kovin pitkälle. Laadun parantaminen edellyttää, että ymmärrämme käsitteen ja siihen liittyvän sitoutumisen.
Sanotaan, että DevOps on 70 % kulttuuria ja 30 % teknologiaa. Transformaatio ei voi onnistua, jos organisaation kulttuuri ei muutu, vaikka käyttöön otettaisiin uusia työkaluja tai toimintatapoja. Lue lisää podcast-jaksostamme, joka käsittelee kulttuurityöpajoja.
- Software development
- DevOps
- Product management
Subscribe to our newsletter
Related blogs