Vaatimusmäärittelyn 5 ongelmaa ja yksi ratkaisu

Kun käy läpi vaikeuksiin ajautuneen projektin määrittelyä, niin kohtaa usein kaksi dokumenttia: 

  1. Vaatimusmäärittely Excel 
  2. Toimittajan tekemä määrittely, jossa kuvattu ohjelmistoon tehtävät muutokset.  

Se joka puuttuu, on dokumentti, jossa kuvataan selkeästi asiakkaan kriittiset prosessit sekä niiden kehittämistarve. Asiakkaalla ei ole ollut aikaa kuvata liiketoiminnalle kriittisen kehitysprojektin liiketoimintaa! Kuulostaa hieman hassulta, vai mitä? 

Vaatimusmäärittelyn ongelma 1 

Vaatimukset on kuvattu yleensä Exceliin, jossa niitä on useampi sata. Vaatimuksen kuvaukset ovat lyhyitä, sanamuodot hiottu jonkun ohjeistuksen mukaan.  

Ongelma: Toimittajan pitää ymmärtää yhden solun tekstin perusteella, mitä asiakas on tarkoittanut.
Näiden kuvausten perusteella toimittajalta pyydetään kiinteähintaista tarjousta ratkaisusta.  

Vaatimusmäärittelyn ongelma 2 

Lähes kaikki vaatimukset koetaan tärkeiksi, joten ne merkitään pakolliseksi ominaisuudeksi. Jos yksikin näistä pakollisista ominaisuuksista puuttuu, niin toimittajan tarjous hylätään.  

Ongelma: Jos toimittaja haluaa tarjota ratkaisua, heidän on pakko ymmärtää osa vaatimuksista ”väärin”. Koska ei auta, vaikka toimittajalla olisi tarjolla vaatimusta parempi ratkaisu. 

Vaatimusmäärittelyn ongelma 3  

Vaatimusmäärittelyn listauksen pohjana on usein nykyisten sovellusten ominaisuudet. Mietitään, mitä kaikkia toimintoja tällä hetkellä tehdään ja listataan ne. Vaikka tavoitteena olisikin digiloikan ottaminen, niin vaatimuksina listataan vanhan ohjelman toiminnot.  

Ongelma: Ohjelmistot kehittyvät koko ajan. Kokonaisia toimintoja saatetaan pystyä jättämään pois. Vanhan ohjelmiston toimintojen listaaminen ei tue nykyaikaisen ratkaisun totuttamista.  

Vaatimusmäärittelyn ongelma 4 

Kun tehdään talkoita listauksia, niin niistä jää aina puuttumaan jotain. Useamman sadan vaatimuksen listauksesta on vaikea huomata puuttuvat kohdat. Virheet löytyvät aika helposti, mutta puutteet ei.  

Ongelma:  Yleensä puuttuvat vaatimukset löytyvät testauksissa, jonka jälkeen ne toteutetaan erillisenä kehitystyönä.  

Vaatimusmäärittelyn ongelma 5 

Jotta toimittaja osaa toteuttaa ratkaisun, tehdään usein myös määrittelydokumentti toimittajan toimesta. Tähän dokumenttiin toimittajan konsultit kuvaavat haastattelujen perusteella ohjelman toimintoja. Usein kuvataan vain ohjelmiston muutokset ja konfiguraatiotarpeet, ei kokonaista lopputulosta. Vakiotoiminnallisuuksia ei kuvata, koska niitä ei tarvitse toteuttaa.  

Tästä aiheutuu kolme ongelmaa: 

  1. Jos asiakas ei tunne uutta ohjelmistoa hyvin, niin ratkaisun ymmärtäminen on vaikeaa. Varsinkin jos dokumentti on kirjoitettu ohjelmiston moduulien pohjalta, eikä asiakkaan liiketoiminnan mukaan.
  2. Määrittelydokumentin hyväksyntä on vaikeaa. Asiakas laitetaan hyväksymään dokumentti, jossa lopputulos ei ole kuvattuna.  
  3. Jokainen asia, joka tähän dokumenttiin unohdetaan kirjata, toteutetaan erillisesti veloitettavina kehitysehdotuksina.  

Yksi ratkaisu 

Yleinen sääntö on, että yrityksen liikevaihdosta 80 % tulee 20 % tapahtumista. Lisäksi on tiettyjä toimintoja, jotka ovat pakollisia, lainvaatimia. Täydellisen määrittelydokumentin kirjoittaminen on liian työlästä, mutta jos keskitytään määrittelyssä näiden liiketoimintojen kuvaamiseen, niin työmäärä helpottuu huomattavasti.  

Kun kyseessä on liiketoiminnalle kriittinen kehitysprojekti, niin silloin pitää kuvata kokonaiset liiketoiminnan prosessit. Kuvauksessa pitää keskittyä liiketoiminnan kuvaamiseen, ei nykyisen ratkaisun kuvaamiseen. Näin tuetaan digiloikan toteutumista ja kuvauksien tekeminen on paljon helpompaa.  

Hyödyt

  1. Kun asiakkaan kriittiset prosessit ovat kuvattuna, niin toimittajan on helpompi ymmärtää asiakkaan tarve. Toimittaja voi paremmin toteuttaa toimivan ratkaisun.  
  2. Kun kuvataan liiketoimintaa, niin määrittelijöiden on helpompi varmistaa, että välistä ei puutu paloja. Kaikki tärkeät toiminnot tulevat mukaan.  
  3. Määrittely kuvaa hyvin liiketoiminnan tarpeen, ne on helppo ymmärtää.   
  4. Jos tehdään myös vaatimusmäärittely-Excel, niin kaikkia toimintoja ei tarvitse merkata pakolliseksi. Annetaan toimittajalle mahdollisuus tarjota parempi ratkaisu.  
  5. Projektin aikaisten muutospyyntöjen määrä vähenee jopa 60%.  

ProjectTOP - Suomen kattavin alusta kehitykseen

Alusta projektien hallintaan ja kaikkeen kehitystyöhön yrityksille ja julkiselle sektorille.

Suosituimmat artikkelit