Software bouw je niet zomaar. Voordat er daadwerkelijk een oplossing, in de vorm van software, wordt gemaakt moet er eerst duidelijkheid zijn overmoet er eerst duidelijkheid zijn ove zijn wat die oplossing is. Hiervoor zijn verschillende aanpakken die allemaal werken op hun eigen manier. Alhoewel ik ervan overtuigd ben dat één aanpak op alle vlakken veel beter is.
Om goed te begrijpen waarom wij voor deze ene aanpak gekozen hebben, moeten we de andere eerst even langsgaan. Het gaat hier voornamelijk over de traditionele aanpak voor het bouwen van maatwerksoftware, de MVP-aanpak voor het bouwen van een SaaS (en maatwerksoftware) en de SLC-aanpak voor het bouwen van software in het algemeen.
De traditionele aanpak
Deze aanpak wordt vaak gebruikt voor het bouwen van maatwerk software. Heel soms wordt het ook gebruikt voor SaaS applicaties maar je zal zien dat dit niet de optimale aanpak is voor SaaS applicaties.
Het process
De traditionele aanpak voor (maatwerk) software ontwikkeling volgt een lineair proces, waarbij elke fase afgerond moet worden voordat de volgende fase kan beginnen. Het begint eigenlijk met het vinden van een oplossing voor een probleem. Deze oplossing moet dan worden omgezet in eisen. Deze eisen beschrijven eigenlijk de functionaliteit van de software. Om een duidelijk visueel beeld te krijgen worden deze eisen/functionaliteit omgezet in ontwerpen. Deze ontwerpen laten zien hoe de applicatie eruit komt te zien.
Deze ontwerpen worden vaak ook omgezet in prototypes. Dit maakt de ontwerpen levend en kan er door heen geklikt worden. Zo kan de klant/opdrachtgever alle (visuele) functionaliteit nalopen en feedback geven. Deze feedback wordt vervolgens weer netjes verwerkt in de ontwerpen en herhaalt de cyclus zichzelf. Dit proces herhaalt zich totdat de klant/opdrachtgever akkoord gaat met de ontwerpen.
Na een akkoord op de ontwerpen wordt de applicatie met software gerealiseerd. Nu komt de software echt tot leven en kan er mee gewerkt worden. Vaak wordt de software in kleine stapjes gemaakt. Vervolgens wordt deze op een “staging” omgeving gezet waar de functionaliteit getest kan worden.”
Het doel
Het doel van de traditionele aanpak is het opleveren van een (maatwerk) softwareoplossing. Omdat het vaak voor een specifieke klant/opdrachtgever wordt gemaakt en de eisen bekend zijn, kunnen deze vooraf opgesteld worden. Er is namelijk een probleem waarvoor een oplossing moet komen. Dit probleem (of idee) kan vaag zijn, maar dat wordt in de beginfases steeds duidelijker.
Tijdens de ontwerp-fase is er genoeg ruimte om aanpassingen te maken. Dit is voor de klant/opdrachtgever belangrijk omdat het kan voorkomen dat diegene toch iets anders in zijn/haar hoofd had waardoor een functionaliteit aangepast moet worden.Deze aanpassingen kunnen dan gemakkelijk doorgevoerd worden in de ontwerpen. Deze ontwerpen geven daarom ook een duidelijk beeld van hoe het eindproduct eruit komt te zien.
De MVP (Minimum Viable Product) aanpak
Een MVP staat voor een Minimaal Werkend Product. Zoals de naam het zegt is dit een product dat minimaal werkend is. Het moet dus zodanig werken dat het net bruikbaar is voor de taak waarvoor het gemaakt is. De MVP-aanpak wordt vaak gebruikt om een idee of concept te testen. Soms voor een kleine groep test gebruikers, soms wordt het ook al in de markt gezet om te kijken of er vraag naar is.
Het proces
Een MVP begint altijd met een idee of probleem. Omdat je vooraf niet kunt weten of mensen dit zouden gebruiken, kun je niet de traditionele aanpak gebruiken. Hoewel je 1 of 2 functionaliteiten weet, omdat dat het idee of probleem is, kun je vooraf niet weten welke functionaliteiten gebruikers waardevol vinden. Dit is de reden dat er een MVP gemaakt wordt. Deze MVP bevat de 1 of 2 kern-functionaliteiten.
Deze MVP wordt daarna gebruikt door een groepje vroege gebruikers of wordt onder de aandacht van potentiële gebruikers gebracht. Als er vraag naar is zullen er gebruikers aanmelden en de MVP gebruiken. Tijdens dit proces is het heel belangrijk dat er feedback verzameld wordt van de gebruikers. Op basis van deze feedback worden er nieuwe functionaliteiten ontwikkeld of wordt bestaande functionaliteit aangepast.
Zo groeit de MVP uit tot een volwaardig en compleet product. Dit allemaal met de nadruk op snelheid. Het kan ook voorkomen dat er geen gebruikers zijn die zich aanmelden voor de MVP. Dit betekent vaak het einde van de MVP vanwege geen of weinig vraag. De makers van de MVP kunnen dan ervoor kiezen om dit idee achter zich te laten of een “pivot” te maken.
Het doel
Ik heb het eigenlijk al verteld maar het doel van een MVP is om een idee of oplossing voor een probleem te testen. Stel je voor, je hebt een idee dat de wereld gaat veranderen. Een social media app voor je huisdieren. Als je de traditionele aanpak volgt, dan ga je eerst alle eisen/functionaliteiten beschrijven. Vervolgens zet je deze om in ontwerpen. Je test de ontwerpen door prototypes ervan te maken en nadat je tevreden bent, ga je aan de slag met het bouwen van de applicatie.
Maanden verder ben je eindelijk zo ver. De hele app is ontwikkeld en werkzaam. Nu is het tijd voor de lancering. Je maakt Facebook-advertenties, posters, en je promoot het overal waar je kan. Na een aantal weken zijn er nog maar 5 gebruikers (waarvan 3 vrienden). Daar zit je dan met een complete app die fantastisch werkt maar waar geen vraag naar is.
Stel je voor, je had dit met een MVP gedaan. Wat is de basis functionaliteit? Delen van foto’s van je huisdieren. Je bouwt dit snel en probeert dan dezelfde aanpak met Facebook-advertenties, posters, etc. Nu krijg je veel sneller feedback of er daadwerkelijk vraag naar is.
We gaan er straks nog verder op in waarom deze aanpak een slechte weergave van vraag naar iets kan zijn.
De SLC (Simple, Loved, Complete) aanpak
De SLC-aanpak staat voor het ontwikkelen van softwareproducten die simpel, geliefd en compleet zijn. In plaats van een Minimum Viable Product (MVP) te bouwen, richten we ons op het maken van een product dat meteen waarde toevoegt voor de gebruiker. Waar een MVP een deel is van een potentieel product, is de SLC een eenvoudig product dat op zichzelf staat. Bij deze aanpak staat de gebruiker centraal, niet de ontwikkelaar.
Deze afbeelding wordt veel gebruikt als meme om te laten zien, hoe een MVP proces eruit zou moeten zien maar heeft het meer weg van een SLC-aanpak. Als we het op een MVP manier bekijken, dan zou de auto versie 1.0 moeten zijn terwijl het skateboard dan versie 0.1 is. Als we het op een SLC manier bekijken, dan is skateboard een SLC product en is dat gelijk al versie 1.0. Het is sneller dan lopen, simpel, mensen houden ervan, en het is compleet.
Het proces
De aanpak begint net als bij een MVP ook met een idee of probleem. Dit wordt omgezet naar een aantal kernfunctionaliteiten. Deze kernfunctionaliteiten worden vaak ondersteund door kleinere functionaliteiten. Ook die worden opgeschreven. Onnodige functionaliteiten worden achterwege gelaten zonder dat de gebruikerservaring veranderd.
Net als bij de traditionele aanpak worden deze functionaliteiten omgezet naar een ontwerp. Doordat het nu visueel duidelijk is, kan het zijn dat er nog meer functionaliteiten weggehaald worden. Het is belangrijk dat dit niet de gebruikerservaring mag hinderen.
Deze ontwerpen worden daarna omgezet in een werkend product en het zal daarna ook in de markt gezet worden. Zoals ik al eerder zei zijn de resultaten van een MVP-lancering helemaal niet betrouwbaar. Gebruikers haken vaak af bij een product dat er half klaar uitziet. Daardoor kan het zijn dat je de indicatie krijgt dat je idee niet werkt, terwijl het product het probleem is. Met een SLC-aanpak gebeurt dit niet omdat je een compleet product op de markt zet.
Het doel
Bij een SLC-aanpak zijn er twee doelen. Aan de ene kant wil je een volledig gebruikerservaring leveren die waardevol is voor de gebruikers, maar aan de andere kant wil je toch flexibel genoeg zijn om te leren van je gebruikers.
Een goed voorbeeld is Snapchat. Met de eerste versie kon je alleen een foto maken en die naar iemand sturen waarna deze weer verdween na een bepaalde tijd. Geen video’s, geen filters, geen sociale netwerkmogelijkheid, geen opslag - simpel/eenvoudig, geliefd (gebruikers vonden het geweldig), en compleet.
Een belangrijk punt van de SLC-aanpak is, dat ze dit zo hadden kunnen laten. Het was een complete versie 1.0. De SLC-aanpak geeft de vrijheid van een MVP zonder de minpunten. Snapchat voegde later een heleboel nieuwe dingen toe. Zoals bijvoorbeeld video’s, filters, streaks, een map, chat, en ook een TikTok concurrent: Spotlight.
SLC laat ook toe dat elk van deze functionaliteiten getest kon worden. Waar een MVP voornamelijk inspeelt op feedback en op basis daarvan functionaliteiten bouwt, laat de SLC-aanpak toe dat er nieuwe functionaliteit getest kan worden. Natuurlijk luistert de SLC-aanpak ook goed naar gebruikers, maar doordat het al een compleet product is, hoeft het niet nieuwe functionaliteiten toe te voegen. Een MVP moet nieuwe functionaliteiten toe voegen.
SLC-aanpak bij het bouwen van maatwerk software
Waar de traditionele aanpak vaak gebruikt wordt voor het bouwen van maatwerk software en de MVP- en SLC -aanpak meer voor SaaS applicaties en ideeën, kiezen wij toch voor de SLC-aanpak voor het bouwen van maatwerk software. De SLC-aanpak is eigenlijk een soort variatie op de traditionele aanpak. Het komt vaak voor dat er functionaliteiten worden gebouwd die na de lancering niet worden gebruikt. Een softwarebedrijf heeft er ook geen baat bij om zo weinig mogelijk functionaliteiten te bouwen, maar wij denken anders.
Waarom de SLC-aanpak
Wij denken in het nu met oog op de toekomst. Software moet betaalbaar blijven, en om dit mogelijk te maken focussen wij echt op het gene wat belangrijk is. Een klant/opdrachtgever heeft een probleem en zoekt een oplossing. Deze oplossing hoeft geen grote software te zijn, maar moet wel compleet zijn.
Daarnaast moet er ook de mogelijkheid zijn voor uitbreiding en verandering. Maatwerk gebeurt niet alleen in het begin, maar juist ook na het in gebruik nemen van software. Dat is het moment waarop er gemeten moet worden. Vaak komt men erachter dat iets toch anders moet. Met de SLC-aanpak kunnen we ook heel makkelijk eventuele A/B-testen inbouwen.
Complete maatwerk software
Het kan misschien lijken alsof software ontwikkeld met de SLC-aanpak beperkt is in functionaliteit, maar dit is niet noodzakelijk het geval. De SLC-aanpak is er juist om ons bij de realiteit te houden en niet af te dwalen van waar het om draait. Deze aanpak zorgt ervoor dat onze focus op de gebruiker blijft. SLC software is zo compleet als het moet zijn. Dit kan betekenen dat bepaalde functionaliteiten er niet in zitten omdat deze overbodig zijn.
Extra functionaliteiten maken software alleen maar ingewikkelder. Dat is wat wij willen voorkomen met de SLC-aanpak. Met de SLC-aanpak streven we naar software die simpel en eenvoudig te gebruiken is, geliefd bij gebruikers doordat zij centraal staan. De software is compleet, zodat een tweede versie niet noodzakelijk is, maar wel mogelijk blijft.
Een laatste woord
Geen van deze aanpakken is goed of fout. Zoveel verschillen ze ook weer niet van elkaar. Het gaat erom dat je begrijpt waarom wij voor de SLC-aanpak gekozen hebben. Onze SLC-aanpak kan ook weer verschillen van een ander bedrijf dat de SLC-aanpak gebruikt. Iedereen ontwikkelt zijn eigen aanpak op basis van richtlijn2en. Als er volgend jaar een betere aanpak uitkomt, blijven wij ook niet hangen in onze aanpak. We testen de nieuwe aanpak en als die beter is dan onze huidige, vervangen we onze huidige aanpak.
Ik hoop dat je nu een beter beeld hebt gekregen bij de verschillende aanpakken hoe software ontwikkeld kan worden en dat je begrijpt waarom wij voor de SLC-aanpak kiezen. Mocht er iets niet duidelijk zijn of heb je vragen, stuur een email naar [email protected].
Arjen de Vos 
