• Ben jij al bezig met het heruitvinden van jouw businessmodel in dit digitale tijdperk? We helpen je graag.

Een platform ontwikkelen? We geven je 5 tips om een vliegende start te maken.

Job de Boer

23-08-2019 | 6 min leestijd

Heb jij ideeën voor een digitaal businessmodel waar je leven in wil blazen? Dan is de kans groot dat je binnenkort begint aan de ontwikkeling van jouw online platform. Een platform is namelijk een plek waar vraag en aanbod in een digitale omgeving bij elkaar komt. Een plek waar nieuwe waardeproposities, verdienmodellen en banen ontstaan, maar ook oude businesses verdwijnen. Steeds meer bestaande bedrijven en nieuwe ondernemers zijn op zoek naar ‘de nieuwe Uber’s’, wat in de praktijk toch een flinke uitdaging blijkt te zijn. Het ontwikkelen van een platform is namelijk geen simpele opgave. Doordat methoden en technieken de afgelopen jaren beter en beter zijn geworden, liggen ook de functionele eisen van maatwerk software een stuk hoger.

In dit artikel delen we een vijftal tips die jou een ‘competitive edge’ kunnen geven. Let wel op dat, zeker bij complexere projecten, het succes van veel meer factoren afhankelijk is.

1. Zorg voor duidelijke requirements van het software project

Een requirement is een combinatie van het gedrag, de kenmerken en de eigenschappen van een platform. Het opstellen van requirements is daarom van groot belang. Goed opgestelde requirements creëren namelijk draagvlak voor de stakeholders van een software ontwikkelingsproject. Zonder draagvlak is de kans groot dat het team focus verliest omdat de gemaakte afspraken niet duidelijk zijn en niet alle neuzen dezelfde kant op staan.

Twee bekende type requirements zijn:

  • Non-functional requirements; de kwaliteitseisen waar een platform aan moet voldoen (bijv. performance, schaalbaarheid en veiligheid).
  • Functional requirements; de functies die een platform (of onderdelen van een platform) moet hebben (bijv. afrekenen bij een webshop).

Door de verschillende type requirements te herkennen, zien we sneller wanneer we iets over het hoofd zien. Hoe vaak gebeurt het niet dat er wordt gevraagd om iets specifieks te ontwikkelen, maar dat er niet is nagedacht over de achterliggende gedachte of het doel van die functionaliteit. Mooi zo’n matching algoritme in je platform, maar werkt het nog zodra er tijdens een piekmoment 10.000 matches tegelijk worden gegenereerd?

Zonder software requirements zal het uiteindelijke resultaat gegarandeerd afwijken van het beoogde resultaat. Het goed opstellen van requirements is daarom essentieel. Zorg dat ze allesomvattend zijn (en dat er dus geen functionaliteiten ontbreken). Een goede test om te zien of iedereen de requirements begrijpt, is wanneer je willekeurige stakeholders bevraagt en iedereen hetzelfde antwoord geeft.

2. Verplaats jezelf in de gebruikers van het platform

Het platform moet aansluiten bij de wensen en behoeften van je gebruikers. Dit lijkt vanzelfsprekend, maar in de praktijk komt het vaak voor dat er veel gebaseerd wordt op aannames. Het is erg belangrijk dat je de gebruikers van jouw uiteindelijke platform er tijdens het ontwerp en de ontwikkeling bij betrekt. Als je jouw eigen ideeën of aannames niet of onvoldoende toetst, leidt dat tot foute beslissingen waardoor het project risico loopt. Platformen die goed in elkaar zitten maar niet aansluiten op de behoeften of problemen van de gebruikers zijn nutteloos.

Gebruikers kunnen op veel verschillende momenten tijdens de ontwikkeling van een online platform betrokken worden. Bijvoorbeeld bij het bedenken van de functionaliteiten, tijdens de ontwikkeling en na iedere tussentijdse oplevering.

Eén van de methoden die je kunt hanteren om de behoeften en problemen van gebruikers bij het bedenken van functionaliteiten te betrekken, is het schrijven van ‘user stories’. Het opstellen van user stories is een onderdeel van de Scrum methodiek en omschrijft hoe een gebruiker gebruik maakt van een specifieke functionaliteit van een product (vanuit het perspectief van de gebruiker). Het is hierbij uiteraard van belang dat je niet speculeert, maar alle stories baseert op dingen die je weet. Ook als je zelf een gebruiker van het product bent, betekent dat niet dat wat voor jou geldt, ook voor anderen geldt. Het proces hiervoor is als volgt:

  1. Ga met gebruikers in gesprek, bevraag ze met open vragen en ga in discussie over de ideeën of over een prototype dat je mogelijk hebt gemaakt.
  2. Stel user stories op volgens de juiste template (zie onderstaande afbeelding).
  3. Valideer de user stories door ze te delen met gebruikers.

De structuur van een user story.

3. Kies een ‘tech stack’ die bij de applicatie past

Er zijn veel verschillende combinaties van technologieën (en technieken) mogelijk die gebruikt kunnen worden om een online platform te realiseren. In de meeste gevallen wordt er maar voor één of twee technologieën gekozen. Dit hangt af van verschillende factoren; wat er gemaakt moet worden (een mobiele app gebruikt bijvoorbeeld andere technologie dan een webapplicatie), het team dat beschikbaar is, schaalbaarheid van de applicatie, enzovoort.

Een solide basis kiezen en hanteren is het essentieel voor de rest van project. Zo’n basis bestaat uit een programmeertaal en meestal een framework. Enkele voorbeelden hiervan zijn:

Programmeertaal Framework
PHP Laravel
Ruby Ruby on Rails
Python Django
C++ Boost
Java Spring Boot
C# .NET Core

Programmeertalen en passende frameworks.
Een taal is niet per se gebonden aan één framework!

Elk van deze programmeertalen en frameworks hebben specifieke voor- en nadelen. Zelf hebben wij gekozen voor PHP en Laravel voor onze back-end. Om de front-end te ontwikkelen gebruiken wij JavaScript, React en SASS. Laravel is zeer flexibel en bruikbaar in verschillende applicaties en heeft ingebouwde ondersteuning voor caching, cloud storage, sessie drivers, geautomatiseerd testen, databasebeheer en nog veel meer. React is een krachtig framework dat dankzij de levendige community erachter, continu support krijgt van andere developers. De performance van React is ook vele malen beter dan andere frameworks, omdat het data dynamisch kan verwerken. SASS is een CSS preprocessor (ook wel SCSS genoemd). Het grote voordeel hierbij is dat je features kunt gebruiken die niet beschikbaar zijn met normale CSS. SASS zet deze vervolgens om in voor de computer-leesbare CSS syntax.

Naast de keuze voor een programmeertaal en framework moeten er ook beslissingen voor de rest van de infrastructuur worden genomen. Dit kunnen dingen zijn zoals een databasemanagementsysteem, testplatform en/of hostingomgeving.

Ons advies voor de keuze luidt:

  • Ga voor een technologie die past bij het probleem dat je op wil lossen, sommige frameworks zijn nou eenmaal beter voor bepaalde cases.
  • Ga voor een populaire open-source technologie, hierdoor ben je zekerder over zaken als veiligheid, documentatie en packages.
  • Ga voor een stack die past bij het team dat je hebt, mensen die je kent of wilt aanhaken. De populariteit van een technologie heeft bijvoorbeeld ook invloed op toekomstige personeelswerving.

4. Ontwikkel software op een ‘Agile’ wijze

Software development methodieken hebben een verschuiving gemaakt van de oude Waterval methodiek naar nieuwe Agile methodieken (waaronder Scrum). Dit komt omdat meer en meer mensen de voordelen inzien van een snelle, iteratieve aanpak. ‘Release early, release often’ wil zeggen dat je blijvend kleine versies (tussenproducten) van het eindproduct deployed. De projectmanager moet hier continu mee bezig zijn want als dit niet gebeurt kan het op lange termijn meerwerk creëren en alleen maar hoofdpijn veroorzaken. Een aantal voordelen van snel deployen zijn:

  • Minder uitstel van de deadline doordat features niet afhankelijk zijn van elkaar.
  • Bugs zijn makkelijker op te sporen en te isoleren doordat er vaak wordt getest.
  • Voorkomt onduidelijkheden omdat iedereen continu op de hoogte is van de voortgang.
  • Geeft de mogelijkheid om tussentijdse versies te valideren bij gebruikers.
  • Verlaagt de druk op het development team om een release te doen.

“If you are not embarrassed by the first version of your product, you’ve launched too late.”

– Reid Hoffman

Schroom dus ook niet om kleine updates er snel uit te rollen. Het vroeg releasen van versies kan een grote impact hebben op het uiteindelijke resultaat.

5. Test de applicatie en voorkom regressie

Na het opleveren van software product ben je nog niet klaar. Software is nooit af, dat betekent dat het continu doorontwikkeld kan worden maar ook zeker continu gecontroleerd moet worden om het goed te laten functioneren. Enerzijds is dit de verantwoordelijkheid van de developer, anderzijds ga je bepaalde fouten pas tegenkomen zodra de applicatie live staat en in gebruik wordt genomen. Hoe dan ook moet je als developer continu op jacht zijn naar die vervelende bugs en errors.

Voorkomen is beter dan genezen zeggen ze wel eens. In software development doe je dat uiteraard door een solide testproces. Wat je hierdoor kan voorkomen is bijvoorbeeld regressie tijdens het onderhoud van jouw software. Regressie is een nieuwe fout die ontstaat als gevolg van een bugfix op een bestaand probleem. Regressiebugs zijn vervelend en daarom beschrijven we hier een 3-stappenplan om ze uit te roeien.

  1. Unit testen; het testen van ​​individuele components of classes.
  2. Integratietesten; het testen verschillende components of packages die samenwerken.
  3. Regressietesten; het nogmaals testen van individuele components of classes na het fixen van problemen als uitkomst van de integratietest. Dit zorgt ervoor dat regressiebugs worden uitgesloten.

Haha.

Uiteindelijk is het zo dat je als developer veel meer tijd zal besteden aan het onderhouden van je code dan aan het schrijven van nieuwe code. Dat houdt simpelweg in dat je er goed aan doet om hier tijd voor te reserveren. Op de lange termijn win je hier veel tijd mee.