De start van een maatwerk software ontwikkeling project is cruciaal – en de belangrijkste stap waarop je zelf nog alle invloed hebt.

Nogal een binnenkomer, ik weet het. Maar terwijl er nooit meer werd geïnvesteerd in maatwerk software ontwikkeling, zegt nog steeds 70% van alle opdrachtgevers achteraf niet tevreden te zijn.

Dat kan beter, en een belangrijke rol is weggelegd voor jou als opdrachtgever. Daarover gaat dit artikel.

Kwaliteit in maatwerk software ontwikkeling

Je laat dus maatwerk software ontwikkelen voor je bedrijf.

Hoe zorg jij ervoor dat je kwaliteit in huis haalt?

En wat is “kwaliteit” in software ontwikkeling eigenlijk?

Het ligt voor de hand om dit te beantwoorden met uitspraken als:

“de software is goed als het foutloos werkt”

Of

“… als het doet wat we hebben afgesproken”

Maar dat is de functionele benadering.

Wat mij betreft mag je ervan uitgaan dat software foutloos werkt, en doet
wat je hebt afgesproken. Dit is een basisvereiste. Toch?

Maar als je verder kijkt dan die functionele benadering, dan vind je hele andere
specificaties. Ze kunnen van grote invloed zijn op de ‘value for money’ die je koopt.

Als gebruiker kun je deze specificaties niet zien. Maar ze bepalen misschien wel de werkelijke slagingskans van je project.

Verborgen specificaties in maatwerk software ontwikkeling

Ik noem dit “verborgen specificaties”. Het zijn de onzichtbare (niet functionele) eigenschappen van je applicatie. En de onuitgesproken voorwaarden waaronder de software in jouw opdracht wordt ontwikkeld.

Het zijn meestal de verborgen specificaties die bepalen of jouw software project succesvol is of uitdraait op een mislukking. Zeker op de lange termijn.

Deze eigenschappen en voorwaarden zijn niet voor niets verborgen – ze blijven onder de radar, omdat jij graag wilt praten over de functionaliteit en omdat je software leverancier niet alle details kan beschrijven in de offerte.

Daarom beschrijf ik in dit artikel de belangrijkste 5 verborgen specificaties in maatwerk software ontwikkeling.

Vraag je mogelijke leveranciers om deze onderwerpen toe te lichten en waar nodig op te nemen in de offerte.

Hun antwoorden maken het jou in de eerste plaats gemakkelijker om met een goed gevoel de juiste partner te kiezen. En daarnaast leidt het uitspreken en vastleggen van deze onderwerpen gegarandeerd tot software van hogere kwaliteit.

Zodra je je bewust bent van de 5 verborgen specificaties, zul je zien dat het opeens veel gemakkelijker is om afwegingen te maken. En om de best passende ontwikkel partner te selecteren.

Zonder dat je hiervoor speciale technische (IT) kennis nodig hebt.

Zo vergroot je je kans om je investering in maatwerk software rendabel te maken.

1. Voorkom gevaarlijke afhankelijkheid

Goede software integreert in je bedrijfsprocessen en zorgt voor verbinding. Als smeerolie, of een rader. Maar naarmate je organisatie meer berust op de software, groeit ook de afhankelijkheid van je leverancier.

Een zekere afhankelijkheid van een leverancier bestaat natuurlijk altijd, maar deze moet niet onnodig gevaarlijk zijn.

Je afhankelijkheid mag niet zo groot worden dat deze een gelijkwaardige samenwerking in de weg staat.

Als jouw leverancier eigenaar blijft van de intellectuele eigendomsrechten van de ontwikkelde software, en geen rechten en broncodes van het gemaakte werk afstaat, dan is er zeker sprake van een gevaarlijke afhankelijkheid.

Wat gebeurt er bijvoorbeeld als jouw onderneming groeit, en je de applicatie zelf in beheer wilt nemen? En waar sta je wanneer je leverancier de tarieven verhoogt, lange wachttijden gaat hanteren, of -de angst van veel ondernemers die “hun idee” laten bouwen- een vergelijkbaar product verkoopt aan de concurrent?

Voorkom dit en zorg ervoor dat de rechten van intellectuele
eigendom aan jouw bedrijf worden overgedragen.

En let op: vermelding van één zinnetje in een offerte is vaak niet genoeg. Juridisch gezien moet er sprake zijn van een “akte van overdracht”. Vanuit praktisch oogpunt raad ik dit ook aan, want in zo’n akte beschrijf je niet alleen uitvoerig wát er wordt overgedragen, maar ook onder welke voorwaarden.

Zo is er van alles af te spreken, bijvoorbeeld over de manier waarop broncodes worden overgedragen, welke kosten de leverancier hiervoor in rekening mag brengen, naamsvermelding en het gebruik van open source componenten.

Het is gebruikelijk dat de leverancier via deze akte een “retourlicentie” ontvangt, waarin hij –onder strikte beperkingengenerieke delen van de door hem gemaakte broncode mag hergebruiken. Maar ook als je dit niet wilt dan is de akte van overdracht de vorm om dit expliciet overeen te komen.

Belangrijk om te weten is dat standaard, onder de Nederlandse Auteurswet, de “maker van een werk” het recht van intellectuele eigendom van dat werk behoudt. Zonder expliciete akte krijg je dus niets. Dat maakt het auteursrecht bij uitstek een verborgen specificatie.

2. Ontwerp niet teveel

Er zijn al ontzettend veel software projecten mislukt doordat de opdrachtgever én de opdrachtnemer zich committeerden aan een vuistdik ontwerp. En aan de belofte dat het daarin beschreven systeem na een maandenlange bouwfase (zonder of met sporadisch tussentijds contact) zou worden opgeleverd.

Deze werkwijze is beroemd gemaakt door grote ICT-bedrijven en
overheidsprojecten.

Het is best verleidelijk je te laten meevoeren door een leverancier die met zo’n vuistdik ontwerp op de proppen komt.

Of die voorstelt om eerst een paar weken goedbetaald te gaan ontwerpen. Het lijkt er immers op dat deze partij veel moeite doet om serieus een oplossing voor je probleem te bedenken. En misschien is dat ook wel zo.

Maar wat blijkt: in de praktijk werkt het juist averechts om je systeem van tevoren helemaal uit te denken en op papier te zetten.

Hoe omvangrijker en completer je ontwerp namelijk is, des te langer het duurt totdat je gebruikers (of jij) iets in handen hebben. En dat blijkt heel belangrijk voor de kwaliteit van je software én de kosten die je gaat maken.

Dit komt door twee simpele wetmatigheden bij het ontwerpen van software:

• Het is onmogelijk om een systeem perfect te ontwerpen. Bij elk systeem constateren de gebruikers functionele fouten, ontbrekende functies of een werkelijkheid die afwijkt van papier.
• Hoe langer de bouwfase duurt, des te meer zal de opgeleverde software achterlopen op de werkelijkheid. Dit levert “re-work” dat voorkomen had kunnen worden.

Natuurlijk heb je een een goede overview nodig van het beoogde systeem. En een technisch ontwerp, waarin je (verborgen) specificaties beschrijft. Maar het functionele ontwerp kun beter opdelen in kleine featuresets, om daarna zo snel mogelijk de eerste featureset te bouwen en in gebruik te nemen.

Spreek met je leverancier een korte eerste bouwfase af en houd elkaar daaraan. Neem bijvoorbeeld 4 weken: na een maand bouwen neem je de eerste versie in gebruik.

Het ligt voor de hand dat je dan start met een applicatie met hoogstens basale, primaire functionaliteit.

Maar dat is prima, uitstekend zelfs! Je wordt nu namelijk gedwongen om vast te stellen wat écht de belangrijkste functies van het systeem zijn. De eerste versie is functioneel genoeg om in je bedrijf te integreren, en inhoudelijk zodanig dat het input en/of output levert voor de volgende functies.

Na oplevering neem je deze applicatie meteen in gebruik en stel je met je gebruikers vast wat de belangrijkste volgende verbetering moet zijn. Je spreekt een cyclus af waarin je nieuwe features in gebruik neemt, bijvoorbeeld elke week of twee weken.

Gefeliciteerd: je hebt nu een software systeem in het leven geroepen dat flexibel kan meebewegen met de werkelijkheid van je business en feedback van je gebruikers.

Bovendien heb je het risico om werk opnieuw te moeten doen of functies helemaal weg te gooien, enorm verkleind. Maar één van de belangrijkste resultaten van deze aanpak zul je functioneel niet meteen merken. In het volgende hoofdstuk vertel ik wat dat is.

3. Omarm en specificeer wendbaarheid

In het vorige hoofdstuk noemde ik het belang van een wendbaar traject. Door je software vaak op te leveren en bij te sturen met feedback vanuit je business en gebruikers, krijg je een veel beter product en zul je minder kosten maken.

Maar er is nog een prachtig gevolg van deze werkwijze, een gevolg dat aan de oppervlakte niet zichtbaar is: je hebt namelijk een leverancier gevonden die wil en kan bouwen voor wendbaarheid. En met hem heb je goud in handen.

Elke leverancier zal jou beloven goede software te maken. En ik wil voor het gemak nu best even aannemen dat elke softwarebouwer ook echt naar de beste software zal streven. De realiteit is dat er 1001 vormen bestaan om software te ontwerpen en waarschijnlijk is het niet mogelijk om één vorm als “de beste” aan te merken.

Maar toch is er een belangrijk onderscheid waarop je alle mogelijke ontwerpen van software in twee groepen kunt verdelen. En dat onderscheid zit hem in het volgende:

• Het is een wereld van verschil of een ontwerp zich richt op de specificaties van een applicatie, of op een veranderlijk softwaresysteem dat vandaag kan bestaan uit deze specificaties en morgen uit andere.

Wat betekent dit? Dat je het bouwen van wendbare software, met kleine deelontwerpen en snelle opleveringen als resultaat, niet moet zien als een methode, maniertje of truuk om tot een applicatie te komen. Het gaat veel verder dan dat:

Wendbaarheid is geen eigenschap van een proces: het moet onderdeel zijn van de definitie van jouw applicatie. Wendbaarheid is een feature die je moet specificeren. Een leverancier die samen met jou de wendbaarheid van de oplossing omarmt en dit expliciet maakt in het ontwerp, zal een component gebaseerde, gelaagde en generieke applicatie bouwen die is ingericht op verandering. Hij zal je niet snel verrassen met bijvoorbeeld één van de volgende veelgehoorde antwoorden:

• “We kunnen dat niet aanpassen. We moeten dat stuk weggooien en opnieuw maken.”
• “Dat hadden jullie eerder moeten zeggen, nu is er geen weg terug.”
• “Dat kan misschien wel, maar pas als alles klaar is. We gaan eerst opleveren wat in het ontwerp staat. Dan laten we nog wel weten wat het kost om het aan te passen.”

Vergis je niet: als je bovenstaande voorbeelden te horen krijgt, dan gebeurt dat vaak niet één keer, maar veel vaker – vrijwel bij alle wijzigingen en uitbreidingen die je nodig hebt.

Dit zijn directe uitingen van een slecht software ontwerp. En naarmate de tijd vordert en je applicatie verandert, wordt dit probleem steeds groter. Je leverancier moet steeds meer kunsten uithalen om de applicatie aan de wensen van jouw business en gebruikers te laten voldoen. De relatieve kosten van nieuwe wijzigingen worden steeds hoger.

Het bespreken van deze wendbaarheid als specificatie van de applicatie, en eventueel het vastleggen hiervan in de offerte, is één van de meest doeltreffende manieren om de beste leverancier te selecteren en om je investering zeker te stellen.

Maar omdat dit aspect nergens in de applicatie functioneel tot uiting komt, is het gemakkelijk om dit over het hoofd te zien en onbesproken te laten. Een wendbare architectuur is daardoor een verborgen specificatie.

4. Bouw voor geen -en elke- omgeving

Elke applicatie stelt specifieke eisen aan beschikbaarheid, performance en capaciteit. Soms is dit zelfs afhankelijk van het tijdstip, de dag van de week of het seizoen. Cloud architectuur biedt in dit geval de perfecte omgeving voor je applicatie.

Want in een cloud omgeving kun je de resources voor je applicatie op- en neerschalen wanneer dat nodig is. Gepland op gezette tijden, zoals bepaalde weekdagen of een specifieke salesperiode.

Maar ook automatisch, bijvoorbeeld wanneer je applicatie een grenswaarde aan processorkracht of geheugen bereikt.

Maar zelfs als je je systeem niet in de cloud onderbrengt, doe je er goed aan je applicatie zodanig te laten ontwikkelen dat deze klaar is voor elke omgeving. Dus voor gebruik op je eigen netwerk of bij je hosting partner, maar ook voor in een cloud omgeving. Het doel moet eigenlijk zijn: software voor geen omgeving.

Omgevingsvrije software heeft een aantal architectuur eigenschappen die de kwaliteit van je software sterk vergroten.

Ik noem er drie:

• Omgevingsvrije software is schaalbaar in de breedte. De applicatie kan over meerdere werkprocessen (machines) verdeeld worden om zo meer aanvragen tegelijkertijd te verwerken.
• Omgevingsvrije software is overdraagbaar. De software kan gemakkelijk naar een ander werkproces (machine) verplaatst worden, en alle uitgaande en inkomende verbindingen kunnen naar het nieuwe netwerkadres worden verwezen.
• Omgevingsvrije software is staatloos. De software bevat geen componenten die de actuele “staat” van de applicatie (gegevens van een gebruiker, sessie of proces) lokaal bewaren. Alle staatinformatie wordt gedeeld in een externe, centrale locatie.

Deze drie architectuureigenschappen leveren samen de flexibiliteit die je nodig hebt. Op het eerste gezicht biedt dit functioneel weinig voordeel. En misschien vertrouw je erop dat dit gewoon goed door je leverancier geregeld wordt. Maar daar ligt nu precies het gevaar.

Dit zijn uitgerekend verborgen specificaties die je nadrukkelijk moet vastleggen. Want een systeem ontwerpen volgens deze architectuur is wel de beste aanpak, maar niet de gemakkelijkste. En ik kan je garanderen dat vrijwel elke leverancier op deze onderwerpen zal bezuinigen, zodra het budget maar een beetje begint te knellen.

Aangenomen –uiteraard!- dat jouw software een groot succes wordt en lang zal bestaan, krijg je hiervoor vroeg of laat de rekening gepresenteerd. En dat kon wel eens eerder zijn dan je denkt, bijvoorbeeld wanneer:

• je applicatie meer resources nodig heeft;
• je back-up omgeving de applicatie moet overnemen ivm een storing;
• je wilt overstappen naar een nieuwe hosting provider met betere prijzen of SLA;
• je een server moet vervangen ivm storingen of onderhoud;
• je bedrijf gaat verhuizen.

Kortom, ook als je jouw applicatie niet in de cloud gaat onderbrengen, dan zijn dit belangrijke kwaliteitsindicatoren van je software systeem. Maak dus afspraken over schaalbaarheid, overdraagbaarheid en staatloosheid van de oplossing. Zo vind je de leverancier met voldoende kwaliteit in huis om ook op lange termijn de beste oplossing te leveren.

5. Ken je applicatie

Logging is wat mij betreft het schoolvoorbeeld van de verborgen specificatie. Ik durf te wedden dat je van veel leveranciers, als je er niet naar vraagt, weinig tot niets over logging zult horen. Logging wordt meestal gezien als de sluitpost van de begroting en wordt dan op het laatste moment nog even ingebouwd. En dat is niet alleen zonde, het is zo fout als het maar kan. Logging moet een feature zijn van de applicatie en ook als zodanig worden gebouwd en getest.

De werking en status van software worden niet alleen bepaald door de uitgevoerde data of feedback van gebruikers.

Goede software registreert relevante statusinformatie op een centrale plek en maakt deze realtime inzichtelijk. Niet dat jíj daar nu de hele dag naar gaat zitten kijken… dat hoeft niet.

Maar elke applicatie heeft een functioneel beheerder nodig. Meestal is hier een afdeling verantwoordelijk voor, een systeembeheer partner, hosting partner of de leverancier.

“Functioneel beheer” moet op elk moment in een oogopslag de actuele status en recente prestaties van de applicatie kunnen inzien, en rapporten kunnen opvragen van tenminste 30 dagen terug. De logs moeten het volgende inzichtelijk maken:

• actuele status van afzonderlijke componenten (opslag, database, apparaten), inclusief 24-uurs historie;
• responsetijden van belangrijke operaties, pagina’s of schermen in de afgelopen 24 uur;
• fouten/storingen die mogelijk een gebruikershandeling onderbroken hebben in de afgelopen 7 dagen.

Als je leverancier voldoende aandacht besteedt aan logging en aan een manier om logs inzichtelijk te maken, dan zal dit al snel vruchten afwerpen. Zeker in de fase na de eerste oplevering kunnen met behulp van goede logs de eerste bugs en performance vraagstukken snel worden opgelost – zaken die zonder logging heel veel tijd kosten of zelfs onmogelijk zijn.

Dus zorg dat Logging niet de sluitpost wordt voor jouw software, want dan doe je jezelf echt tekort.

Met goede logging kom je sneller tot de oorzaak van problemen én tot een oplossing.

Bovendien verschaft realtime logging je een objectieve indruk van de kwaliteit, performance en stabiliteit van je applicatie. Als je vanaf de start een goede logging implementeert, dan ontdek je eventuele knelpunten vroeg en maak je de technische effecten van nieuwe features en wijzigingen direct meetbaar.

Maatwerk software ontwikkeling – hoe verder?

Je hebt nu mijn vijf sleutelfactoren voor succesvolle maatwerk software ontwikkeling gelezen. Deze inzichten kunnen je helpen de juiste leverancier te kiezen en nog veel meer goede beslissingen te nemen. Dus begin er al mee in de offertefase: breng deze onderwerpen ter sprake en luister naar de reactie van je leveranciers. Het zal je betere software opleveren en een efficiëntere, snellere route daar naartoe.

Het is moeilijk om grip te krijgen op maatwerk software ontwikkeling, zeker wanneer één partij dit doet in opdracht van de andere. Het ligt daardoor voor de hand om je samen vooral te richten op wat je gemakkelijk concreet kunt maken: de functionele aspecten van de applicatie.

Takeaway

Als je iéts wil onthouden, dan dit: dat de totale kwaliteit van software zich niet alleen laat zien in de functionele eigenschappen. Dat zou denk ik mijn “takeaway” zijn.

Vijf of meer?

Er zijn nog wel meer factoren te bedenken, maar deze vijf heb ik opgenomen omdat ze volgens mij zó algemeen zijn dat ze echt gelden voor elk software project.

Ik dank je hartelijk dat je dit artikel (helemaal tot het einde!) hebt gelezen en ik wens je veel succes met de ontwikkeling van jullie software.

Als je mij je mening over dit stuk wilt laten horen, verder wilt discussiëren of andere vragen hebt, dan hoor ik ze heel graag.

Mijn contactgegevens vind je op deze pagina.

~Jorrit Venema