Näin onnistut ohjelmistohankkeessa – 4 vinkkiä
Jokaisesssa teknologiainvestoinnissa on tärkeintä tehdä oikeita asioita. Jos perimmäistä tarvetta ei ymmärretä, projekti epäonnistuu takuuvarmasti.
Usein tietojärjestelmiä hankittaessa huomataan pian käyttöönoton jälkeen, että hartaasti odotettu ja paljon maksanut ohjelmisto ei ratkaisekaan kaikkia niitä ongelmia, joita varten se hankittiin. Tämä on kaikkein fataalein virhe ohjelmistohankinnoissa.
Yritys on investoinut uuteen ohjelmistoon paljon aikaa ja rahaa, mutta ongelma on edelleen olemassa ja yritys on yhä lähtöpisteessä – nyt vain entistä köyhempänä. Tällä välin kilpailijat ovat repineet hurjasti etumatkaa.
1. Yhteistyö voittaa siilot
Onnistumisen kannalta olennaista on ottaa kaikki sidosryhmät alusta asti mukaan hankkeen suunnitteluun. Näitä sidosryhmiä ovat liiketoiminnan edustajat (eli ohjelmiston hankkiva taho), loppukäyttäjät (hankkivan tahon työntekijät ja/tai asiakkaat) sekä toteutustiimi (joko oma tai toimittajan).
Jos jokin edellä mainituista sidosryhmistä jätetään syystä tai toisesta pois keskusteluista, syntyy ongelmia:
Jos liiketoiminta ja toteutustiimi käyvät keskusteluja ilman loppukäyttäjää, syntyy ohjelmisto, jota ei haluta käyttää. Tällöin siltä on turha odottaa myöskään tuottoa tai säästöjä.
Jos toteutustiimi ja loppukäyttäjät käyvät keskusteluja ilman liiketoimintaa, syntyy ohjelmisto, jota halutaan kyllä käyttää, mutta joka ei tuo bisneshyötyä.
Jos liiketoiminta ja loppukäyttäjät keskustelevat keskenään ja jättävät toteutustiimin ulkopuolelle, ohjelmistosta ei tule sellainen kuin oli tarkoitus.
Paras lopputulos syntyy, kun liiketoiminnan edustajat, loppukäyttäjät ja
koodarit ovat kaikki mukana hankkeessa. Sweet!
2. Kirkasta ongelma
Kun oikeat sidosryhmät on sitoutettu hankkeeseen mukaan, on löydettävä oikea ongelma. Monesti arkielämässä näkyvät haasteet ovat vain seurausta jostain paljon syvemmällä piilevästä epäkohdasta. Näin ollen on tärkeää vastustaa ensimmäistä intuitiota ja pohtia tarpeita syvällisemmin.
Parhaat tulokset saavutetaan analyyttisella ja systemaattisella lähestymistavalla. Tässä voi käyttää apuna voi esimerkiksi Lean Canvasia, joka on muokattu versio Business Model Canvasista. Lean Canvas keskittyy nimenomaan ongelmaan ja sen ratkaisemiseen.
3. Oletusten validointi
Liiketoiminnan haasteet ovat hyvin kompleksisia, ja niihin liittyy paljon riippuvaisuuksia. Paraskaan analyysi ei kata kaikkia eteen tulevia tilanteita, minkä vuoksi joudutaan tekemään lukuisia – enemmän tai vähemmän valistuneita – oletuksia.
Tämän vuoksi ongelmaa ei kannata lähteä ratkaisemaan yhdellä kertaa, sillä jotkut oletuksista saattavat osoittautua virheellisiksi. Näin ollen on äärimmäisen tärkeää pyrkiä validoimaan tärkeimpien oletusten paikkansapitävyys mahdollisimman nopeasti ja halvalla. Usein tämä onnistuu ilman ohjelmiston rakentamista.
Ratkaisu liiketoimintaongelmaan voi olla esimerkiksi uuden kuluttajille suunnatun verkkopalvelun rakentaminen. Tässä tärkein oletus lienee, että kuluttajat ovat valmiita käyttämään kyseistä palvelua. Verkkopalvelun toteuttamisen sijaan oletusta voidaan testata esimerkiksi haastattelemalla kuluttajia ja kysymällä mielipiteitä palvelun tarpeellisuudesta.
Mikäli palaute on pääosin negatiivista, ongelmaa ja sen ratkaisua lienee syytä pohtia uudelleen. Jos taas vastaanotto on innostunutta, voidaan siirtyä testaamaan seuraavaa oletusta.
4. MVP-, eli Minimum Viable Product
Kun kaikki ei-ohjelmallisesti testattavat oletukset on validoitu ja ratkaisumalli vaikuttaa edelleen hyvältä, on aika ryhtyä itse ohjelmiston toteutukseen. Ohjelmistoa ei kuitenkaan kannata rakentaa yhtenä isona könttinä, vaan vaiheittain pienissä osissa sekä jatkuvasti palautetta ja oppia keräten.
Nopean palautteen ja käyttökokemuksen saamiseksi on tärkeää julkaista ohjelmisto riittävän nopeasti oikeaan käyttöön. Tässä vaiheessa ohjelmistosta voi puuttua paljon ominaisuuksia, mutta tärkeimpien toimintojen olisi syytä olla käytettävissä. Aluksi myös käyttäjäryhmä voi olla rajatumpi, jotta mahdollisten ongelmien vaikutus jää sopivan pieneen piiriin.
Tämä ns MVP-malli (Minimum Viable Product) mahdollistaa oikeiden käyttökokemusten ja palautteen saamisen ohjelmistosta mahdollisimman nopeasti ja halvalla. Näiden kokemusten avulla voidaan tehdä tietoon perustuvia päätöksiä, kannattaako projektia jatkaa ja mihin osa-alueisiin panoksia kannattaisi suunnata.