Kun ollaan hankkimassa tai jatkokehittämässä tietojärjestelmää, on järjestelmän vaatimusten kuvaaminen keskeisessä roolissa. Vaatimusten kuvaaminen esimerkiksi käyttötapausten muotoon on tapa kommunikoida liiketoiminnan tahtotilaa kehittäjälle. Käyttötapauksia käytetään hyväksymisen ja testauksen lähtökohtana, ja toimittajalle ne toimivat usein myös hinnoittelun perusteena. Käyttöönotto- ja jatkokehitysprojektien backlog eli tehtävälista rakentuu vaatimuksista. Mutta miten vaatimukset kannattaisi kuvata? Ja kuinka onnistua ketterässä kehityksessä?
Jaan tässä kirjoituksessa muutamia päähavaintoja vaatimusten määrittelyyn liittyen sekä toimittajan että tilaajan puolella työskentelystä ammentaen.
Tarkka vaatimus, paras vaatimus! Vai onko?
IT-palveluntuottajien leivissä ollessa tehtiin tietysti omaa bisnestä. Monesti projekteja myydään alalla ns. sopuhintaan (joskus myös alihintaan), ja kate revitään käytännössä muutoshallinnan, lisenssien ja jatkokehityksen kautta. Projekteissa tuntui käyvän niin, että jos tilaaja oli kuvannut järjestelmän haluttua toimintaa piirun tarkkaan (jopa järjestelmän nappien värejä myöten), pääsi muutoshallinnan keinoin naplaamaan aika paljon rahaa. Aina löytyi vaatimuksia, joita ei ollut kuvattu riittävän tarkasti – ei, vaikka vaatimus-excelissä oli jopa 1000 riviä.
Taas niissä tapauksissa, kun asiakas oli kuvannut ylemmän tason liiketoiminnan tarpeita ja käyttäjien tarpeita, oli muutoshallintahaukan paljon hankalampi päästä projektiin rahamielessä väliin.
Otetaan esimerkiksi loma-anomuksen tekeminen ja siinä lomapäivien riittävyyden tarkastaminen.
Kuvaustapa 1: Asiakas kuvaa yksityiskohtaisesti miten lomapäivien riittävyys lasketaan (laskentasäännöt).
Kuvaustapa 2: Asiakas kuvaa vaatimuksena, että loma-anomuksen tekijän pitää heti loma-anomusta tehdessään saada tieto lomapäivien riittävyydestä.
Järjestelmämielessä lomapäivälaskenta pystytään helposti toteuttamaan. Henkilöstön näkökulmasta on kuitenkin hyvin suuri ero siinä, tuleeko tieto siitä, etteivät lomapäivät riittäneetkään heti loma-anomusta tehtäessä, vai vasta sitten kun anomus on mennyt sutjakkaasti HR-järjestelmän koneistosta läpi, tieto siirretty palkkajärjestelmään ja vasta siellä tuleekin havainto, että asiassa onkin ongelma. Pahimmassa tapauksessa työntekijä on loma-anomuksen hyväksymisilmoituksen saatuaan ostanut lennot ja varannut majoituksen lomakohteesta, ja sitten alkaakin setviminen, joka harmittaa ja työllistää monessa portaassa ja aiheuttaa pahimmillaan ylimääräisiä kustannuksia työntekijälle ja työnantajalle.
Kannustan siis kaikkia vaatimusten kirjaajia pohtimaan vaatimusta tekemisen näkökulmasta. En väitä, että sääntöjen kuvaaminen olisi turhaa, mutta perimmäisiä tavoitteita ja tarpeita ei saa unohtaa.
Mikä on se hyöty, jonka käyttäjä saa – mikä hänen tarpeensa on?
Ketterä kehitys on pop, mitä se edellyttää onnistuakseen?
Ketterä kehitys toimii, jos a) kehitysresurssit ovat varattuna liiketoiminnan tarpeiden toteuttamiseen ja b) liiketoiminta kykenee kuvaamaan tavoitteensa ja tarpeensa kehitystiimille selkeästi ja ajallaan. Kun tilaaja ja toimittaja ovat tulleet tutuiksi ja yhteistä tekemistä on tuloksekkaasti harjoiteltu jo jonkin aikaa, pääsee ketterä tekeminen oikeuksiinsa.
Ketterä kehitys on kärsivällisyyslaji, jossa harjoitus tekee mestarin.
Voidaan sopia esimerkiksi mallista, jossa tietty tiimi on käytettävissä jatkokehitykseen tietyllä panoksella, vaikkapa 50% työajasta. Tilaajan tehtävä on varmistaa, että backlogissa eli tehtävälistalla on valmisteltua tekemistä tiimille toteutettavaksi. Sprinttimallisella työllä varmistetaan ymmärrys tarpeesta ja toteutustapa tarkentuvat, ja tilaajan henkilöstölle esitetään konkreettisia tuloksia säännöllisin väliajoin.
Lyhyen syklin tekemisen lisäksi on käytävä keskustelua tavoitteista ja mahdollisuuksista myös pidemmällä aikavälillä, jotta toimittajalle hahmottuvat suunta ja isommat tavoitteet. Näiden ymmärtäminen vaikuttaa monesti valittuihin toteutustapoihin myös lyhyellä aikavälillä – eihän haluta rajata pois jotain mitä jatkossa pitää ottaa huomioon. Eikä ainakaan haluta heti äskettäin toteutettua värkätä uudelleen vähän eri tavalla, koska valittu toteutustapa sulki pois jotain, mitä seuraavaksi tarvitaankin.
Ketterä kehitys ei ota onnistuakseen, jos resurssien saatavuudessa on vaikeuksia, liiketoiminta ei huolehdi siitä, että backlogissa on jatkuvasti järkevää tekemistä tai jos kehitystiimissä ei ole uskallusta ja kiinnostusta jankata asiaa niin kauan, että liiketoiminnan tarve on ymmärretty.
Ketterä kehitys on yhteispeliä. Jos se ei toimi, ei koskaan ole yhtä syyllistä ja yhtä syytöntä.
Tilaajalla oltava yksimielisyys siitä mitä halutaan tuloksena syntyvän
Varsinkin suuremmissa organisaatioissa yhteinen näkemys vaatii neuvotteluita, kompromisseja ja päätöksiä. Tilaajan vastuuhenkilön tärkeimpiä tehtäviä onkin esikäsitellä sisäiset ristiriidat toimittajan suuntaan selkeiksi suuntaviivoiksi. Tämä tehostaa ja helpottaa yhteistyötä, kun toimittajan ei tarvitse toimia keskenään erilaisia agendoja ajavien tilaajien erotuomarina.
Kaikkein kalleimmaksi tilaajalle koituu, jos ensin ei ole muodostettu näkemystä siitä, millaisiin tarpeisiin tietojärjestelmän tulee vastata ja etenkin siitä, mitä tuloksina halutaan syntyvän. Mitä uutta tekemisessä tulee mahdollistua ja miten toiminnan halutaan muuttuvan nykyiseen verrattuna?
Tietojärjestelmäprojekti on mahdollistaja. Tietojärjestelmäprojekti ei koskaan ole lähtökohta ja tavoite itsessään.
Merja Roponen
Ratkaisija, osakas