Bepaal nu of je app technisch haalbaar is met het MoSCoW stappenplan

Als je een app wilt maken, dan wil je natuurlijk weten of je idee wel haalbaar is. Misschien weet je niet zoveel van de techniek achter apps af. Dat hoeft ook niet! Met het MoSCoW stappenplan kom je er in 6 stappen achter of jouw idee wel technisch haalbaar is. 

Lees het artikel of bekijk de samenvatting in de video:


icoon technische eigenschappenDe MoSCoW methode en de MoSCoW principe

De MoSCoW methode is een principe die Dai Clegg ontworp om prioriteiten te stellen in (technologische) projecten. Door deze methode te gebruiken ontstaat er overzicht in projecten en zie je op welke taken je nadruk moet leggen. Het helpt je om snel de juiste keuzes te maken. MoSCoW staat voor:

  • Must Haves: Dit zijn eisen waar het eindresultaat aan MOET voldoen.
  • Should Haves: Dit zijn eisen die gewenst zijn maar niet persé nodig.
  • Could Haves: Dit zijn eisen die alleen aan bod komen als er tijd of geld over is.
  • Won’t Haves: Dit zijn eisen die niet gebruikt moeten worden in het eindresultaat.


Ik gebruikte deze methode als inspiratie voor het stappenplan, waarmee jij test hoe technisch haalbaar jouw app-idee is. Bij dit stappenplan haalde ik voor het gemak de W van Won’t Haves er uit.

We gebruiken de MoSCoW methode in deze 6 stappen om de technische haalbaarheid van je app te bepalen:

"De Must Have-lijst zijn de kernfuncties van je app."

icoon afvinklijstStap 1: Must Have, Should have, Could have

Met jouw app heb je een duidelijk doel: je wilt een bepaald probleem oplossen of mensen helpen. Gebruikers voeren bepaalde taken uit met jouw idee. Welke functies moet je app bezitten om die taken te voltooien? Maak een Must Have-lijst van functies die jouw app SOWIESO moet hebben om te zorgen dat het probleem zich oplost of dat de taak is uitgevoerd. Dit zijn de functies die je app gegarandeerd moet hebben. Een wegwijzer-app kan bijvoorbeeld niet zonder een GPS-functie, dit noem je een must have.

Daarna ga je de Should Have-lijst maken. Hiervoor denk je na over handige functies die de kerntaken ondersteunen. Het is niet persé nodig om deze functie toe te voegen maar kan wel van meerwaarde zijn. Bij de wegwijzer-app is het bijvoorbeeld handig dat de gebruiker ziet waar zijn vrienden op de kaart zijn. Zo vinden zij elkaar snel en kunnen tegelijkertijd ook de weg vinden. Een login via Facebook zorgt op een eenvoudige manier er voor dat je snel je vrienden kan importeren in de wegwijzer-app, dus dat is onderdeel van de functie. Maar is deze functie persé nodig om de weg te vinden? Nee. Kan het wel bijdragen aan de weg bewandelen? Ja. Durf keuzes te maken en zet zoveel mogelijk op het Should Have-lijstje in plaats van op de Must Have-lijst.

Dan bestaat er ook nog een Could Have-lijst. Op deze lijst zet je de functies die je leuk vindt voor de app, maar eigenlijk alleen een extraatje zijn. Zo kan er bij de wegwijzer-app een chatfunctie worden toegevoegd, zodat gebruikers met elkaar kunnen chatten. Dat is een gezellig en leuk idee. Alleen voegt het weinig toe aan de originele taak: de weg vinden.

Nu heb je 3 lijstjes voor je liggen. De Must Have-lijst zijn de kernfuncties van je app. Je wil erachter komen of deze functies technisch haalbaar zijn. Op de Should Have-lijst staan functies die je later kan toevoegen maar deze zijn niet essentieel. Van de Must Have's en Should Haves wil je weten of ze kunnen, omdat het waarschijnlijk is dat ze ontwikkelt gaan worden. Of je de Could Have functies gaat bouwen, hangt sterk af van hoe je app zich ontwikkelt. Als je app gemaakt is en men het gebruikt, krijg je vaak de vraag om andere functies te bouwen dan wat je vooraf bedenkt. Daarom bewaar je de Could Haves voor de toekomst. Zij geven je dan inspiratie, maar het is dus nog onzeker of je ze ooit laat bouwen. Je hoeft dus ook niet te checken of ze haalbaar zijn.

icoon vergrootglasVoorbeeld: De Wegwijzer App - stap 1

Must Have: GPS Functie -> Mensen zien op de kaart waar ze zich bevinden en waar ze heen moeten. 
Should Have: Vrienden zoek-functie (via Facebook)-> Op de kaart zien gebruikers waar hun vrienden zich bevinden. 
Could Have: Chat functie -> Mensen praten met andere gebruikers van de app. (De Could Have functies vervallen in de volgende stap)

icoon opties wisselenStap 2: Bestaande functies

Een goede manier om te kijken of je Must Have functies technisch haalbaar zijn, is om te checken of de techniek al bestaat. Bestaan er andere apps met dezelfde functies? Kijk bijvoorbeeld naar de apps die al op je telefoon staan, of download vergelijkbare apps. Zet een vinkje achter de functies waarvan je weet dat ze al bestaan.  

Heb je nu achter iedere functies een vinkje staan? Gefeliciteerd, je app-idee is voor een groot gedeelte al technisch haalbaar!

icoon vergrootglasVoorbeeld: De Wegwijzer App - stap 2

GPS-functie: De functies GPS en navigeren zie je ook terug in andere apps, dus deze functie is technisch mogelijk. ✓ 
Facebook koppeling: Vrienden van Facebook laten zien in de app. Het blijkt een relatief makkelijke koppeling die al veel apps toepassen, dus deze functie is mogelijk. ✓

icoon onderverdelenStap 3: Systeem koppelingen

Elk app-idee is anders. Per idee verschilt, de doelgroep, het doel of de functie. Geheel afhankelijk van je idee moet je app ook samenwerken met andere systemen. Maak je bijvoorbeeld een bedrijfsapp, dan moet die app werken met het systeem waar de werknemers mee werken. Maak je een app voor zeilers, dan zal je moeten weten hoe de windrichting staat. Je moet dan samenwerken met een systeem die windrichtingen meet. Zo hebben de meeste ideeën ‘hulp’ nodig van een andere systeem.

Deze samenwerking hoeft in principe geen probleem te zijn, maar je moet wel inzicht krijgen in de hoeveelheid systemen die je nodig hebt. Schrijf per functie of je een extern systeem nodig hebt en hoeveel je toegang je nodig hebt om de functies van je app te laten werken.

Over het algemeen ben jij niet de eigenaar van het externe systeem. Meestal ligt het eigendom van het systeem in handen van iemand anders. Jouw app moet gaan ‘praten’ met deze systemen. Probeer na te gaan met wie je moet samenwerken om gebruik te mogen maken van het systeem.

Zijn deze partijen en systemen bereikbaar? Dan weet je of de koppeling van jouw app met het systeem technisch haalbaar is. Let op dat dit nog niet betekent dat een partij wil samenwerken met jou. Veel grote partijen werken via standaardcontracten, zodat je bijvoorbeeld makkelijk je app koppelt aan Google Maps of Facebook. Kleinere partijen zoals jij zullen grote partijen die geen gebruik maken van standaard contracten moeten overtuigen. Dat wordt dus lastig. Zoek op de website van de grote partijen of ze zo'n koppeling standaard toestaan. Zo'n koppeling noemt men in technische termen vaak een "API”. Bieden ze die mogelijkheid? Dan is je app ook technisch haalbaar in stap 3!

Wil je meer weten over hoe apps samenwerken met een ander systeem? Lees dan dit artikel over een app programmeur die vertelt hoe dat werkt.

