Lean-mittarit – mittaa ja muutu

Muutos on iloinen asia

Lean on jatkuvaa muuttumista – parantamista. Kyky muuttua on olemassaolon kannalta olennaista, oli sitten kyse organismista tai organisaatiosta. Yrityksille jatkuva kilpailu luo painetta muuttua, koska kilpailijat hakevat jatkuvasti tapaa parantaa tuotteitaan ja tapaa, jolla tuotteet tehdään. Jos ei osallistu tähän muutokseen on vain ajan kysymys milloin saa etsiä uutta tekemistä.

Yhtäältä on tärkeää kehittää sitä tapaa jolla yritys luo lisäarvoa ja näin ajaa kustannuksia alas. Toisaalta jos keskityt vain olemassa olevan parantamiseen, niin status quo voi muodostua liian rakkaaksi ja olet vaikeuksissa, kun on aika muuttaa liiketoiminnan suuntaa.

Olennaista on ymmärtää missä on, ja mihin haluaa päästä. Tämän jälkeen on paljon helpompaa todentaa mittareilla, miten eteneminen kohti tavoitetta sujuu.

Haluamme jakaa lean-mittaamisen ilosanomaa

Kävimme yhdessä Karoliina Luodon kanssa puhumassa Scan Agilessa mittaamisesta, miten sitä pitää tehdä usealla tasolla, tasojen linkittämisestä ja siitä, miten mittareilla voi ajaa lean-muutosta.

Esittelimme tavan asettaa kuusi mittaria, joilla voit ottaa haltuun yrityksen suunnan, asiakkaan ja kehityksen.

Ylempi kuva: Flickr Creative Commons, seabamirum.

 

 

Hyvä käytettävyys syntyy perusasioista

Paras ohjelmisto on se, jota ei tarvinnut kehittää. Jos käyttäjien tarpeisiin riittää mainiosti pelkkä PDF, on turhaa käyttää rahaa sovelluskehitykseen.

Kysyin ohjelmistokehittäjältämme Jussi Rytköseltä ja ohjelmistoarkkitehdiltamme Jaakko Holsterilta, mitä heidän mielestään on hyvä käytettävyys. Heidän mukaansa hyvä käytettävyys ei välttämättä ole vaikeaa tai edes kallista, kunhan muistaa perusasiat. Jussin ja Jaakon käytettävyyden tärkeimmät teemat ovat:

1) Panosta määrän sijasta laatuun

Heti alkuun Jaakko nostaa esille esimerkin hyvästä käytettävyydestä: Helsingin kaupungin pysäköintialuekartan. Se skaalautuu hienosti, on terävä ja toimii sulavasti kaikilla alustoilla, niin mobiilisti kuin näyttöpäätteelläkin – ja kartta on itse asiassa PDF-tiedosto, ei sovellus.

“Yksinkertainen ja toimiva on paljon parempaa kuin kallis, monimutkainen ja huonosti toimiva. On parempi käyttää rajallinen budjetti perustoiminnallisuuteen, joka toteutetaan hyvin,” Jaakko tiivistää. “Kannattaa toteuttaa vain sellaista, joka tuo tutkitusti käyttäjien enemmistölle arvoa. Ominaisuuksien karsiminen ei takaa hyvää käytettävyyttä, mutta helpottaa huomattavasti siihen pääsemistä.”

Jussi komppaa: “Mitä pienemmäksi ja hiotummaksi kokonaisuuden pystyy tiivistämään, sen parempi. Hyvässä designissa suurin kohteliaisuus on, jos loppukäyttäjälle tulee sellainen olo, että tämähän on maailman yksinkertaisin juttu, miksi tämä toimisi millään muulla tavalla.”

2) Älä riko toimivaa

“Perinteiseen verkkokäytettävyyteen liittyy paljon itsestäänselvyyttä”, Jussi toteaa. “On asioita, jotka ovat toimineet webissä melkein ensimmäisestä selaimesta lähtien, mutta ne eivät enää toimikaan mobiilissa. Tämä on yksi pahimpia ongelmia nykysoftien käytettävyydessä, että unohdetaan perusasiat,” Jaakko säestää. Linkkien ja takaisin -nappulan tulee toimia myös modernissa sovelluksessa aivan kuten perinteisillä sivustoilla.

3) Muista, että hyvä design on ajatonta

Hyvä esimerkki aikaa kestämättömästä design-trendistä on niin sanottu cover flow, jotka olivat suurta huutoa muutama vuosi sitten. Tuolloin monet halusivat sellaisen sivuilleen, mutta suosiota seurasi vääjäämätön kyllästyminen. Lopulta myös huomattiin, ettei cover flow ollut kovin mukava käyttääkään. Jokaista uutta käyttöliittymätrendiä ei siis kannata noudattaa orjallisesti. “Jos se tuntuu heti aluksi hieman arveluttavalta, se luultavasti ei ole paras tapa tehdä kyseistä asiaa. On parempi välttää turhaa kikkailua,” tuumaa Jaakko.

Toisaalta liiallinen pelkistäminen voi myös huonontaa käytettävyyttä. “Aika usein tulee vastaan tapauksia, joissa on viety pelkistämistä niin pitkälle, että käyttäjälle alkaa olla epäselvää, mitkä asiat käyttöliittymässä ovat interaktiivisia,” Jaakko jatkaa.

Myös designin johdonmukaisuus on tärkeää käytettävyyden kannalta. “Täytyy olla tarkkana, että design ei ala hajota suuressakaan ohjelmistossa. Samannäköisestä nappulasta painamalla täytyy aina seurata sama toiminto,” Jussi muistuttaa.

4) Muista minimalistisuus myös pinnan alla

Nykyään lähes kaikki sovellukset perustuvat pitkälti uudelleenkäytettäviin ja yleiskäyttöisiin koodikirjastoihin. Kirjastot nopeuttavat ohjelmistotuotantoa, mutta usein niiden mukana tulee paljon myös turhia ominaisuuksia. Jaakko kehottaa käyttämään kirjastoja harkiten.

“On hienoa, että nykyään tehdään minimalistisia ulkoasuja, mutta kun vielä saataisiin se minimalistisuus sinne konepellinkin alle. Mikään sovellus ei voi olla erityisen nopeasti reagoiva ja hyvä käyttää, jos se tökkii liian koodin takia,” Jaakko kertoo.

5) Ota budjetti tehokäyttöön leanillä

Tiukalla budjetilla kannattaa suosiolla tehdä yksi rajallisesti responsiivinen versio sovelluksesta, joka on suunniteltu toimimaan ensisijaisesti mobiilialustalla. Zoomattava näyttöpäätesivustokin voi toimia paremmin puhelimella käytettäessä, kuin päälleliimatun oloinen ja huolimattomasti testattu mobiiliversio.

“Leanin kehityksen periaatteiden mukaisesti kannattaa miettiä softan tärkein ydintoiminnallisuus, ja toteuttaa se ensin ja kunnolla. Lisätoimintoja voidaan sen jälkeen kasata sen mukaan, mihin resurssit vielä riittävät,” Jaakko sanoo.

Myös Jussi puhuu leanin ohjelmistokehityksen puolesta: “Kenelläkään ei ole niin paljon tietoa, että osaisi tehdä täydellisen designin saman tien. Parhaat käyttöliittymät hioutuvat kehityksen aikana.” Jaakko jatkaa: “Kannattaa myös mahdollisimman varhaisessa vaiheessa antaa ohjelmisto loppukäyttäjien testattavaksi, jotta saadaan palautetta ja voidaan iteroida. Ei kannata käyttää budjettia turhaan tekemiseen.”

Lopuksi Jussi ja Jaakko haluavat nostaa esille ranskalaisen kirjailijan, Antoine de Saint-Exuperyn (1900-1944) mietelmän, joka on yhä hämmästyttävän ajankohtainen ja pätee hyvin softakehitykseen. Jos tämä blogaus pitäisi tiivistää yhteen lauseeseen, se voisi hyvinkin olla tämä:

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

 

CV-talkoot kerran kuussa?

Digiperiaate lupaa pyytää tietoa vain kerran

Valtionvarainministeriön kuudes digitalisoinnin periaate sanoo: “Pyydämme uutta tietoa vain kerran.” Tiukasti ja kirjaimellisesti tulkittuna periaate tarkoittaa, että kun jokin julkisen hallinnon osa on kerran pyytänyt – ja saanut – jonkin tiedon kansalaiselta, tieto on kaikkien muidenkin julkisen hallinnon osien käytössä. Tietojen siirto voi olla automaattista, vaikkapa kansallisen palveluväylän kautta, tai viranomaiset voivat kansalaisen tietämättä siirtää tietoja toisilleen esimerkiksi paperilomakkein ja telafaksein. Kansalaista valtio lupaa vaivata kunkin tiedon osalta vain kerran.

Valtionhallinnolle paljon työtä tekevänä konsulttina olen hyvin innostunut digitalisoinnin kuudennesta periaatteesta. Konsulttina näet joudun usein vastaamaan julkisen hallinnon tarjouspyyntöihin – hankintalain mukaan suoraan ei sovi ostaa vaikka puitesopimus olisi voimassa. Olisi suurenmoista, jos kerran julkishallinnolle antamani CV-tietoni olisivat jatkossa julkishallinnon käytettävissä seuraavissakin kilpailutuksissa. Näin ei kuitenkaan ole.

Turhaa työtä jokaisesta kilpailutuksesta

Julkisen hallinnon tarjouspyynnöt ovat kaikki erilaisia. Tarjouspyynnön kohteen erilaisuus on tietenkin luonnollista, sillä eihän samaa työtä ole tarpeen eikä syytä tehdä kahteen kertaan. Konsultin kannalta harmillista on, että aivan jokainen julkishallinnon laatima tarjouspyyntö vaatii jokaisen konsultin CV- ja osaamistiedot uudestaan ja joka kerta erilaiseen ja eri formaatissa olevaan dokumenttiin täytettynä. Tästä seuraa loputon määrä ylimääräistä työtä sekä julkishallinnossa että konsulttifirmoissa. Julkishallinto joutuu joka kerta laatimaan uudet lomakkeet ja manuaalisesti käsittelemään lomakkeilla saamansa tiedot. Konsultit joutuvat täyttämään tietonsa moneen kertaan – vaikkei yksittäisen konsultin työhistoria muutu kilpailutuksesta toiseen.

Kuinka suuresta työmäärästä on kyse? Arvioidaanpa työmäärää erään viimeaikaisen kilpailutuksen perusteella. Tarjouspyyntöön vastataksemme meidän piti täyttää kolmeen kertaan samat tiedot kunkin tarjoamamme konsultin työhistoriasta. Yhteensä saimme aikaiseksi yli 200 sivua taulukkoja Word-muodossa. Meillä tähän meni varmaankin 25 työpäivää. Vastaanottajalla, kilpailutuksen järjestäjällä, menee varmasti useita kymmeniä työpäiviä meidän ja muiden kilpailutukseen osallistuvien konsulttifirmojen toimittamien yhteensä tuhansien sivujen läpikäyntiin, manuaaliseen pisteytykseen ja päätöksen tekemiseen ja perustelemiseen.

Tämän yhden kilpailutuksen työmäärä on siis tarjoajien puolelta satoja työpäiviä ja kilpailuttajan puolelta vähintäänkin kymmeniä työpäiviä. Tämän kilpailutuksen jälkeen nyt tehty työ on arvontonta, koska tällä kertaa kerätyt tiedot ovat formaatiltaan vääriä seuraavassa kilpailutuksessa. Tietojen sisältö on tosin oikein.

Tuottavuusloikka Suomen digitalisointiin

Voisiko tämän tehdä jotenkin helpommin? Olisiko mahdollista rakentaan LinkedInin tapainen konsulttitietopankki, jonne konsultit syöttäisivät CV-tietonsa ja osaamisensa ja josta valtionhallinnon – ja ehkä jopa kuntienkin – kilpailuttajat kävisivät tiedot hakemassa, tarkistamassa ja pisteyttämässä?

Voisipa hyvinkin olla. EU:ssa tällainen jo onkin: Europass. Se ei aivan sellaisenaan sovi Suomen konsulttikilpailutuksiin, mutta muutaman kuukauden kehitystyöllä siitä saisi riittävän hyvän aikaiseksi.

Kelpaisikohan tämä pieneksi tuottavuusloikaksi maamme digitalisointitalkoisiin? Kuka tarttuisi toimeen? Kuka kilpailuttaisi suunnittelu- ja toteutustyön? Hanke on triviaalisti kannattava.

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.