Een developer is geen actuaris

Submitted by admin on Tue, 12/18/2018 - 09:59

"Kun je garanderen dat de software over 6 maanden af is?"

Een garantie geven kan altijd.

Garanties zijn belangrijk voor de economie, ze leveren stabiliteit. Zijn garanties ook belangrijk bij de planning van softwareontwikkeling?

Futures

Op de beurs kun je opties en futures kopen. Dit zijn zogenaamde "garantiecontracten". Deze contracten geven zekerheid op de prijs en datum dat een product wordt geleverd. Je kunt zelf de garantie op mooi weer kopen. Garanties op mooi weer, dat kan toch helemaal niet, want daar heeft niemand invloed op. Precies, en toch kun je mooi weer garanderen. Hoe dan? Dat vertel ik zo.

Garantie op een product

Bij de aanschaf op een product met een hoge prijs krijg je vaak garantie. De garantie is dat het product niet stuk gaat binnen een bepaalde period. En dat vinden we normaal. Maar wat is precies het verschil met die garantie op mooi weer? Nou, in beide gevallen moet de verkoper (een deel van) de schade vergoeden. Een garantie is dus niets meer dan een financiële zekerheid. De partij die de garantie biedt (bij verlengde garantie is dat bijna nooit de leverancier) berekend vooraf wat de risico's zijn bij het verlenen van de garantie. Als 1 op de 1000 TV's binnen 1 jaar stuk gaan, dan zijn de kosten voor de garantie van 1 jaar 1/1000 * kostprijs van de TV (nog geen euro in veel gevallen). Als je goed het weer kunt voorspellen, dan kun je dus ook berekenen hoeveel de garantie voor mooi weer moet kosten. Bij slecht weer krijg je het geld van de vakantie weer terug. Is de kans op slecht weer 5%, dan zal de garantie op mooi weer minimaal 5% van de vakantieprijs kosten.

Garanties op een IT project

Bij veel IT projecten wordt er door de opdrachtgever een garantie gevraagd. Ofwel een garantie op de prijs een garantie op de leverdatum of beide. Het bijzondere aan deze 'IT garantiecontracten' is dat ze niets mogen kosten!

Er is ook geen bedrijf dat een garantieproduct zou willen leveren voor een IT project. Dat komt omdat het zo goed als onmogelijk is om de risico's te berekenen voor vertraging in de levering. Om te beginnen is het vooraf vaak niet duidelijk wat er gemaakt dient te worden en het is niet duidelijk wat het precies waard (in euro's) zal zijn als het is opgeleverd. Dus zowel de inkoopprijs als de verkoopprijs zijn niet bekend bij de start van het IT project.

Risico bepaling. Advies kost geld

Stel dat we een bedrijf vragen om een IT project Future af te geven. De leverancier van het IT project heeft dan de garantie op afname voor een vaste prijs en de afnemer heeft de garantie van levering voor een vaste prijs. De investeerder die de Future afgeeft zal dan het risico van het project moeten kunnen bepalen. Hiervoor zou de investeerder een adviesbedrijf met kennis van IT kunnen inschakelen. Uiteraard zijn daar kosten aan verbonden en zal de gevraagde garantie minimaal gelijk zijn aan de kosten voor het adviesbedrijf.

Is het opgeleverd? Testen kost geld

Maar wie gaat nu bepalen dat er geleverd is? Bij een fysiek product (graan, gas, olie) is de levering eenvoudig te bepalen: als het op de stoep ligt dan is het geleverd. Maar wat is er geleverd volgens de afgesproken kwaliteit? Het gaat om commodities en de markt heeft standaarden ontwikkeld om de kwaliteit te bepalen. Bij software zijn er geen marktstandaarden om de kwaliteit te meten. Om te beginnen moet goed zijn vastgesteld wat de overeengekomen kwaliteitsnorm is. Laten we aannemen dat deze norm is vastgelegd als onderdeel van de calculatie van het risico door het adviesbedrijf. Een onafhankelijk bedrijf zou dan kunnen testen of er volgens deze norm is geleverd. De term onafhankelijk is hier cruciaal. Dit bedrijf dat gaat testen (er zijn gespecialiseerder IT test bedrijven) moet ook worden betaald. En in de regel geldt: "Wie betaald die bepaald." En logischerwijze zijn de kosten van het IT testbedrijf ook onderdeel van de kosten voor de garantie.

Hoe kan het dan dat deze IT garanties wel worden afgegeven? 

De garanties worden meestal gegeven met in het achterhoofd dat toch niemand kan bepalen of een project is opgeleverd volgens afspraken op tijd en budget. De opdrachtgever past vaak de specificaties aan en een groot IT bedrijf heeft een leger aan juristen in dienst die de contracten zo opstellen dat bij een minimale verstoring de verplichting tot garanties vervallen.

Zijn garanties altijd nodig? 

Bij moderne IT ontwikkeling wordt er minder gericht op de garantie van levering. Er wordt vooral gericht op het zo snel mogelijk leveren van meerwaarde. Het maken van garanties kost tijd. Als het IT developers zijn die deze garanties moeten opstellen, dan is het veelal efficiënter om de developer code te laten schrijven.

Een developer is geen actuaris

De developer is uitgekozen vanwege de getoonde development skills en niet vanwege de 'garantievaardigheid'. Als een developer bezig is met het opstellen van een garantie, dan kan deze developer geen code schrijven. Dus als je een developer vraagt om een planning te maken (dit is het opstellen van een garantie) dan is de kwaliteit laag en de developer heeft deze tijd niet kunnen gebruiken om code te schrijven. Twee keer pech!  Het waarde verschil tussen een IT garantie en werkende code is vrij groot. Het is allebei tekst, alleen aan een IT garantie kan niet worden verdiend. Bij productontwikkeling is het verschil nog duidelijker. Het resultaat van het werk (een programma) is verhandelbaar, het IT garantiecontract niet. Dat is dan ook een belangrijke reden waarom een Agile/Scrum aanpak zo goed werkt bij productontwikkeling.