Frustraties over bugs, uurtje factuurtje en lange wachttijden bij software beheer zijn geen uitzondering. Als opdrachtgever speel je misschien een belangrijkere rol dan je denkt.
Regelmatig word ik benaderd door opdrachtgevers die midden in een project zitten. Ze zijn hoogst ontevreden over hoe het project loopt.
Meestal spuien ze frustraties als:
- er blijven maar bugs naar boven komen
- de urenmeter gaat aan voor alles
- we moeten lang wachten op wijzigingen
Het is misschien niet leuk om te horen, maar dit soort frustraties hebben vaak één oorzaak: onjuiste of naïeve budgettering.
En daarin speel je als opdrachtgever een belangrijke rol.
Laten we de drie voorbeelden eens nader bekijken:
“Er zitten nog steeds bugs in”.
Helaas maar waar: elke broncode(-wijziging) bevat bugs. Zaak is dat je maatregelen neemt om ze a) zoveel mogelijk te voorkomen en b) te traceren en verhelpen voordat de software “live” gaat.
Dat kan alleen door gestructureerd testen deel uit te laten maken van de ontwikkeling van je software.
Dit doe je meestal op twee manieren: technisch (geautomatiseerd, door de ontwikkelaar) en functioneel (geautomatiseerd of handmatig, door de ontwikkelaar en de eigenaar).
De vaststelling dat software na lange tijd “nog steeds bugs bevat” is meestal een signaal dat testen geen (voldoende) aandacht kreeg tijdens de begroting van een applicatie, versie of feature.
Ik bedoel hiermee niet dat de eigenaar verantwoordelijk is om bugs uit de software te halen! Test- en herstelwerk moet vooral structureel zijn opgenomen in de begroting.
Het zijn meestal ontwikkelaar en eigenaar samen die het belang van testen onderschatten of negeren.
“De urenmeter gaat aan voor alles”.
Vaak blijkt: een eigenaar is bereid te betalen voor uitbreidingen, maar verwacht dat bugs kosteloos worden verholpen voor rekening van de ontwikkelaar.
Dat is vooral het geval wanneer de software al in productie is genomen, waardoor het gevoel ontstaat dat “er voor betaald is”.
De meeste software wordt echter ontwikkeld op basis van een uurtarief, en dan is dit gevoel in de basis niet terecht.
Het herstellen van bugs kost ook tijd, of het nu voor of na livegang gebeurt. Dit testwerk moet natuurlijk wel realistisch begroot worden (zie vorige punt).
(Deze wrijving is trouwens de reden dat ik software ontwikkeling als dienst niet goed vind passen bij het uurtarief als prijsvorm. Maar elke vorm heeft zo z’n nadelen… ook fixed-price.)
“We moeten lang wachten op wijzigingen”
Dit heeft te maken met prioriteit.
Als eigenaar wil je graag snel inspringen op feedback en nieuwe inzichten. Voor software ontwikkelaars blijft het een puzzel om relatief klein werk te plannen tussen nieuwbouw werk dat vaak een fulltime claim doet op de developers.
Het helpt enorm als opdrachtgever en ontwikkelaar de overlap in hun prioriteiten proberen te vinden. Die is er zeker. Je bent namelijk beide gebaat bij:
- een efficiënte tijdsbesteding
- ontwikkel- en testwerk dat ‘behapbaar’ is
- ritme en regelmaat in releases
Om dit te bereiken kun je een constructie afspreken waarin deze overlap voor jullie allebei goed naar voren komt.
Ook hier is het instrument budgettering: door een vast ritme in te plannen, koppel je een gereserveerd budget aan een gegarandeerde inspanning van de ontwikkelaar.
Dit wordt meestal gedaan met een onderhoudsovereenkomst of een strippenkaart constructie. Dat kost geld en het kan behoorlijk bindend aanvoelen.
Maar het is wel dé manier om met geplande regelmaat samen te werken aan kleine blokjes werk.
Door klein werk te bundelen, besteed je je budget het meest efficiënt.