Reading time: 3 minutes
Author:
Hergebruik is een hot topic. Het management kan er die enorme investeringen in software mee terugverdienen. Voor techneuten is het geweldig om componenten zo generiek mogelijk te maken dat ze voorbereid zijn om opnieuw te worden gebruikt.
Het is absoluut van bedrijfsbelang om niet voor ieder project opnieuw alles uit de grond te moeten stampen. Vaak begint het wel zo in startende bedrijven. Soms groeien die door naar echte projectorganisaties, waarbij engineers op een specifiek project zitten. Dit geeft 100 procent focus op dat project, wat zich vertaalt in de mogelijkheid om snel te reageren op klantwensen. Die snelheid maakt de club ook onderscheidend ten opzichte van concurrenten. Doorstomend van het ene naar het andere project nemen de engineers hun ervaring mee. Met een snelle kopieeractie is er weer een fantastisch beginpunt en een vliegende start voor dat volgende project. Zo blijft de organisatie snel en wendbaar.
Tot het bedrijf te succesvol wordt. Aan de ene kant geweldig om te zien hoeveel van elkaar afgeleide producten er al in het veld staan. Maar ja, klanten die gewend zijn geraakt aan een product met al zijn mogelijkheden, willen soms meer. Al snel komen ze met de vraag of de informatie die nu in een tabel wordt weergegeven, ook in een grafiekje kan komen te staan. Dat is toch maar een kleine aanpassing in de software? En als ze op F4 drukken in het instellingenscherm, dan reageert de programmatuur niet meer. Waarschijnlijk een foutje dat makkelijk op te lossen moet zijn.
Je hoort de onderhoudsafdeling al kraken. Na oplevering van een project krijgt die de software overgedragen. De engineers gaan immers door naar het volgende project. Dus de aanpassingen van de klant komen via de servicedesk bij onderhoud terecht. Weten we nog precies welke versie we ook alweer waar hadden uitgeleverd? Als deze fout in versie 3.5.7 zit, moeten we dan ook de andere versies bijwerken? Wie levert die uit naar de klant? En die aanpassing lijkt ook wel handig om mee te nemen in de huidige ontwikkeling. Wie geeft dat door aan de engineers?
Het management krijgt het warm. Verdorie, dit hadden we in het begin beter moeten opzetten. Laten we actie ondernemen en een ontwikkelteam opzetten dat nadenkt over wat we in de toekomst allemaal nodig hebben. Een team dat dit generiek gaat bouwen en beheren en als een toeleverancier naar de projecten gaat werken. De projecten die als interne klant gaan optreden, zijn verplicht hier gebruik van te maken. Anders blijven we natuurlijk een onderhoudsprobleem houden.
Verkoop moet wel even aan de klanten vertellen dat de systemen die ze al hebben besteld wat later komen. Het bedrijf is namelijk bezig verder te investeren in kwaliteit en dat heeft nou eenmaal tijd nodig. Klanten begrijpen dit wel. Als bedrijf nemen we het nu maar even op de koop toe dat we wat minder snel zijn. Dat halen we straks wel weer in.
Een half jaartje later heeft het generieke ontwikkelteam zijn eerste levering voor de klantprojecten klaar. Voor een daarvan mist helaas nog wat functionaliteit. Moet het project die toch maar zelf realiseren of kan het generieke ontwikkelteam dat doen? Het generieke team gaat ermee aan de slag en bouwt de betreffende functionaliteit bij. Project blij. Maar er was nog een ander project dat op diezelfde component zat te wachten. Hun is verteld dat ze de nieuwe generieke component pas over een maandje kunnen verwachten, ondanks dat zij die extra functionaliteit eigenlijk niet nodig hebben. Hoe vertellen zij hun klant dat het een maandje langer duurt omdat er functionaliteit bij komt die eigenlijk overbodig is?
Aan management, architecten en configuratiebeheerders de taak om de juiste balans te zoeken tussen de twee geschetste uitersten. Mijn credo: start vanuit een volle focus op de klant. Zorg wel voor een nette modulaire architectuur. Een eerste afgeleide mag best een kopie zijn van de eerste versie. Staat er een volgende afgeleide op de roadmap, dan wordt het verstandig generieke delen af te splitsen en onder de verantwoordelijkheid te laten vallen van een generiek ontwikkelteam, met mogelijk wat refactoringwerk richting de eerste twee producten. Reuse after use.