icoon vergrootglasVoorbeeld: De Wegwijzer App - stap 3

GPS functie: Samenwerken met Google om maps te integreren in de app via Maps API. ✓ 
Facebook koppeling: Samenwerken Facebook om vrienden toe te voegen via Facebook API ✓

foto van iemand die een smartwatch draagt

icoon doelgroepStap 4: Selecteer je doelgroep

Je hebt nu je functies gecheckt en je weet of je moet andere systemen moet gaan samenwerken. Dan breekt nu de tijd aan om je doelgroep te beschrijven. Het lijkt onbelangrijk maar je gaat zo zien waarom dit essentieel is voor de technische haalbaarheid van je app. Bedien je met je app meerdere doelgroepen? Wie spreek je aan? Is hun leeftijd, geslacht en woonsituatie belangrijk of zijn hun hobby’s interessant? 

De mensen die het eerste jouw app gebruiken, zijn meestal de early adopters. Dit zijn mensen die graag iets nieuws proberen en jouw app willen downloaden, zeker als de app handig is. Wie valt onder jouw early adopter groep? Maak een duidelijke schets van je doelgroep. De focus op early adopters is ook voor een latere stap belangrijk: namelijk om je app populair te maken

icoon vergrootglasVoorbeeld: De Wegwijzer App - stap 4

Doelgroep 1: Mannen en vrouwen tussen de 18-40 jaar die vaak afspreken in onbekende steden. Ze zijn avontuurlijk, ondernemend en reizen liever samen dan alleen. 
Doelgroep 2: Groepen jongeren tussen de 12-18 jaar die met de fiets naar een gezamenlijke locatie moeten voor school of andere activiteiten.  
Doelgroep 3: Mannen en vrouwen tussen de 18-60 jaar die niet goed zijn in het oriënteren van de weg. Ze raken vaak de weg kwijt en hebben behoefte aan een oplossing.

icoon grafiekStap 5: Zet je app-idee in de Haalbaarheidsgrafiek

Hieronder zie je de Haalbaarheidsgrafiek. Op de verticale lijn zie je het aantal functies van de Must Have-lijst en op de horizontale lijn zie je de doelgroepen die de app moeten gebruiken. De gebogen lijn geeft de grens aan of een app-idee technisch haalbaar is of niet: alles onder de lijn is technisch haalbaar. Als een app te veel functies én een te brede doelgroep heeft, dan is die onhaalbaar. Daarom worden app-ideeën boven de lijn geen succes.

Haalbaarheidsgrafiek app

icoon vergrootglasVoorbeeld: De Wegwijzer App - stap 5

De Wegwijzer app bedient veel verschillende doelgroepen maar bezit weinig functies. De wegwijzer komt dus rechtsonder in de Haalbaarheidsgrafiek te staan. Over het algemeen niet verstandig om meer dan 1 doelgroep te benaderen. Je kan beter één doelgroep goed helpen in plaats van drie groepen maar een beetje. Lees voor meer informatie de onderstaande casus: Elektronisch Patiënten Dossier app.

Combineer nu jouw must-haves met je doelgroep en positioneer jouw app-idee in de grafiek. Staat je idee onder de gebogen lijn? Dan is jouw idee technisch haalbaar! Is jouw idee boven de lijn te vinden? Geen probleem, lees dan verder bij stap 6.

icoon boekCasus: Elektronisch Patiënten Dossier App 
Een goed klassiek voorbeeld uit 2008 van technische haalbaarheid is de Elektronisch Patiënten Dossier App (EPD-app). Als iemand bij de eerste hulp in het ziekenhuis terecht komt, wordt deze app gebruikt om snel diens medische verleden te zien. Zoals de naam al zegt, houdt deze app je medische historie bij. Hiermee ziet niet alleen de arts van het ziekenhuis het dossier maar ook de patiënt, huisarts of apotheker. Een handig idee, zou je kunnen zeggen. Helaas bleek de uitvoering geen succes. Er zaten enorm veel functies in de app om hem goed te laten functioneren. Daarnaast gebruikten de huisarts, apotheker en dokter allemaal andere medische termen. Dit werd gebruikt voor een brede doelgroep. Oftewel, de EPD-app bezat veel functies én had veel verschillende doelgroepen voor ogen. Dit plaatst de app rechtsboven in de Haarbaarheidsgrafiek. Als je het nieuws eind 2008 hebt bijgehouden dan weet je dat deze app faalde en de overheid miljoenen kostte.

icoon vinkjeStap 6: Zo kom je onder de lijn en ben je technisch haalbaar

Als je de MoSCoW stappenplan hebt gevolgd, heb je nu een lijstje met jouw kernfuncties waarbij staat welke functie technisch haalbaar is en welke niet. Het is goed om van tevoren te bekijken of jouw idee wel uitvoerbaar is. Zo schat je in waar er beren op de weg zijn. Toch moet je je niet laten ontmoedigen als niet elke functie direct haalbaar is.

Ook plaatste je je idee in de Haalbaarheidsgrafiek. Veel app-ideeën vallen in eerste instantie in het verkeerde gedeelte van de grafiek, boven de gebogen lijn. Dit is geen probleem maar een goed moment om je idee aan te scherpen. Te veel doelgroepen en functies bij elkaar, werkt helaas niet. Dat is te zien in het voorbeeld van de Elektronische Patiënten app. Maar ook een idee die (nog) niet goed genoeg is, kan het roer omgooien..

icoon boekCasus:  Elektronisch Patiënten Dossier App 
Die EPD-app bediende teveel verschillende functies en gebruikers. Nadat dit duidelijk werd, kwam er eenzelfde soort app voor specifieke doelgroepen, bijvoorbeeld voor zwangere vrouwen. Hiermee zien zwangere vrouwen en verloskundigen gemakkelijk zwangerschapsgegevens in. Deze app bezit nog steeds veel functies. Maar omdat er één duidelijke doelgroep is, is het veel eenvoudiger om de app te maken. Dit zorgt ervoor dat de app linksboven terecht komt in de grafiek. Deze vorm van de EPD-app bleek dus wel een succes!

Mijn tip: ‘Verzand niet in de techniek van de app, maar begin bij het nut!’. Door je focus te leggen op het nut voor de doelgroep bepaal je beter welke functies belangrijk zijn. Zorg dus voor één duidelijke doelgroep en bekijk welke functies zij écht nodig hebben op basis van hun problemen waar ze hulp bij kunnen gebruiken. Je levert nut in de app als oplossing van problemen van de doelgroep. Je app moet duidelijke toegevoegde waarde bezitten. Als jouw app een duidelijk nut bezit voor de gebruiker en een echt probleem oplost, dan verhoog je de kans op een succesvolle app. Jij gebruikt toch ook geen apps waar je weinig aan hebt? Maar daarom niet een app die "wel leuk" is  maar "onmisbaar!"

De techniek van de app heb je nu getest, dus daar hoef je je geen zorgen te maken. Over de markthaalbaarheid van je app wél. Leg daarom de focus op je doelgroep. Combineer de focus op de doelgroep met jouw passie en dat brengt jouw idee al heel ver!

"Welke ontwikkelingsmethode heeft jouw idee nodig?"

icoon eigenschappenOntwikkelingsvergelijker

Als je de technische haalbaarheid van je app test, interesseert het je waarschijnlijk ook om je te verdiepen in de ontwikkelingsmethode die jouw app nodig heeft. Zo begrijp je de techniek van je app beter.

Hiervoor maakte ik een handige ‘Ontwikkelaarsvergelijker’. Hiermee check je welke soort ontwikkeling technieken het beste werken voor jouw idee. Vul hieronder je emailadres in en krijg hem direct in je mailbox!

-David van AppSpecialisten

geschreven door
David van der Loo