Alle requirements waren toch duidelijk! Waarom is het product dan toch niet goed ontwikkeld en is het zo duur uitgevallen?!

Is het bovenstaande herkenbaar? Het gebeurt helaas vaak in de IT wereld dat softwareontwikkeling vaak duur uitvalt, maar hoe komt dit eigenlijk?

Lees het onderstaande whatsapp bericht.

Alle requirements waren toch duidelijk! Waarom is het product dan toch niet goed ontwikkeld en is het zo duur uitgevallen?!

Wat voor een huis verwacht u na 3 maanden bij het lezen van de conversatie?

De kans is groot dat iedereen een ander huis voor ogen heeft.

Als u een huis gaat bouwen, dan verloopt het (hopelijk) niet zo.

U gaat eerst met een architect zitten om u wensen uit te spreken. Het budget wordt vastgesteld. De architect maakt schetsen van u wens, u geeft hierop terugkoppeling en via verschillende terugkoppel rondes worden de schetsen steeds verder uitgewerkt tot een bouwtekening.

Pas als u het eens bent met de bouwtekening, dan wordt er gebouwd.

Bij het maken van software wordt nog helaas te vaak uitgaan van alleen uitgeschreven requirements. Dit is veelal de oorzaak van waarom software ontwikkeling (vaak) duurder uitvalt.

Om te begrijpen waarom het vaak duurder uitvalt blijven wij bij de analogie van het bouwen van een huis:

U hebt opgegeven een huis met 5 deuren, 10 ramen en er moeten 7 mensen in. De bouwer begint ijverig een fundering te storten zodat het huis erop gebouwd kan worden.

U bent vergeten te vermelden dat de 7 mensen allen een eigen kamer nodig hebben. U geeft dit aan bij de bouwer. Geen probleem, hij zal zorgen dat er 7 kamers zijn. Tegen meerprijs worden extra muren gebouwd. Jammer, maar u hebt namelijk te laat verteld dat iedereen een eigen kamer nodig had.

De bouwer trekt de muren verder op en het huis heeft in totaal 5 deuren. Sommige kamers hebben 2 ramen maar ieder kamer heeft minimaal 1 raam, in totaal 10 ramen. In het huis kunnen 7 mensen in wonen met ieder een eigen kamer.

Volgens de eisen is het huis af!

U inspecteert het huis en komt tot de volgende punten:

  • Sommige deuren zijn 2 keer zo breed zijn. Dit was volgens de bouwer nodig zodat alle kamers te betreden zijn. Dit was niet volgens uw verwachting?
  • Sommige kamers zijn heel klein. Dit was volgens omdat de fundering en de muren al opgetrokken waren. Toen u aangaf dat iedereen een eigen kamer nodig had, moesten sommige kamers in 2 moest gedeeld worden.

U wilt grotere kamers en alle kamers hebben hun eigen deur nodig. Dit betekent echter dat de bouwer extra fundering moet bijstorten en kamers moet slopen om het opnieuw te bouwen. Hierdoor gaan de kosten nog meer omhoog en duurt het project vaak langer

Enfin, ik kan het verhaal nog langer maken maar de oorzaken voor de extra kosten in dit verhaalt gebeuren vaak, deze zijn in het bovenstaande voorbeeld:

  • Foute aannames. U nam aan dat met 5 deuren alle kamers betreden konden worden. De bouwer nam aan dat u het geen probleem vond dat de deuren 2x zo breed werden om alle kamers toegankelijk te maken.
  • Voortschrijdend inzicht, achteraf worden dingen pas duidelijk. Een huis met 5 deuren kan geen 7 kamers hebben die allen toegankelijk zijn met een eigen deur.
  • Requirements (eisen) kunnen vaak vergeten worden. De redenen liggen vaak uiteen.

Uiteindelijk is het aanpassen achteraf altijd duurder. Aanpassen van eenmaal gestorte funderingen en muren kost veel tijd en arbeid.

Bouwtekening = Klikbare designs

Aannames en voortschrijdend inzicht kunnen grotendeels voorkomen worden door een goede bouwtekening te maken. Dit geldt bij Software ontwikkeling ook. Door het maken van schetsen met pen en papier en hierna klikbare protypes kan veel van uw eisen een aannames getoetst worden.

Bij Madlogic werken wij altijd met ‘bouwtekeningen’ alvorens een regel code geschreven wordt. Want niemand heeft er baat bij het aanpassen van funderingen achteraf…