Kun kehitysprojektissa alkaa määrittelyvaihe, tilanne on usein tämä: Asiakkaan projektiryhmä, eli liiketoiminnan edustajat, tuntevat hyvin oman osa-alueensa toiminnan, mutta eivät uutta ohjelmistoa. Toimittajan konsulteilla on toimialaosaamista, mutta he eivät tunne asiakkaan prosesseja.
Johto on asettanut ehdon: ”Olemme ostaneet valmisohjelmiston, joka otetaan käyttöön vakiotoiminnoin. Kaikkea räätälöintiä vältettävä.”

Määrittely toteutetaan siten, että järjestetään muutama iso määrittelypalaveri, jossa konsultti haastattelee liiketoiminnan asiantuntijoita ja kirjaa asiat ylös. Toteutetaan mahdollisimman kevyt määrittely, jotta vältettäisiin ylimääräiset muutospyynnöt.

Kun näin toimitaan, lopputuloksena syntyy tyypillisesti yksi iso, jopa 300-sivuinen opus. Opukseen on kuvattu järjestelmään tehtävät konfiguraatiot ja asetukset. Toimintoja on kuvattu juuri sen verran, että koodarit osaavat tehdä työnsä, ei yhtään enempää. Avoimet asiat ovat kivasti punaisella tekstillä. Räätälöintien tarpeet ovat kirjattuna jossain omassa Excelissään.

Kuulostaako tutulta?

Perinteisen ”määrittelyopuksen” isoimmat ongelmat ovat:

1. Projektiryhmälle ei synny selkeää kuvaa rakennettavasta ratkaisusta, koska vakiotoiminnallisuuksia ei kuvata määrittelydokumentissa.
2. Määrittelyn hyväksyntä on vaikeaa. Se ei ole koskaan 100% valmis, eikä määrittelyssä ei kuvata projektin lopputulosta.
3. Todelliset räätälöintitarpeet löydetään vasta testausvaiheessa. Räätälöintien suuri määrä yllättää ja niistä ihan pakolliset toteutetaan kiireellä ja kalliisti.
4. Kaikki asiat, jotka toimittaja ”unohtaa” kirjoittaa määrittelydokumenttiin, ja jotka menevät läpi tarkastuksen, tuottavat muutospyyntöjä projektille.

Projekti alkaa heti ensi metreiltä mennä metsään!

Fiksusti tehty määrittely vähentää projektin aikaisia muutospyyntöjä noin 60%? Tämä tarkoittaa tuhansien Eurojen säästöä.

Käyttötapauksilla projektista saadaan laadukas ja johdettava

Määrittely on mahdollista toteuttaa nykyaikaisestikin. Siten, että sekä asiakas pystyy kertomaan liiketoiminnan tarpeen ja toimittaja pystyy toteuttamaan liiketoimintaan soveltuvan ratkaisun.

• Pilkotaan määrittelyopus käyttötapauksiksi. Suunnitellaan, kuinka kukin käyttötapaus määritellään.
• Kuvataan käyttötapauksiin toiminnon kannalta tarpeellinen, eli prosessi, toiminnallisuus ja rakennettava ratkaisu. Näin määrittelyn valmiusasteesta saadaan reaaliaikainen kuva, kun tiedetään, että toiminto on loppuun asti määritelty.
• Käyttötapaukset on helppo hyväksyä, koska niissä on kuvattu selkeästi ratkaisun lopputulos, ei vain osia siitä.
• Käyttötapaukset luovat pohjan kehitysprojektin reaaliaikaiselle raportoinnille ja johtamiselle.

Tässä postauksessa en ehdi paneutumaan käyttötapauksien rakenteeseen, enkä luontiprosessin syvemmin, mutta tule mukaan Quality Gate Best Practice- mallin koulutuswebinaariin.
Koulutuksen jälkeen tiedät, miten käyttötapauksia hyödyntämällä kehitysprojektin toteutusvaihe saadaan toimimaan saumattomasti. Ja projektin aikaiset muutospyynnöt vähenevät 60%!

Lue lisää ja ilmoittaudu Quality Gate Best Practice -mallin koulutuswebinaariin!