HomeBlog ❱ Software beheer en onderhoud: een best practice

Software beheer en onderhoud: een best practice

Door samen de 'beheer' fase van je software beter te begroten, voorkom je bugs, onverwachte kosten en een grillig release schema.

Jorrit Venema door Jorrit - leestijd 4 minuten

Onze software planner

Onze software planner waarin we nieuwe features en versies plannen

Regelmatig krijg ik de vraag of VAART ook een bestaand software project "in beheer" kan nemen. De aanleiding is ontevredenheid over de manier waarop het project nu loopt, met frustraties zoals:

  1. "er zitten nog steeds bugs in"
  2. "de urenmeter gaat aan voor alles"
  3. "we moeten lang wachten op wijzigingen"

Voordat je denkt dat dit een marketing-achtig wij-zij verhaaltje wordt: ook onze software bevat bugs (referenties op aanvraag ;)), wij werken niet gratis en we halen niet elke planning.

Deze post gaat over iets anders. Al dit soort frustraties hebben namelijk één en dezelfde oorzaak. En voordat een project begint, kun je ze prima voorkomen.

De meeste frustraties over software beheer worden veroorzaakt door een slechte begroting.

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 dit onderschatten.

"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 een betere vorm heb ik nog niet gevonden, wel mee geëxperimenteerd.)

"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.

In mijn ervaring kan het helpen als eigenaar en ontwikkelaar de overlap in hun prioriteiten proberen te vinden. Die is er zeker.

Eigenaar en ontwikkelaar zijn beide gebaat bij een ritme en regelmaat in releases, bij een efficiënte tijdsbesteding, bij werk dat 'behapbaar' is, zowel om te bouwen als om te testen.

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.

Zo begroot je je software project beter

Veel frustratie kun je dus voorkomen door je project vooraf anders te begroten, samen met je ontwikkelaar. Maar heb je dan meer geld nodig? Nee. Hoe werkt het dan?

Ik denk ten eerste dat het woord "beheer" een groot aandeel heeft in de onderschatting die dit werk zo vaak ten deel valt.

"Beheer" suggereert een soort passiviteit, een status quo. Daardoor zie je mentaal de ontwikkeling als het project en beheer als iets dat daarna komt.

Maar dit is geen realistische benadering van je software project - zo scheid je twee dingen die onlosmakelijk verbonden zijn.

Het is onmogelijk om je software in één keer volledig goed te ontwerpen en bouwen, en zelfs onverstandig om dat te proberen (lees ook de grootste valkuil van maatwerk software).

Software ontwikkeling fasen

De drie fasen van software ontwikkeling

Laat de term "beheer" eens los en noem het vanaf nu "optimalisatie". Dat is een veel actiever woord dat ook nog eens veel beter past bij de doelstelling.

Ontwikkeling en optimalisatie zijn beide fasen in één project. Door het zo te benaderen, voelt het logisch om beide fasen ook afzonderlijk te budgetteren.

Hierboven zie je onze gouden driehoek van software ontwikkeling met de drie fasen in elk project. Je begint in de strategiefase en kent budgetten toe aan ontwikkeling en optimalisatie.

Als wij een budgetplanning maken dan hanteren we de volgende verhouding:

ontwikkeling:optimalisatie | 3:4 - oftewel met een budget van € 70K reserveer je € 40K voor de optimalisatiefase.

"Dan reserveer je minder dan de helft voor de ontwikkeling!" Hoor ik je denken. En dat klopt. De ontwikkeling richt je op het MVP. En dat wil je zo klein en eenvoudig mogelijk houden.

Vergeet niet: hoe sneller je live gaat, hoe beter. De ontwikkeling duurt ook het kortst, en optimalisatie duurt veel langer, eigenlijk de gehele levensduur van je software.

Gemiddeld nemen wij voor de optimalisatie twee jaar. De werkelijke verhouding is dan 3:2:2 | ontwikkeling : optimalisatie j1 : optimalisatie j2.

Budgetteren voor optimalisatie hoeft dus ook helemaal niet te betekenen dat je in totaal meer geld nodig hebt. Je verschuift de focus en kunt als het goed is je budget voor ontwikkeling kleiner maken.

Sterker nog, ik voorspel een grote kans dat je uiteindelijk goedkoper uit bent én ook nog beter software in handen hebt.

Ga jij aan de slag met de tips in dit artikel? Deel je bevindingen of je vragen aan mij in de reacties hieronder.

Reacties