Avainsana: ohjelmistokehitys
“Meidän ihmiset ruukaa tehdä parhaansa” – asiakasuskollisuus ei synny vippaskonsteilla
Hiotulla on vankka kokemus uskollisista asiakkaista. “Firman ensimmäinen asiakas on edelleen asiakkaamme – nyt jo kolmannen yrityksen kautta. Siitä ensimmäisestä tuli sittemmin osa Rautea, joka on nykyään meidänkin emoyhtiömme”, kertoo Hiotun toimitusjohtaja Satu Lapinlampi. “Kaikki asiakkaat eivät toki ole koko ajan tilaamassa, vaan palaavat asiaan aina kun tarvetta ilmenee.”
Uskotaan. Mutta miten tähän oikein päästään? Mitä pitää tehdä oikein?
“Kaikki lähtee siitä, että meillä tehdään niin hyvää työtä kuin mahdollista”, sanoo Lapinlampi. “Koodarit ovat asiakasrajapinnassa ja pystyvät hyvin kuuntelemaan asiakasta. Lisäksi meillä asiakasta ei sidota eikä rajoiteta: rakennettuihin ratkaisuihin annetaan laajat käyttöoikeudet, ja asiakas voi halutessaan jatkaa toisen toimijan kanssa. Me luotamme omaan tekemiseemme: asiakkaan pitämiseen ei tarvita vippaskonsteja.”
Asiakaspysyvyyttä ei ole Hiotulla varsinaisesti mitattu, mutta asiakkuuksia seurataan säännöllisesti. Jos asiakkuus ei jatku, sille on perustellut syyt: asiakkaan liiketoiminta on muuttunut tai päättynyt. Harvinaisissa tapauksissa syynä ovat olleet pitkittyneet muutostoiveet, joista ei ole projektin alussa ollut puhetta. Projektinaikaisia yllätyksiä pyritään taklaamaan etukäteen mahdollisimman hyvällä ennakkosuunnittelulla ja työmäärän arvioinnilla – tässä kantapääkokemus auttaa.
“Esimerkiksi web-projekteissa tyypillisesti Eirolan Mikko ensin juttelee asiakkaan kanssa, kyselee ja kirjoittaa tarvittavat kuvaukset. Sen jälkeen tehdään arvio: lasketaan ensin optimistinen Strömsö-skenaario, sitten mahdollisimman realistinen skenaario ja kolmanneksi pessimistinen skenaario. Näiden yhdistelmästä syntyy tietyllä kaavalla yleensä erittäin hyvin kutinsa pitävä lopullinen työmääräarvio.” Tarjoukseen arvio päätyy vaiheisiin palasteltuna: asiakas näkee, mistä hinta koostuu.
Vilpitön pyrkimys läpinäkyvyyteen
Konenäköpuolella ennakkoarviointi on vaikeampaa. Tämä johtuu yksinkertaisesti siitä, että usein tehdään asioita, joita ei ole ennen tehty. Olosuhteet asiakkaan tiloissa vaihtelevat, ja aina tarvitaan erilaisia kameroita ja muita kilkkeitä.
Pohjalla ovat tietysti yleiset IT-sopimusehdot: jos projektin aikana syntyy asiakkaasta johtuvia yllätyksiä, muistutetaan tuntihintamallista. Konenäköprojektienkaan työmääräarvioinnissa ei silti toki tikkaa heitetä, vaan nojataan kertyneeseen kokemukseen ja valistuneisiin arvauksiin. “Meillä on vilpitön pyrkimys läpinäkyvyyteen”, sanoo Lapinlampi. “Tätä asiakkaat arvostavat.”
Kaiken keskiössä ovat osaavat tekijät. “Meidän ihmiset ruukaa tehdä parhaansa. Ne nauttii, kun saa opetella uutta.”
Miten parhaansa tekemisen yrityskulttuuriin kasvetaan, kun mukaan tulee uusia ihmisiä?
“Uuden työntekijän kanssa pidetään aina ensin 1–2 tunnin kalvosulkeiset perusasioista. Tärkeät työsuhdejutut ovat senkin jälkeen kaikkien saatavilla Teamsissa”, kertoo Lapinlampi. “Mutta olennaista on käsitellä heti alkuun kaiken perusta: arvot, toimintatapa, asiakkaan kunnioittaminen. Edes selän takana ei puhuta pahaa.” Kehityskeskusteluissa tästä on tullut toimarillekin hyvää palautetta.
“Käsittämättömän hienoja asioita”
Millaisia asioita toimitusjohtaja itse arvostaa asiakaskokemuksessa?
“Olen valmis maksamaan enemmän hyvästä”, Lapinlampi toteaa. “En tarkoita luksusta, vaan henkilökohtaisuutta – oli kyseessä sitten B2C tai B2B. Meillä on esimerkiksi kahden hengen tilitoimisto, josta mielellämme pidämme kiinni: palvelu on joustavaa, neuvovaa ja opastavaa. Sama kokemus on liikelahjatoimittajasta – olemme käyttäneet samaa henkilöä jo vuosikausia. Tai vuokranantajamme Technopolis, ja erityisesti vastaanoton älyttömän mukava Teija: jos jotain tarvitaan niin sehän järjestyy.”
Hiotun suhteen asiakassuhteen ydin lienee tässä. “Meidän asiakkaat tekee siistejä juttuja, siis niin käsittämättömän hienoja asioita. Niistä on helppo innostua”, hehkuttaa Lapinlampi, mutta muistuttaa: “On mahtavaa, kuinka asiakkaita voidaan auttaa ihan yksinkertaisillakin softatoteutuksilla, vaikkapa excelöinnin korvaavalla web-sovelluksella tai tuotetietojen siirtymistä helpottavilla ratkaisuilla. Vaikka projekti olisi softaprojektina pieni, sillä voi olla jonkun asiakkaan tuottavuuden kannalta yhtä iso vaikutus kuin toiselle asiakkaalle on suurisuuntaisella sovelluksella.”
Hiottu testiautomaatio – näin sen teet!
Testiautomaatio on viime vuosina rynninyt ohjelmistokehitykseen, ja syystä. Aika on rahaa: manuaalitestaukseen verrattuna automaatiolla säästetään paljon, kun ihmiset voivat keskittyä toisiin asioihin. Kuulostaa ihmiskunnan ja yritysten unelmalta: jälleen yksi tarkkuutta vaativa, työläs, toisteinen ja aikaa vievä vaihe voidaan jättää tietokoneiden huoleksi. Vaan onkohan tuo ihan niin yksinkertaista?
“Testausta tehdään monella tasolla”, huomauttaa Kari Lapinlampi. “Koodaritasolla tehdään yksikkötestejä tietyn ominaisuuden tarkistamiseksi. Automaatiossa sen sijaan testataan koko järjestelmää päästä päähän, ja pidetään sekä vanhat että uudet ominaisuudet koko ajan mukana kuviossa.”
Automaatiolla saadaan helposti ajettua myös aiemmat testit nopeasti ja täsmälleen samalla tavalla. Näin varmistetaan, etteivät uudet muutokset aiheuta uusia ongelmia. Jos esimerkiksi testataan verkkosivustoa, automaatiotestaus voidaan ajoittaa yöajalle, ja katsoa tulokset seuraavana päivänä. Koodin laatu säilyy hyvänä – ja samalla koko lopputuotteen.
“Pintapuolisella käyttäjätestauksella ei mitenkään päästä samaan laadunvarmistustasoon kuin automaattitestauksella”, sanoo Kari Lapinlampi. “Isossa projektissa olisi ylipäätään mahdotonta, että ihminen tekisi kaiken. Toki ihmistyötäkin tarvitaan kokeilevaan testaamiseen.”
“Ja määrittelyyn”, lisää Jarmo Pylkkö. “Testien määrittelyä ei voi automatisoida: siihen tarvitaan joku, joka osaa kuvata, millaisia käyttötapauksia tiettyyn ominaisuuteen liittyy.”
Kun kehitys – runko, rakenne ja käyttöliittymä – ovat riittävän pitkällä, testit kirjoitetaan toteutettaviksi käyttöliittymää vasten. Kooditason testausta toki tehdään alusta pitäen, esimerkiksi tietokannan käyttötapoja.
Testeillä ei tutkita vain toiminnallisuuksia, vaan myös suorituskykyä. Onko vaste riittävän nopea? Kestääkö järjestelmä kuormitusta? Miten häiriötilanne syntyy? Millaisia häiriöt ovat? Kehityksessä tulee päivittäin vastaan tilanteita, joissa on riskinä, että aiemmin tehty paikkaus lakkaa toimimasta. Ilman testausta ja koodinmuutoksia asiakas saattaa esimerkiksi saada virheellisen kuvan jonkin prosessin toiminnasta. Väärää dataa tarjoava, mutta oikealta näyttävä toiminto on vaarallisempi skenaario kuin se, ettei mitään tapahdu.
Kertakorjauksesta ikivihreisiin
Ohjelmistokehityksen tahti on muuttunut olennaisesti viime vuosina. “Nykyään uusia ohjelmistoversioita tulee melkein viikon välein”, sanoo Kari Lapinlampi. Ohjelmistoista on tullut ikivihreitä, evergreenejä: koko ajan julkaistaan pieniä parannuksia. “Uusienkin versioiden pitää silti olla testattuja. Versioiden julkaisukäytännöt ovat muuttuneet perusteellisesti: jatkuvan ohjelmistokehityksen CI/CD-putkessa uuden version julkaisu voi tapahtua nappia painamalla.”
Testi kertoo, onko mahdollista edetä. Koodari kehittää yksikkötestit, ja ne yhdistetään pääkehityshaaraan. Hiotulla testiautomaatiosofta Jenkins huomaa tämän, hakee uuden koodin ja ajaa testit. Jenkins on integroituna versionhallintaan. Jenkinsin kaverina käytössä on Python-pohjainen Robot Framework.
Ohjelmistoja on tarjolla paljon. “Jenkins valikoitui meidän käyttöömme, koska se on avointa lähdekoodia, ollut pitkään olemassa, hyvin tuettu ja taipuu mihin käyttöön tahansa”, toteaa Jarmo Pylkkö.
Vaikka asioita kuinka automatisoitaisiin, perusasiat pysyvät.
“Viestintä on todella tärkeää”, korostaa Kari Lapinlampi. “Kehittäjän ja testaajan välisen kommunikaation täytyy pelata.”
“Niin se tahtoo mennä, että ensin kehittäjä vie iloisena muutokset pilveen”, Jarmo Pylkkö nauraa. “Sitten testaaja lähestyy koodaria ja vetää tämän alas: lopetapa juhliminen ja palaa jäljittämään ja korjaamaan.”
(Kuvan piirteli parhaan ymmärryksensä mukaan Crayion-tekoäly. Emme ostaisi siltä käytettyä polkupyörää.)