HomeOntwikkeling ❱ Gefrustreerd over je software beheer? Fix het!

Gefrustreerd over je software beheer? Fix het!

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 wordt VAART benaderd door opdrachtgevers die midden in een project zitten. De aanleiding is ontevredenheid over de manier waarop het project loopt. Meestal door frustraties als:

  1. er blijven maar bugs naar boven komen
  2. de urenmeter gaat aan voor alles
  3. 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.

Auteur(s): Jorrit

Meer rendement uit maatwerk software met technisch advies en begeleiding. Neem contact op

Maatwerk software 

Advies & begeleiding


030 320 0450

VAART software
Kanaalweg 18-G Utrecht
KvK 30187211

Privacyverklaring

Maatwerk software advies in je mailbox: