Käyttäjälähtöisen ja ketterän kehittämisen etuja on vaikea havaita käytännössä. Tällä blogikirjoituksella näytämme, miten merkittävästi perinteinen ja ketterä toimintatapa vaikuttavat yrityksen tulokseen.
Käymme läpi kaksi totuutta mukailevaa projektiesimerkkiä. Molemmissa projekteissa halutaan toteuttaa digitaalinen lipunmyyntipalvelu.
Ensimmäisessä kuvitteellisessa esimerkissä tuomme esiin BusinessPro-nimisen yrityksen perinteisen tavan tehdä lipunmyynnin digipalvelua. Toisessa esimerkissä kerromme, kuinka LippuSoft-niminen yritys puolestaan hyödynsi palvelun kehittämisessä Fraktiolle ominaista kehitysprosessia.
Käymme läpi kaksi projektia, joiden lähestymistavat ja tekemisen mallit eroavat toisistaan.
BusinessPro
BusinessPro on pari vuotta alalla ollut tapahtumien lipunmyyntiin keskittyvä yritys. Yrityksen johto on tyytymätön markkinoilla oleviin verkkokaupparatkaisuihin.
Johto miettii ratkaisun valmiiksi
BusinessPron sisällä johtohahmot ja nykyistä järjestelmää ylläpitänyt ohjelmistokehittäjä ovat keskenään miettineet uutta ratkaisua. Samalla he ovat luonnostelleet uuden palvelun PowerPointilla.
BusinessPron tiimin mielestä Angular-projektirunko näyttäisi sopivalta ja verkosta on löydetty ulkoasuun passeli Google Material Design -teema.
Tiimin mielestä palvelu on valmis toteutukseen. Projekti on kuitenkin liian suuri yhden työntekijän toteutettavaksi, joten työhön tarvitaan yhteistyökumppani.
Tiukasti rajattu budjetti ohjaa kehitystä – halvin tarjous voittaa
BusinessPron johto on laskenut itse paljonko uusi palvelu säästäisi sekä tehnyt ennusteet jälleenmyynnistä. Budjetti on tiukasti rajattu. Tarkoitus on keskittyä vain tärkeisiin asioihin.
BusinessPro lähestyy useita konsulttitahoja tarjouspyynnöillä ja saa useita tarjouksia. Ihmetystä herättävät maininnat tutkimuksista ja esisuunnittelusta, sillä palvelu on BusinessPron mielestä tekemistä vaille valmis.
BusinessPro solmii sopimuksen uuden, erittäin halvan hinnan tarjoavan konsulttitalon kanssa, jolla on referenssejä Angular-projektista.
BusinessPro uskoo, että palvelu on jo toteutusta vaille valmis. Päätökset tehdään johdon palavereissa.
1. viikko
Ryminällä pystyyn
Palvelun kehittäminen pyörähtää käyntiin ryminällä. Koodiympäristö saadaan pian pystyyn ja ensimmäisen viikon aikana ohjausnäkymän runko alkaa hahmottua. Kaikki ovat tyytyväisiä ripeään tahtiin. PowerPointin piirrokset alkavat muotoutua aidoiksi sivuiksi.
Kuukauden kuluttua
Näkymiä puuttuu – johto miettii ratkaisut
Kehittäminen jatkuu, vaikka huomataan, että tärkeitä näkymiä kuten hukkuneen salasanan pyytämistä, tilinhallintaa ja kuittien suodattamista ei ollut huomioitu riittävästi suunnitteluvaiheessa.
Yrityksen johto miettii keskenään ratkaisuja ja luonnostelee ne PowerPointilla valmiiksi. Myös ohjelmistokehittäjät miettivät tahollaan mahdollisia ratkaisuja ongelmiin.
2 kuukauden kuluttua
1. versio melkein toimii ja budjetti ylittyy
Parin kuukauden kuluttua aloituksesta ensimmäinen versio palvelusta melkein toimii. Suurin haaste on rakentaa ja saada toimimaan aiemmin päätettyjä näkymiä sekä muodostaa verkkomaksuyhteys pankkeihin.
Alkuvaiheessa tehdyt päätökset tietokantarakenteesta saivat aikaan lähetysvirheen järjestelmässä. Virheen selvittäminen osoittautui odotettua hankalammaksi. Projektin budjetti ylittyy.
3 kuukauden kuluttua
Päätetään julkaista puolivalmis palvelu
Projekti ylittää budjetin. Yrityksen sisällä palvelua aloitetaan näyttämään useille henkilöille. Eri osastojen ihmiset saavat tilejä, joilla työntekijät pääsevät tutustumaan palveluun. Jokainen työntekijä huomaa eri haasteen.
Johdon on vaikea päättää mitkä havainnot ovat tärkeitä. Pitääkö palvelun toimia mobiilissa? Ovatko valikon valinnat riittävän selkeitä? Pitäisikö käyttäjän profiilista pystyä näkemään onko hän kirjautunut järjestelmään?
Kasvavan tehtävälistan edessä johto tekee päätöksen, että viimeiset työn alla olevat asiat viedään loppuun ja sitten palvelu otetaan käyttöön. Projektin budjetti on ylitetty viikkoja sitten.
Julkaisun valmistelu tuo esille uusia ongelmia
Julkaisua varten nimitetään oma tiimi luomaan myyntimateriaaleja sekä siirtämään BusinessPron omat tapahtumat ja asiakastiedot palveluun.
Julkaisutiimillä on haasteita saada selkeää kuvaa palvelun toiminnoista, sillä projektin dokumentaatio on ollut vähäistä ja sekavaa.
Samalla tiimi kokee tapahtumien massasyötön vaivalloiseksi ja pyytää lisäämään toiminnon. Aikataulujen vuoksi kehittäjille toimitetaan tapahtumien tiedot sisältävä Excel-tiedosto, jonka he ajavat räätälöidyn koodin avulla sisään palveluun.
Julkaisu yllättää käyttäjät ja tuo esille lisää puutteita
BusinessPro ottaa palvelun sisäisesti käyttöön ja päivittää verkkosivunsa hyödyntämään uutta ostojärjestelmää. Julkaisun yhteydessä asiakaspalvelu kuormittuu käyttäjistä, jotka ihmettelevät uutta käyttöliittymää. Käyttäjät eivät löydä tarvittuja tietoja, joitakin osioita puuttuu kokonaan.
Julkaisun jälkeen
Käyttäjien tyytymättömyys ruuhkauttaa asiakaspalvelun
Seuraavat viikot menevät asioiden selvittelyyn. Asiakaspalvelu yrittää selviytyä tyytymättömien käyttäjien kommenteista. BusinessPro saa lopulta julkaistua tiedotteen ja ohjeet uuden järjestelmän käyttämiseen. Lisäksi luodaan linkki vanhaan järjestelmään niille, jotka tarvitsevat vanhoja, uudesta järjestelmästä puuttuvia toimintoja. Parin viikon kuluessa kyselyiden määrä vihdoin laskee.
Palvelun puutteellisuuden vuoksi kysyntää ei ole
Uuden palvelun oli tarkoitus tuottaa lisämyyntiä, mutta sen sijaan raportit kertovat lippujen pienentyneestä menekistä.
BusinessPro yrittää myydä palvelua muille tapahtumatarjoajille, mutta joutuu huomaamaan, että palvelusta puuttuu useita ammattilaisille tärkeitä toimintoja.
Tehdyt päätökset vaikeuttavat jatkokehitystä
Kehitystiimi on saanut ison määrän tikettejä ja kehityskohteita julkaisun jälkeen. He huomaavat, että palvelussa on paljon teknistä velkaa. Kehitysprosessin aikana tehdyt päätökset vaikeuttavat jatkokehitystä huomattavasti.
Palvelun jälleenmyynnistä luovutaan
BusinessPro luopuu ideasta jälleenmyydä palvelua toistaiseksi. Kehitystiimiä ohjataan paikkaamaan suurimmat aukot palvelussa. Vihdoin vanha järjestelmä saadaan ajettua alas pysyvästi ja parannettua asiakkaiden palautetta.
Vaikka projekti ylitti budjetin ja sai huteran vastaanoton, palvelu toimii ja säästää aikaa arjessa. Ehkä jonain päivänä palvelu saadaan vielä houkuttelevaksi muille.
LippuSoft
LippuSoft on uusi startup, jonka perustajina on kaksi liikemiestä. He haluavat luoda “tapahtumien lipunmyynnin Woltin”. Yrityksen omistajat törmäsivät toisiinsa paikallisessa yritystapahtumassa, jossa molemmilla oli vaikeuksia löytää lippu sähköpostista.
Ensimmäinen versio varmistaa rahoituksen
Startup palkkaa nuoren kehittäjän, jonka avulla he kehittävät ilmaisilla järjestelmillä ensimmäisen ratkaisun. Ratkaisu on puutteellinen ja kankea, mutta riittää varmistamaan yritykselle rahoituksen.
Omistajat benchmarkkaavat palveluita, joissa on heidän mielestään hyviä ideoita. He myös puhuvat ideasta useille ulkopuolisille. Noista keskusteluista nousee myös vinkki Fraktiosta.
Ketterä kehittäminen vakuuttaa
LippuSoft sopii tapaamisen Fraktion kanssa. Tapaamisessa mukana ovat suunnittelija ja kehittäjä, jotka kyselevät projektiin liittyvistä tarpeista sekä kertovat, kuinka lähestyisivät ongelmaa.
Fraktion toteuttaa projekteja ketterää toimintatapaa hyödyntäen. Tärkeintä on löytää palvelun tuoma arvo käyttäjälle.
LippuSoftin omistajat ovat vakuuttuneita referensseistä ja käyttäjälähtöisestä suunnittelusta. He kuitenkin epäröivät miettiessään paljonko kehittäminen tulee maksamaan.
Ketterästi toimimalla ei lukittauduta ensimmäisiin ajatuksiin, vaan tärkeintä on löytää palvelun tuoma arvo käyttäjälle.
1. viikko
Viikossa käyttäjätestattuun prototyyppiin
Palvelun kehittäminen alkaa tiivistetyllä Design Sprint -työpajalla. Työpajassa mukana ovat tapahtumajärjestäjä ja ulkopuolinen, tapahtumissa kuukausittain vieraileva henkilö.
Työpajassa kuullaan lisää kokemuksista, tarpeista ja järjestelmän vaatimuksista. Lisäksi kartoitetaan tapahtumajärjestäjän ja lipunostajan käyttäjäpolut, jotta nähdään, kuinka palvelu nivoutuu osaksi heidän kokemustaan.
Tiimi luo kerätyn tiedon pohjalta projektisuunnitelman ja lähtökohdat kehitykselle. Tärkeimmäksi ratkaistavaksi haasteeksi jää luoda lipunostopalvelu, jota on vaivaton käyttää. Vaivattomuutta käyttäjälle on maksaa parilla painalluksella sekä hyödyntäen olemassa olevia maksualustoja. Lisäksi palvelu auttaa käyttäjää löytämään lipun tapahtuman alkaessa.
Viikon aikana on edetty idean konseptoinnista käyttäjätestattuun prototyyppiin. Samanaikaisesti ohjelmistokehittäjät selvittävät tietokannan rakennetta. Aiempaa kokemusta alasta ei ole, mutta he etsivät tietoa haastattelemalla asiantuntijoita sekä kartoittamalla parhaita käytäntöjä.
2. viikko
Prototyypin testaus osoittaa suunnan
Prototyyppi testataan etänä viiden käyttäjän kanssa. Testauksessa on mukana koko työryhmä. Testaus auttaa selvittämään, mitkä osiot eivät olleet käyttäjille selkeitä ja mitä toimintoja puuttuu.
Testauksesta johdetut työtehtävät priorisoidaan perustuen ydintoiminnallisuuteen eli vaivattomasti käytettävään lipunostopalveluun.
Laajennettava rakenne ja kattava rautalankaversio
Ohjelmistokehittäjille on muodostunut selkeä käsitys siitä, miten tietokanta tulisi rakentaa. Selkeä, tehokas ja laajennettava rakenne, johon kaikki kehittäjät uskovat. Luodussa taustajärjestelmässä voi luoda perustapahtumia karulla lomakkeella.
Suunnittelijoilla on aikaisempien havaintojen pohjalta alustava käsitys siitä, kuinka palvelu toimii sekä tapahtumajärjestäjälle että lipunostajalle. Suunnittelijat luovat palvelusta kattavan rautalankaversion, jossa huomioidaan aiemmin saatuja havaintoja.
Kuukauden kuluttua
Testaus osoittaa suunnan ja ongelmat ratkaistaan käyttäjä edellä
Kehittäjät alkavat rakentaa yhteyttä verkkopankkeihin. Suunnittelijat testaavat uusia prototyyppejä käyttäjien ja tapahtumajärjestäjien kanssa.
Yhteystesteissä havaitaan puutteita tietokantarakenteissa. Tulokset johtavat hedelmällisiin keskusteluihin asiakkaan kanssa siitä, miten he haluavat, että järjestelmä rakennetaan.
Verkkopankin rajapinnat pakottavat valitsemaan toisen kahdesta mallista. Malli tulee määrittämään vahvasti palvelun arkkitehtuuria sen elinkaaren aikana.
Ratkaisuun päästään kertaamalla ensimmäisen yhteisen työpajan päätöksiä suunnasta ja käyttäjätutkimuksen havainnoista. Valitaan se hieman vaikeampi, mutta skaalautuvampi vaihtoehto.
2 kuukauden kuluttua
Testien avulla tietoa lisäpalveluiden tarpeesta
Suunnittelijat havaitsevat testeissään, että tapahtumajärjestäjiä turhauttavat nykyiset ratkaisut. Monilla on toistuvia tapahtumia, joista he haluaisivat tallentaa mallipohjat, jotka nopeuttaisivat tapahtumien luontia. Myös tuotteiden myyminen samassa palvelussa olisi arvokasta.
Huomio inspiroi intensiivisiä keskusteluja siitä, mitä palvelu voisi olla. Koska tavoitteena oli luoda vaivaton ostokokemus, lisäominaisuudet aikataulutetaan työn alle heti julkaisun jälkeen – ensin hoidetaan kuntoon käyttäjien puoli ja sitten tapahtumajärjestäjien.
Tavoitteiden tiedostaminen tässä vaiheessa antaa mahdollisuuden kehittäjille lisätä koodia tietokantaan, mikä nopeuttaa seuraavan vaiheen toteutusta.
3 kuukauden kuluttua
Luottamus palveluun rohkaisee näyttävään pilotointiin
Palvelu alkaa olla valmiina julkaisuun. Käyttäjien ongelma on tiedostettu ja korjattu varhain, jotta käyttöliittymä on mahdollisimman selkeä käyttää.
Tiimi on saanut hienon idean toteuttaa julkaisutapahtuma uuden palvelun kautta, jolloin palvelu pilotoidaan samalla. Toteuttamalla palvelu skaalautuvalla pilviarkkitehtuurilla varmistetaan, että palvelu toimii nopeasti huolimatta ihmismassasta.
Käyttäjätieto auttaa julkaisun suunnittelua
Kehitysbudjetti on pysynyt raameissaan, minkä vuoksi markkinointibudjetti on säilynyt julkaisua varten. Lisäksi sijoittajat ovat olleet mielissään edistyksestä, jota ovat nähneet.
Fraktio auttaa LippuSoftia löytämään erinomaisen markkinointikumppanin, joka luo julkaisuun ja yrityksen tyyliin sopivan kampanjan. Työpajoissa kerätty tieto käyttäjistä tukee ja nopeuttaa kampanjan luomista. Julkaisuviestit kohdennetaan testeihin osallistuneille tapahtumajärjestäjille ja muille tärkeille tahoille, mikä saa myös alan blogit puhumaan tulevasta julkaisusta.
Julkaisu
Onnistunut julkaisu tuo ensimmäiset kaupat
Julkaisu sujuu onnistuneesti – ihmiset saavat lippunsa vaivattomasti. Ilmainen ensitapahtuma veti väkeä ja kerätyn palautteen mukaan suurin osa oli innoissaan uuden palvelun helppoudesta.
Markkinointikumppanin lähettämä tiedote sai pari lehteä ottamaan yhteyttä ja kirjoittamaan artikkeleita. Ensimmäiset kaupat syntyvät muutaman päivän kuluessa.
Tiimi korjaa pari havaittua pientä bugia, mutta suurimmaksi osaksi järjestelmä toimii odotetusti. Jatkuva testaaminen projektin ulkopuolisten henkilöiden kanssa kantaa hedelmää.
Julkaisun jälkeen
Seuraava kehitysvaihe käynnistyy
Seuraavan vaiheen työ alkaa pian palvelun julkaisun jälkeen. Tiimiin tuodaan yksi kehittäjä lisää varmistamaan, että käyttäjäpuolen palvelu jatkaa kehitystään samalla kun tiimi lähtee panostamaan entistä enemmän tapahtumajärjestäjien palveluun. Työ alkaa jälleen yhteisillä työpajoilla.
Yhteenvetona
Riskit toteutuvat, kun suunnitelmasta pidetään kiinni väkisin
Vaikka nämä projektit olivat vain ajatusleikkiä, törmäämme niissä käsiteltyihin asioihin usein. Joudumme perustelemaan testaamisen tärkeyttä, suunnitelman muutoksia ja budjetteihin.
BusinessPron ja LippuSoftin projektin eroista on helppo nähdä, kuinka riskit toteutuvat, kun projektisuunnitelmasta pidetään väkisin kiinni eikä loppukäyttäjää ole otettu mukaan riittävän aikaisessa vaiheessa.
Viimein BusinessPron palvelu saatiin toimimaan ja se auttoi heitä säästämään rahaa. Palvelu ei kuitenkaan auta yritystä menestymään markkinoilla. Voidaan kysyä, onko suurella panostuksella toteutettu, hieman parempi versio vanhasta, menestys?
Selvittämällä kevyesti ja nopeasti ratkaisun tehokkuutta voi jo varhaisessa vaiheessa tehdä korjausliikkeitä. Rakentamalla kaikista arvokkaimmat toiminnot ensin, luodaan käyttäjille arvoa ja saadaan synnytettyä kassavirtaa. Samalla opitaan, miten palvelua on parasta kehittää jatkossa.
Jos olet kiinnostunut ketterästä, käyttälähtöisestä kehittämisestä:
