Toimialasta riippumatta on olemassa lukemattomia esimerkkejä järjestelmistä, joihin projektivaiheessa panostettiin kovasti resursseja mutta jotka kuitenkaan valmistuessaan eivät tästä huolimatta konkreettisesti vastanneet loppukäyttäjien ja liiketoiminnan tarpeisiin. Tällöin pahimmillaan voidaan havahtua tilanteeseen, jossa panostettiin merkittävä määrä resursseja projektiin, jonka lopputuloksena syntynyttä järjestelmää kukaan ei koskaan ala käyttämään. Syitä tähän voi olla lukuisia – ehkä projektin aikajana oli niin pitkä, että liiketoiminnan tarpeet ehtivät muuttua esimerkiksi toimintaympäristön muutoksen seurauksena? Ehkä virhe tehtiin jo siinä, että projektin vaatimukset asetettiin projektiryhmän toimesta back-office-tasolla vaikka todellisiin tarpeisiin vastatakseen olisi pitänyt osallistaa lähempänä asiakasrajapintaa työskenteleviä loppukäyttäjiä ympäri maailman? Ehkä loppukäyttäjiä olisi haluttu osallistaa, mutta ei tullut vastaan mielekästä keinoa?
Yllä kuvatun tilanteen välttämiseksi ja onnistuneen lopputuloksen saavuttamiseksi esittelen ohessa ohjelmistokehitysprojektin elinkaarelle asettuvan kolmivaiheisen mallin, jonka avulla loppukäyttäjiä voidaan osallistaa tehokkaasti läpi projektin. Lisäksi kuvailen, kuinka kustakin katselmoinnista tiivistettyjä lopputuloksia voidaan viiveettä huomioida ketterillä tavoilla (esim Scrum) kehitettävissä projekteissa – vieläpä verrattain myöhäisissäkin projektin vaiheissa!
Ensimmäisen vaiheen lopputuloksena syntyy tuotevisio joka määrittelee yhteisesti hyväksytyt odotukset lopputulokselle – realististen odotusten asettaminen on hyvin tärkeätä, sillä näitä odotuksia vasten loppukäyttäjät tulevat myöhemmin hyväksymään/hylkäämään kehitetyn järjestelmän. Projektitiimin näkökulmasta ensimmäisen vaiheen yhteydessä loppukäyttäijien tekemiä priorisointeja eri toiminnallisuuksista voidaan suoraan hyödyntää siten, että ne asettavat konkreettista tekemisen järjestystä projektille – kriittisimmät toiminnallisuudet tulee rakentaa ennen ”nice to have”-toimintoja. Lopuksi, projektitiimin kannattaa reagoida käyttöliittymäluonnosten saamaan palautteeseen tässä vaiheessa – alkuvaiheessahan on helppoa sopeutua muutoksiin kun koodia ei ole kirjoitettuna vielä riviäkään. Projektin aikajanan näkökulmasta tämä ensimmäinen vaihe tulisi suorittaa verrattain varhaisessa projektin vaiheessa.
Toisen vaiheen osalta lopputuloksena projektitiimin jäsenet saavat kuulla loppukäyttäjiltä vankan ja rehellisen mielipiteen siitä, onko kehitystyö mennyt ja menossa oikeaan suuntaan. Jos kehitystyön kohdistamisessa esiintyy huomautettavaa, niin tässä vaiheessa on vielä hyvä tilaisuus tehdä sopeutuksia suunnan korjaamiseksi. Ideana tämän toisen vaiheen kohdalla on se, että loppukäyttäjiä ei enää tässä vaiheessa pyydetä arvioimaan järjestelmän luonnoskuvia vaan sen sijaan loppukäyttäjät päästetään konkreettisesti testaamaan järjestelmän prototyyppiä, josta löytyy jo joitakin loppukäyttäjälle kriittisiä toimintoja. On luonnollista, että itse kokeilemalla saatetaan tässä vaiheessa tunnistaa paljon tärkeitäkin parannusideoita jotka aiemmin eivät kuvia katsellessa tulleet mieleen – nämä parannusideat tulee loppukäyttäjien toimesta arvottaa ja priorisoida. Kehitystiimin tulee huomioida ja toteuttaa näitä ideoita niissä rajoissa kuin on mahdollista (huomioiden siis projektin budjetti- ja aikataulurajoitteet). On lisäksi kuitenkin huomioitava, että nämä uudet ideat tulee arvottaa sisäisesti projektitiimin toimesta myöskin toteutettavuuden kannalta – jos pieni muutos aiheuttaa merkittävää refaktorointityötä, on ehkä järkevämpää kommunikoida kyseisen toiminnon mahdollisesti rakennettavan myöhempään järjestelmäversioon. Toisaalta idealistassa heti seuraavana oleva tärkeä idea saattaakin olla toteutettavuuden kannalta helppo viiden minuutin lisätyö!
Aikajanalla tämä toinen vaihe loppukäyttäjein osallistamisessa tulisi käynnistää kehitystyön puolivälin tienoilla.
Hyväksyntätestausvaiheessa aiemmissakin vaiheissa mukana olleet loppukäyttäjät kutsutaan koolle hyväksyntätestaamaan valmistuneen järjestelmän eri päätoiminnot. Lisäksi tässä vaiheessa arvioidaan liiketoimintaodotusten täyttymistä verraten valmistunutta tuotetta alkuvaiheessa asetettuja toiminnallisia odotuksia sekä visiota vasten. Hyväksyntätestaus huipentuu loppuäänestykseen, jossa loppukäyttäjät pääsevät äänestämään siitä, onko järjestelmä heidän mielestään ja testaushavaintojen perusteella valmis käyttöönotettavaksi. Tämän äänestyksen lopputulos määrittelee pitkälti projektin seuraavat vaiheet. Jos loppukäyttäjät hyväksyvät tuotteen, tällöin projekti on valmis etenemään seuraavaan vaiheeseen, joka on tyypillisesti pilotointivaihe tuotantoympäristössä. Jos projektilla on yritysjohdosta koostuva ohjausryhmä, tulisi erityisesti tämän kolmannen katselmoinnin lopputulokset toimittaa ohjausryhmälle, jolloin ohjausryhmä ottaa vastuun päätöksenteosta projektin etenemiseen liittyen.
Projektin elinkaaren näkökulmasta tämä viimeinen vaihe loppukäyttäjien osallistamisessa tulisi suorittaa siinä vaiheessa kun projektiryhmä kokee, että rakennettu toiminnallisuus vastaa projektin alkuvaiheessa asetettuja tavoitteita ja odotuksia tyydyttävissä määrin.
On selvää että esimerkin mukainen käytäntö loppukäyttäjien osallistamisessa laskee uusien toimintatapojen omaksumisen kynnyksiä ja kasvattaa loppukäyttäjien tyytyväisyyttä – parhaassa tapauksessa loppukäyttäjät hihkaisevat ilosta löytäessään järjestelmän käyttöliittymästä sellaisia nokkelia ratkaisuja, jotka he keksivät itse jonkin kolmen mainitun vaiheen kohdalla. Lyhyesti sanottuna tällaiset loppukäyttäjien osallistamiskäytännöt mahdollistavat sen, että vahvasti IT-orientoituneenkin projektin tekemistä ohjaa konkreettiset loppukäyttäjien/liiketoiminnan asettamat odotukset
Jotta ylläkuvatun kaltainen käytäntö loppukäyttäjien osallistamisessa saataisiin toimimaan, on toki syytä aivan aluksi tiedostaa se, ketkä ovat profiililtaan arvokkaimpia loppukäyttäjiä liiketoiminnan kannalta, joita erityisesti tulisi kuunnella – katselmointeihin tulee erityisesti kutsua sellaisia osallistujia, joiden työnkuvassa kehitettävä järjestelmä on merkittävässä roolissa. Sopivien loppukäyttäjien valikointi kannattaa siis tehdä huolella ennen kuin loppukäyttäjiä aletaan osallistamaan.
Haluatko tietää lisää Bisnesteknologiamallista ja sen soveltamisesta käytännössä? Ota yhteyttä.