On yleistä, että liiketoiminnan paineet kiirehtivät ohjelmistotuotteen saattamista tuotantoon ja edelleen sen käyttäjille.
Tuotekehitystiimi keskittää silloin kaiken tarmonsa kehitystikettien ratkaisemiseen, jotta sprintille lapioidut asiat tulisivat valmiiksi ja jotenkuten testatuiksi deadlineen mennessä.
Strateginen työskentely tapahtuu liiketoiminnan päätösten ehdoilla, jonka määrittelemät, esimerkiksi julkistuksen ja markkinoinnin, ajankohdat tai uusien ominaisuuksien lanseeraamiset ovat merkityt roadmapille, eikä niistä odoteta lipsuttavan.
Tekninen velka ei kuitenkaan kuulu tällaisella agendalla murehdittaviin asioihin, ja siksi se jää usein vähälle huomiolle pahimman kiireen laannuttuakin.
Tyypillisiä tilanteita, jotka vaikuttavat teknisen velan kertymiseen:
- Siiloutuminen, erityisesti jos tuotekehityksen ja liiketoiminnan tarpeita ei saada mahdutettua saman roadmapin agendalle.
- Ylimalkainen vaatimusmäärittely ja heikko tekninen suunnittelu jättävät jälkeensä purkkakoodiratkaisuja.
- Heikko dokumentaation taso, joka vaikeuttaa erityisesti uusia kehittäjiä ymmärtämään järjestelmän toimintaa.
- Koodin refaktorointia ei suoriteta säännöllisesti, jolloin seurauksena on koodipohjan vähittäinen rappeutuminen ja sen ylläpidon hankaluudet.
- Ei yhteisesti sovittua laadunvarmistusstrategiaa
- Yksikkö/integraatiotestien määrä ja kattavuus epäselviä, eikä harmonisoituja käytäntöjä ole sovittu kehittäjien kesken
- Testiautomaation hyödyntäminen korkeintaan tarvekohtaista – ei systemaattisesti kehitettyjä, ajettuja ja ylläpidettyjä testejä.
- Testausta tehdään, mutta sen kattavuutta tai tuloksia ei seurata. Testatuiksi merkityt tiketit ovat ainoa mittari.
Ilman yhteisesti sovittua laadunvarmistusstrategiaa ja työkaluja laadun systemaattiseksi hallitsemiseksi, tiimi toimii reaktiivisesti, jolloin laatuongelmiin puututaan vasta kun ne tapahtuvat.
Millaiset ovat huonon laadun vaikutukset liiketoimintaan?
Hymyilevä asiakaspalvelu ei ole ratkaisu!
Suurin yksittäinen asiakastyytyväisyyden pilaaja on ohjelmistotuotteen huono käyttökokemus ja epäluotettavuus. Käyttäjät kestävät sitä tiettyyn rajaan saakka, mikäli palvelu on laatuongelmistaan huolimatta heille tärkeä tai ainoa vaihtoehto vallitsevaan tarpeeseen (esim julkishallinnon ohjelmistot).
Kuitenkin ajan saatossa jatkuvat käyttöongelmat ja toistuvien korjausversioiden toimittaminen vaikuttavat negatiivisesti asiakastyytyväisyyteen ja brändiin, ollen samalla suora syöttö kilpailijoiden lapaan. Käyttäjien mitta täyttyy ennenpitkää, mutta se heijastuu ikävästi myös koko tuotekehityshenkilöstöön.
Vaikka valveutuneella asiakaspalvelulla tarjottaisiin käyttäjille paras mahdollinen tuki, ei sillä, eikä jatkuvilla hätäpaikkauksilla ratkaista toistuvia laatuongelmia.
Millaisista tappioista keskustelemme, mikäli 50% tuotteesi potentiaalisista asiakkaista valitsisivatkin kilpailevan ratkaisun seuraavan kahden vuoden kuluessa?
Kehittäjät vihaavat työnsä keskeytymistä!
Entä kun uusi ominaisuus on viety kiireellä tuotantoon ja tuotannosta alkaa saapua virheraportteja?
Se on tilanne, jossa kehittäjät ovat pakotetut keskeyttämään sen hetkisen tekemisensä, ja keskittymään ongelman ratkaisemiseen. He vihaavat sitä joka kerta.
Pahoissa tilanteissa, tiedotusosastoa joudutaan pyytämään tiedottamaan teknisestä ongelmasta jota korjataan parhaillaan, samalla kun asiakaspalvelu tekee parhaansa reklamoivien asiakkaiden parissa. Heistäkään kukaan ei nauti siitä.
Kiireellisten tuotantokorjausten toimittaminen viivästyttää meneillään olevaa tuotekehitystä, vaikuttaa asiakastyytyväisyyteen ja turhauttaa koko henkilöstöä kerta kerralta enemmän. Mikäli se on jatkuva normaalitila, työntekijöiden motivaatio laskee, eikä ole poikkeuksellista että he alkavat ajan myötä tähyilemään mielekkäämpiä haasteita.
Millainen olisi tuotekehityksesi tila, mikäli tuotekehitystiimisi jäsenet vaihtuisivat säännöllisesti?
Vapiseeko sormi julkaisunapilla?
Tuotannon laatuongelmat herättävät närää sekä asiakaskentällä sekä organisaatiossa, mutta toistuvana ilmiönä ne voivat aiheuttaa suoranaista julkaisukammoa.
Kukaan ei luonnollisesti halua olla kutsuttuna ”kulmahuoneeseen” selvittämään, mistä jo pitkään toistuneet tuotannon laatuongelmat johtuvat ja millä tavoin laadunvarmistus on toteutettu – erityisesti jos sitä ei ole toteutettu asianmukaisesti.
Ajantasainen tieto laadusta on kaikkien osapuolten kannalta aina paras lääke:
- Yksikkö- ja integraatiotestaus tarjoaa välittömän palautteen kehittäjälle
- Muutoksen yhteydessä ajettu testiautomaatio tiedottaa parhaimmillaan koko tuotteen tilasta.
- Ihmisvoimin suoritettu tutkiva testaus tarjoaa monipuolista tietoa käyttökokemuksen ja eri käyttötapausten näkökulmasta.
- Testauksen tuottamat havainnot ovat reaaliaikaista kommunikointia laadusta.
- Säännöllinen keskustelu laadusta pitää asian mukana tiimin päiväjärjestyksessä.
Julkaisupäätöksen tekeminen tuntuu joka kerta enemmän turvallisemmalta, kun laatukäsitys on ensin tiimistä ammennetulla tiedolla varmistettu!
Ketkä sinun tiimistäsi olisivat vastaamassa ja kenelle, mikäli iltapäivälehdet kirjoittaisivat tuotteenne laatuongelmasta?
Testaus ei ole erillinen vaihe kehityksessä – se on tapa kehittää!
Aloita kehittämään jo nyt! Tässä vinkkejä toteutukseen:
- Puhukaa laadusta jokaisen sprintin alussa – älkää vasta retrospektiivissä. ”Mitä testaukselta odotetaan tässä sprintissä?”, on helppo puheenaihe.
- Ajantasainen dokumentaatio, johon on myönnetty pääsy kaikille tiimissä. Dokumentoimattomia adhoc-muutoksia vältettävä viimeiseen saakka.
- Koko tiimillä on laatuvastuu, koska tiiminä myös (toivottavasti) seisotte tuotteenne takana.
- Code review -käytännöt, sisältämään myös yksikkötestikattavuuden tarkastelun.
- Demo-tilaisuudet, voivat sisältää myös lyhyesti testaushenkilöstön puheenvuoron ja/tai esityksen.
- Jatkuva integraatio jossa aktiivisesti ylläpidettyä testiautomaatiota ajetaan muutosten yhteydessä.
- Tutkivan testauksen kulttuuri, jossa ohjelmistoa testataan järjestelmällisesti erilaisissa käyttötilanteissa, monipuolisella datalla ja mielikuvitusta hyödyntäen!
- Laatutyön palkitseminen. Tunnistakaa teknistä velkaa aktiivisesti purkavat tekijät tiimistänne ja antakaa positiivista palautetta! Se yhdistää koko tiimiä!
Kaiken ei tarvitse tapahtua saman kvartaalin aikana, mutta laadun parantamiseen puuttumalla, koko tuotekehityksenne vointi paranee!
Lisää aiheesta?
Lue lisää testauspalveluistamme >>
Tai ota yhteyttä: Janne Lepistö, CEO / +358 50 487 3265 / janne.lepisto@qubilea.fi
Tutustu myös artikkeleihimme:
