Lean ajattelu ohjelmistoprojektin valmistelussa



Lean ajattelu ohjelmistoprojektin valmistelussa lähtee kahdesta peruskysymyksestä:

  • Miten voimme tuottaa ohjelmistolla asiakkaallemme – välillä myös asiakkaan asiakkaalle – eniten arvoa (ja sitä kautta myös omalle liiketoiminnallemme)?
  • Miten saisimme tehtyä ohjelmiston tehokkaimmin, vähimmällä mahdollisella ylimääräisellä työllä? Entä kun mietimme ohjelmiston käyttöä ja ylläpitoa: onko prosesseja joissa voisi oikaista tai jopa työtä jonka voisi jättää kokonaan tekemättä?

Tietenkin ohjelmistoprojektiin valmistautuminen, myös ketterä projekti, vaatii lisäksi paljon tarkempaa ja syvällisempää suunnittelua. Tässä kirjoituksessa käydään läpi tärkeimmät visiotasolla suunniteltavat asiat.  Voit ladata maksuttoman lean-visiolakanan, jota voit käyttää visiotyöpajassa ohjausryhmän kanssa, ehkä jopa pitää näkyvissä projektihuoneen seinällä projektin ajan. Lakana on ladattavissa täällä.

Lean-visiolakana kiteyttää oleellisimman ohjelmistosta

Suunnittelutyön ongelmana on usein, että yksityiskohtia yritetään kuvitella ja kiinnittää paljon pidemmälle kuin on oikeastaan pakko. Samalla lukitaan ratkaisuja turhan aikaisin, ja kehitystyön aikana syntyvää ymmärrystä voi jäädä hyödyntämättä. Ihannetapauksessa nimittäin voitaisiin projektin aikana käyttäjäpalautteen avulla huomata esimerkiksi, että jotakin ominaisuutta ei tarvitse rakentaa ollenkaan.

Hyvä visioajattelu pitää kysymykset niin yleisellä tasolla, että päätöksentekijätkin jaksavat osallistua keskusteluun, ja toisaalta vaikkapa uusi projektiin tuleva henkilö saa tärkeimmistä asioista kirkkaan yleiskäsityksen ennen kuin hän ryhtyy syventymään projektiin tarkemmin. Hyvässä visioajattelussa päästään tietojärjestelmän ohella kiinni liiketoiminnan perimmäisiin kysymyksiin: Mikä on se epäreilu kilpailuetu, joka saa asiakkaat tulemaan meille eikä menemään naapuriin? Ja mikä toisaalta on meille koko homman tarkoitus, se minkä takia jaksamme aamulla nousta ylös sängystä?

Visio koostuu seuraavista asioista:

Käyttäjien ongelma

Projektin riskitasoa laskee heti kättelyssä, jos ongelma validoidaan eikä se perustu arvaukseen. Esim. käyttäjähaastattelut ovat hyvä keino tähän. Jos sitten huomataan että käyttäjäongelma oli väärä arvaus, suunnittelua voidaan jatkaa toiseen suuntaan ilman kummoisiakaan uponneita henkisiä tai konkreettisia kustannuksia.

Onnistunut järjestelmä ratkaisee käyttäjille jonkin tärkeän ongelman. Kuluttajabisneksessä kyse voi olla vaikka opiskelijoista jotka kaipaavat lukupiiriseuraa ja parempaa kontaktia opiskelutovereihinsa, organisaation sisäisissä järjestelmissä kyse voi olla vaivattomammasta ja varmemmasta kuittien käsittelystä kirjanpitoa varten. Useimmiten ongelmia voi luetella monia, mutta kirkkaan konseptin kannalta on hyvä, jos tärkeimmäksi saadaan nostettua yksi.

Järjestelmän tarjoama ratkaisu

Seuraavaksi on mietittävä, miten järjestelmämme ratkaisee edellä tunnistetun käyttäjän ongelman. Lukupiiriesimerkissä vastaus voi olla Tinder-tyylinen kohtauttamistyökalu, jossa hakija kertoo opintoaiheen johon kaipaa opiskeluseuraa ja työkalu ehdottaa kanssaopiskelijoita sopivalta paikkakunnalta ja oppilaitoksesta. Kuittiesimerkki voi ratketa vaikkapa kännykän appillä jolla voi kuvata kuitit lennossa.

Myös ratkaisu on syytä validoida. Se onnistuu esim. yksinkertaisen prototyypin ja siihen yhdistetyn käyttäjätutkimuksen avulla. Jos käy ilmi, että oletettu ratkaisu ei itse asiassa autakaan käyttäjän ongelmaan, voidaan lähteä hakemaan toista ratkaisua eivätkä tappiot vieläkään ole suuria.

Ainutlaatuinen arvo

Useimmiten järjestelmillä on tavalla tai toisella kilpailijoita, jos ei muita niin se, että käyttäjä jättääkin asian kokonaan tekemättä. Ainutlaatuinen arvo on ohjelmistossa se ominaisuus, joka saa käyttäjän käyttämään juuri meidän järjestelmäämme ja ihastumaan siihen. Lukupiiri-Tinder-esimerkissä tämä voi olla mahtava sosiaalisuuden tuntu, kuittikamerassa taas se että kuva kuitista hoituu yhdellä painalluksella laskujärjestelmään asti.

Ainutlaatuista arvoa voi lisäksi syntyä siitä, että uuden järjestelmän myötä saadaan helpotettua järjestelmää tarjoavan yrityksen omia prosesseja. Viekö jokin asia tiskin takana nykyään paljon aikaa? Onko jotakin minkä voisi jättää tekemättä kokonaan?

Molemmantyyppiset ainutlaatuiset arvot on edelleen tärkeää validoida. Jo prototyypissä voi kokeilla haetun hurmausefektin tehokkuutta, ja uusien työtapojen säästövaikutuksia voi mitata vaikka kokeilemalla ilmaistyökaluilla ennen kuin uusi järjestelmä on edes kehitysvaiheessa.

Avainresurssit toteuttamisessa ja päätöksenteossa

Jokaisessa ohjelmistoprojektissa on resursseja, joiden jääminen löytymättä tai menettäminen on iso riski projektin onnistumiselle. Tällainen voi olla taitava tuoteomistaja, sponsori ylimmässä johdossa tai ohjelmiston tekninen velho, mutta yhtä hyvin korvaamaton lanseerauskanava, datalähde tai lähiprojekti.

Kehitystiimiltä kaivataan yleensä paitsi tiettyä todistettua teknologiaosaamista, myös hyviä yhteistyötaitoja toistensa ja asiakkaan edustajan kanssa. Ja mitä erikoisempi teknologia tai vaatimusyhdistelmä on kyseessä, sitä kriittisempää juuri tiettyjen resurssien saamisesta yleensä tulee. Resursoinnissa kannattaa myös miettiä läpi jatkokehitysvaihe.

Resursointia miettiessä yksi avainkysymys on, onko tärkeimmissä resursoitavissa jotain mikä voitaisiin itse asiassa saada valmiina verkostojen kautta tai ostettuna. Voisiko siitä silloin tulla jopa parempi, ja softantekijät ja tilaaja pääsisivät keskittymään siihen minkä tekevät parhaiten?

Kenelle järjestelmää tehdään

Kohderyhmiä miettiessä mopo usein karkaa käsistä, ja erilaisia käyttäjätyyppejä päädytään luetteloimaan esim. 12 kappaletta. Lean-ajattelun hengessä kuitenkin hyödyllisintä olisi pyrkiä erottamaan yksi tärkein käyttäjäpersoona. Minkä käyttäjäryhmän varassa liiketoiminnan tuleva kasvu on? Kuka viettää järjestelmässä eniten aikaa? Mikä käyttäjäryhmä voisi tuoda muut mukanaan? Olisiko käyttäjäryhmää edustavia ihmisiä saatavilla pilottikäyttäjiksi kehitystyötä varten?

Käyttäjäpalaute ja mitä sitten

Käyttäjäpalautteen keräämisellä ja analysoinnilla varmistetaan, että palvelu kehittyy jatkuvasti paremmaksi. Tämä on edelleen tärkeää, kun järjestelmää kehitetään eteenpäin vaikkapa kymmenettä vuotta.

Tilauskannan kehittyminen on hyvä käyttäjäpalautteen mittari, mutta myös laadullisempaa dataa tarvitaan. Apuun tulee esim. prototyypeistä kerättävä palaute, järjestelmän käyttöanalytiikka, käyttäjille tehtävät kyselyt, muutosten A/B-testaus tai klassinen käytettävyystestaus.

Tärkein asia käyttäjäpalautteessa kuitenkin on, että sitä käytetään päätöksenteon pohjana yhtä hyvin projektin päivittäisessä elämässä kuin isommissakin linjoissa esim. ohjausryhmän kanssa. Muuten kerääminen on jokseenkin hyödytöntä.

Rajoitukset projektille

Jokaisella ohjelmistoprojektilla on rajoituksia. Tyypillisimpiä ovat liiketoiminnan sykli tai aikataulu, johon on osuttava täyden hyödyn saamiseksi investoinnista. Esim. Lukupiiri-Tinderin tapauksessa lukukauden alku on tärkeä, koska opiskelijat järjestelevät elämäänsä ja ovat avoimia uusille vaikutteille.

Myös budjetti on usein rajallinen, ja suunnittelua tarvitaan. Maksavatko lisenssit, tarvitaanko laitteita ja tiloja kehitykseen, hankitaanko ohjelmistokehittäjät rekrytoinneilla vai ostamalla?

Harva järjestelmä tuottaa arvoa ilman, että käyttäjät tietävät siitä. Paljonko lanseeraukseen olisi syytä varata työtä tai rahaa?

Miten palvelun ylläpitovaihe eli hosting ja mahdollinen jatkokehitys aiotaan resursoida? Halutaanko järjestelmä taas uudistaa joidenkin vuosien päästä isosti, vai kehitetäänkö sitä mieluummin jatkuvasti pienellä panoksella?

Tekninen visio

Teknisessä visiossa ohjelmiston ostaja hyötyy eniten toimittajasta, ja suunnittelu onkin syytä tehdä yhdessä. Toisaalta seassa on kysymyksiä, joissa leanit ratkaisut eivät välttämättä kulje käsi kädessä toimittajan maksimikatteen kanssa. Omaakin visiota on siis hyvä hankkia vaikka sitten riippumatonta näkemystä ostamalla.

Millä teknologioilla ohjelmisto aiotaan toteuttaa? Onko vaihtoehtoja? Mikä tekniselle onnistumiselle on ensiarvoista, haetaanko vaikkapa monistettavuutta tulevaisuutta varten vai riittääkö kertatoteutus? Suositaanko avointa lähdekoodia?

Miten projektissa voitaisiin tehdä mahdollisimman vähän ohjelmistokehitystä? Onko olemassa valmiita tuotteita, joilla osa tarpeista voitaisiin kattaa vaikkapa muovaamalla vaatimuksia hiukan? Onko käytettävän teknologian sisällä valmismoduuleita joita voitaisiin käyttää, tai jopa olemassa olevia toteutuksia joihin voitaisiin pohjata? Jos käytetään avointa lähdekoodia, hyödynnetäänhän kehittäjäyhteisön valmiit ratkaisuaihiot?

Yksi järjestelmän lisäarvon ulottuvuuksista syntyy siitä, mitä sillä voidaan korvata. Sitä kautta voidaan esim. saada säästöä lisenssikustannuksissa.

Edelleen on mietittävä, mihin järjestelmä linkittyy – tästä syntyy teknisiä rajoitteita. Pitääkö sen viedä tai tuoda dataa, ja jos niin mihin kaikkiin järjestelmiin? Mitkä ovat turvallisuustarpeiden ja lain tai säännösten aiheuttamat rajoitukset?

Ja viimeisenä: mihin järjestelmän jatkokehitettävyys perustuu? Ollaanko valittu teknologia, jolla on pitkä elinkaari, vai lähdetäänkö suoraan siitä, että homma on menossa uusiksi muutaman vuoden päästä? Tämä vaikuttaa teknologiavision kunnianhimotasoon. Jos ketterä projekti etenee iteratiivisesti mutta aikajänne on pitkä, miten myöhemmin aiotaan kuroa umpeen teknistä velkaa, jota alun nopeissa voitoissa on mahdollisesti syntynyt? Löydetäänkö valituille teknologioille osaajia myös tulevaisuudessa?

Liiketoimintamittarit

Lean ajattelu ohjelmiston visiossa päätyy tuottonäkökulmaan. Kun visio on muodostettu ja validoitu, kehitys etenee suunnitellusti ja asiakkaalle alkaa syntyä uutta arvoa, kehitysinvestointi alkaa näkyä viivan alla. Vaikutuksen toteamiseen tarvitaan kuitenkin mittareita.

Visiossa on hyvä tunnistaa, onko järjestelmän tarkoitus tuoda liiketoimintaan kenties kokonaan uusi alue tai käänne, vai tähdätäänkö laadun parantamiseen esim. asiakaskokemuksessa tai lopputuloksissa? Vai haetaanko ennemminkin toiminnan tehostamista?

Molemmissa tapauksissa tarvitaan sekä välittömiä että epäsuoria mittareita. Lukupiiri-Tinderin tapauksessa välitön mittari voi olla esimerkiksi opiskelijoiden kokema tyytyväisyys ja tenteistä saadut arvosanat, ajan mittaan tulokset näkyvät toivottavasti nopeutuneina valmistumisaikoina ja vähentyneinä mielenterveysongelmina.

Lean-visiolakana käyttöösi

Oman ohjelmistovisiosi vastaukset edellä listattuihin ydinkysymyksiin voit kirjata joko täytettävään PDF:ään tai tilata samalla lomakkeella maksutta työpajaasi A1-kokoisen visiojulisteen.

Visiolakanan lisäksi projekti tietenkin tarvitsee paljon muita ohjausvälineitä, kuten tarkemman konsepti-idean ja mahdollisesti sitä testaavan proton, käyttäjätutkimuksen ja siltä pohjalta muodostetut käyttäjäpersoonat, kehitysjonon ja jonkin välineen sen käsittelyyn, konkreettiset menestysmittarit ja niiden tulosseurannan, resurssi- ja budjettisuunnittelun, taustajärjestelmäselvitykset sekä välineet käyttäjäpalautteen keräämiseen. Visiolakana kiteyttää projektin sielun ja kokoaa edellä mainitut yhteen.

Lataa lean-visiolakana maksutta

Voit ladata visiolakanan täällä.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *