Om te kunnen boeken bij sneleentaxi moet javascript aan staan.

Onze geheimen gedeeld. Over de fuck-ups & successen van sneleentaxi

Een kijkje in de keuken bij sneleentaxi.

Het begon met een kleine wens naar een meertalige website. Het eindigde in een traject dat vier keer zo lang duurde dan oorspronkelijk gepland. Zowel onze front-end als onze back-end werden volledig opnieuw geschreven. Als start-up heb je compleet andere uitdagingen voor de kiezen en andere lessen te leren dan wanneer alles al in processen is gegoten.

Ik zal in een vijfdelige serie dieper ingaan op de fuck-ups alsmede ook de successen die een ombouw van oud naar nieuw met zich meebrengen. Ik heb even getwijfeld of ik al deze informatie wel zou delen, maar ik denk dat het enorm waardevolle lessen kunnen zijn voor bedrijven die in vergelijkbare situaties zitten als wij.

Om onze keuzes te begrijpen is het goed je iets meer mee te nemen in de achtergrond van ons bedrijf. We hebben een platform voor het boeken van taxi's in héél Nederland. Wanneer iemand bij ons een taxirit boekt die minimaal 6 uur later plaatsvindt, sturen wij deze reeds betaalde rit, door naar vervoerders waarvan wij weten dat die rit erg handig in hun planning uitkomt. Wij bieden deze rit in een veiling aan, waarbij vervoerders de mogelijkheid hebben om de rit tegen het tarief, dat oploopt naarmate de veilingtijd verstrijkt, te accepteren. De klant merkt hier overigens niets van. Wachten de vervoerders dus langer lopen ze het risico dat een ander deze rit accepteert en zal onze marge lager zijn. De klant krijgt vervolgens de gegevens van zijn vervoerder en wij verstrekken de vervoerder de gegevens van de klant.

Om alles in goede banen te leiden, is er inmiddels een behoorlijk complex platform aan de achterkant dat vele processen automatiseert. Een klein voorbeeld van hoe ingewikkeld zaken kunnen worden doet zich bijvoorbeeld voor als iemand een wijziging aan zijn rit wil aanbrengen. Vervoerders kunnen uiteraard niet altijd aan deze wijziging voldoen, dus moeten vervoerders eerst een mogelijkheid krijgen om op dit wijzigingsverzoek in te gaan. Mocht die niet kunnen rijden dan dient de rit opnieuw in de veiling te worden gezet. De klant dient op de hoogte gehouden te worden, maar nog niet te veel lastig gevallen worden tot het moment dat wij geautomatiseerd een nieuwe vervoerder hebben gevonden.

Dit is slechts één van de honderden uitdagingen die er zijn wanneer je een platform zoals sneleentaxi.nl volledig wilt automatiseren.

Onze geheimen gedeeld. Over de fuck-ups & successen van sneleentaxi

Hoe een eerste clash ontstond met een van onze leveranciers

Toen wij aan dit project begonnen hadden we er in eerste instantie gekozen om dit door een externe partij te laten bouwen. We schakelden een jong en enthousiast development-bureau in en dachten dat zij na enkele meetings en een briefing van letterlijk 3 A4’tjes precies wisten wat wij van hen verwachtten. Het bleek een onmogelijke klus en ook een kort huwelijk van beide kanten. We wisten zelf ook nog niet hoe complex het uiteindelijk allemaal zou worden.

Het bureau had een te krappe inschatting gemaakt qua uren en wij bleken te veeleisend qua wat er allemaal in de MVP (Minimum viable product) moest komen. Sommige details waren veel te ver uitgewerkt, terwijl we nauwelijks wisten of daar vraag naar zou zijn. Een voorbeeld daarvan was de optie om bij het boeken van een retour-rit een ander adres voor de terugweg te kunnen opgeven dan waar je vandaan boekte. Een feature die ooit een keer bedacht was door de ontwerper van de designs ter inspiratie, maar eigenlijk door ons klakkeloos werd overgenomen en uiteindelijk op het wensenlijstje kwam van dingen die "er zeker in moeten zitten voordat we live kunnen". Achteraf gezien totaal overbodig gezien dit in niet meer dan 0,2% van de boekingen voorkwam. Een optie die we later zelfs compleet hebben verwijderd om 99,8% van de bezoekers niet lastig te vallen en het zonde was van de beperkte ruimte waarin je de bezoeker wilt overtuigen om bij jou een bestelling te doen.

Sommige details waren veel te ver uitgewerkt, terwijl we nauwelijks wisten of daar vraag naar zou zijn.

Naarmate de uren van het bureau op raakten, bleven wij over met een versie die nog aan alle kanten kraakte en piepte terwijl wij onze vervoerders reeds aansluitkosten hadden gevraagd voor een platform dat nog niet live stond. Ook hun geduld raakte op en na een aantal keer de deadline te hebben verzet, besloten dat we nu een finale deadline moesten stellen. Deze kwam er, en met deze datum ook het besluit om het platform verder intern door te ontwikkelen. Het was misschien ook niet realistisch om van een extern klein bureau 's-avonds om 11 uur te verwachten dat ze direct een belangrijke bug zouden oplossen.

Voor ons kwam het neer op een compleet andere fase binnen ons bedrijf. Waar wij voorheen één developer in dienst hadden, moesten wij nu ineens gaan werken aan een intern developers-team en werden we meer en meer een techbedrijf. Hierdoor konden we veel sneller nieuwe features lanceren en het platform steeds volwassener maken. Er kwamen extra medewerkers op tech en we moesten ons ook plotseling bezig houden met het recruiten van deze talenten, want geld om recruitmentbureaus in te schakelen hadden we niet. Achteraf gezien zijn we daar heel erg blij mee, want het zorgde voor een succesvol programma om nieuw techtalenten van de hogescholen te scouten en intern hier warm te maken voor een echte job. We besparen hiermee niet alleen enorm veel kosten, maar ook kunnen we tussen de talenten nog het kaf van het koren scheiden om echt te bepalen wie er bij onze organisatie past. Inmiddels zijn er 12 developers werkzaam bij sneleentaxi.

Een verbod op nieuwe features

Met alle wensen van klanten, vervoerders, supportmedewerkers en management, werden ook de beperkingen van het platform steeds meer zichtbaar. Het development-bureau had er ooit voor gekozen om dit te bouwen in C# met als front-end omgeving Aurelia. Een onbekend framework waarvan wij toen nog niet beseften dat het ons zo zou kunnen tegenhouden in snellere ontwikkeling. Voor hen een logische keuze, met ruime ervaring binnen dit framework, maar voor ons toen nog een aspect van de bouw waar wij niet zo over na hadden gedacht. Zo lang het project maar voldeed aan onze wensenlijst waren we wel tevreden.

Een relatief eenvoudige wens was dat wij ons platform meertalig wilden maken. Hier kwamen de beperkingen van Aurelia al snel naar voren. "Het kan allemaal wel, maar écht handig gaat dat niet", stamelden de developers, die zich inmiddels steeds meer beklaagden over het gebrek aan documentatie, een community die met elkaar discussieerde en reeds gemaakte libraries die development een stuk eenvoudiger zouden maken. Als management wisten we dat het tijd werd om toch een keer op Angular over te gaan stappen. Toch voelde dat altijd als een keuze die ons snelgroeiende bedrijf even op de rem liet trappen. Nieuwe features konden namelijk niet gebouwd worden in de tussentijd en het ombouwen zou zo'n 2 tot 3 maanden in beslag nemen. Voor ons leek dat een eeuwigheid met de wensenlijst van klanten en partners die dagelijks bleef groeien.

"Nog zeker twee maanden", zeiden de developers nadat de deadline al diverse malen was uitgesteld.

Dit waren projecten zoals het boeken van ritten in héél Nederland (en niet alleen naar luchthavens zoals wij oorspronkelijk ooit waren gestart), het toe kunnen voegen van tegoed in klanten hun accounts, het veel flexibeler kunnen aanpassen van tarieven per gemeente gebaseerd op type vervoer, het ontwikkelen van een tell-a-friend systeem, het kunnen boeken op rekening voor bedrijven, en zo kan ik nog een hele werkdag vullen met projecten waarvan ik wist dat die het platform zou verbeteren maar die we dus even in de koelkast moesten zetten.

Wat we toen echter nog niet wisten is dat dit project een enorme uitloop zou krijgen. Want met het openen van de motorkap van onze software, besloten we terloops dat ook delen uit onze back-end beter geschreven konden worden en werd de deadline eerst met een maand uitgesteld. Na deze maand keken we hoopvol uit naar een nieuwe meeting met onze developers. De mededeling dat het toch "nog zeker twee maanden" zou duren bracht een lichte paniek bij ons teweeg. Het zorgde er wel voor dat er een veel betere interne communicatie ging ontstaan waarin we development & management veel meer betrokken bij onderlinge discussies. We gingen elkaars taal steeds beter begrijpen en het werd ons ook steeds duidelijker waarom het belangrijk werd om bepaalde zaken uit ons platform tijdelijk operatief te vervangen voor nieuwe onderdelen. Dat dit project het grootste zouden worden sinds we het platform gestart waren, werd daardoor ook steeds duidelijker.

Nog meer insights voor de liefhebber

In een vijfluik wil ik graag toelichten welke veranderingen ons platform allemaal heeft ondergaan en waarom we daarvoor gekozen hebben. Het kan bedrijven helpen die misschien in dezelfde fase zitten waar wij vorig jaar zaten. Ik belicht onderwerpen die duiding geven aan keuzes op gebied van;

Het deed me goed om te horen dat ook grotere bedrijven kampten met dezelfde soort vertragingen in technologische processen (leestip bijvoorbeeld: "Het geheim van bol.com"). Achteraf gezien hadden we met een betere voorbereiding ons meer gerealiseerd dat we aan een enorme klus waren begonnen, maar eerlijkheidshalve waren we er hoe dan ook toch aan begonnen. We zijn heel erg blij dat we, door een investeringsronde vorig jaar, buffer hebben gehad om deze realisatie te kunnen voltooien. Daarnaast hebben we geleerd dat door het werken nu met de laatste technologieën we nog makkelijker developers aan ons kunnen binden. Het was voor ons verrassend hoe ontzettend belangrijk talentvolle developers waarde hechten aan het werken binnen een moderne omgeving (in ons geval Angular7 i.c.m. C#).

22 Augustus volgt het tweede deel uit deze blog's over user experience verbeteringen aan het platform. Ik ben benieuwd of ik je kan behoeden voor de valkuilen waar wij in zijn getrapt of je tot inspiratie aanzet om dingen in jouw organisatie anders aan te pakken.