Business case: De spanning erin houden

07-11-2020

3 minuten

Koen

Een Nederlandse scale-up is al een tijd bezig met prototype ontwikkeling van slimme accu’s. Deze accu’s zijn uitermate geschikt voor “high-demand” toepassingen waarbij actieve monitoring van spanning, voltage en de levensduur van de accu van groot belang zijn. Denk hierbij aan raceauto’s, motorjachten, luxe caravans et cetera. Een high-end accu voor een high-end markt. Eén van de USP’s van de accu is de meegeleverde mobiele app die actief de accu kan uitlezen en de gebruiker van belangrijke data voorziet én de mogelijkheid om meerdere accu’s aan elkaar te schakelen. Deze worden dan gezien als één grote accu.

Het prototype werd grondig getest en een eerste productierun is uitgerold. Enkele honderden geselecteerde “early adopters” ontvingen hun slimme accu. En toen ging het mis. Veel gebruikers klaagden over wegvallende verbindingen, de app die niets registreerde of juist vreemde waardes teruggaf. Ook het koppelen van meerdere accu’s werd niet geregistreerd door de app. Waar de accu’s zelf prima presteerde liet de software het afweten. De eerste lancering dreigt uit te lopen op een fiasco.

01. De casus

Hoe dit zo kon lopen? De mobiele app is in-house ontwikkeld door een absolute whizzkid die ook medeoprichter was van de scale-up. Waar deze ontwikkelaar uitblinkt in kennis van hardware en embedded softwareontwikkeling, is de ontwikkelaar niet echt bekend met het ontwikkelen van een mobiele app. Daarnaast stond deze ontwikkelaar bij het ontwikkelen niet in contact met de klant en werkte hij slechts drie dagen per week.

Uiteindelijk bleek de gebruikte hardware slechts te kunnen werken met een specifieke bluetooth implementatie. Hierbij ontstond een behoorlijke bottleneck met betrekking tot de snelheid van dataoverdracht tussen de accu en de mobiele telefoon. Ook bleek dat niet alle mobiele telefoons deze bluetooth standaard ondersteunden. Het bereik van de bluetooth implementatie was ook minder groot. Dit verklaart het niet kunnen verbinden met de accu, het wegvallen van de verbinding en de soms vreemde waardes die worden uitgelezen.

02.  Nieuw gereedschap

Om een fiasco af te wenden besluit de scale-up om de app opnieuw te ontwikkelen. Ze schakelen extra ontwikkelaars in via Young_Coders die gewend zijn om met meerdere programmeertalen en omgevingen te werken. De nieuwe app ontwikkelen ze in een programmeeromgeving waarbij eenvoudig dezelfde broncode naar de diverse mobiele besturingssystemen kan worden uitgerold zonder dat een update van de app nodig is. Op een zo laag mogelijk niveau wordt er een maatwerk bluetooth bibliotheek geschreven zodat de ontwikkelaars zelf kunnen gaan experimenteren met het opvoeren van de overdrachtssnelheid en stabiliteit van de verbindingen. Daarnaast wordt een feedback functie in de app gebouwd zodat klanten direct problemen kunnen melden via de app. Om de uitgelezen data te valideren wordt een globale database uitgerold. Deze dient als buffer om vervolgens de data uit de accu op de juiste manier te tonen en de dataoverdracht netjes uit te laten lopen. Uiteindelijk wordt er gebruikt gemaakt van iOnic framework, Typescript, C++, Assembly, MongoDB en Laravel voor de ontwikkeling.

03. Hoe helpt Young_Coders

Young_Coders leidt jonge, enthousiaste HBO’ers en WO’ers op diverse rollen in de technology branche. Doordat wij onze mensen altijd blijven uitdagen noemen wij ze “Challengers”. De Challengers die Young_Coders opleidt en begeleidt, worden zoveel mogelijk “code-agnostic” of “language agnostic” opgeleid. Dit betekent dat wij onze Challengers alles leren over programmeerconcepten. Als je de concepten begrijpt zijn deze relatief eenvoudig toe te passen op meerdere programmeertalen. Je hoeft dan alleen nog maar de syntax te leren. Door gebruik te kunnen maken van verschillende programmeeromgevingen kan een ontwikkelaar het juiste gereedschap voor de juiste klus kiezen. Dit bevordert de snelheid van ontwikkelen. Ook bevordert het vaak de performance van de te ontwikkelen oplossing.

04. HET RESULTAAT

De vernieuwing van de mobiele app is via het MVP (Minimal Viable Product) principe ontwikkeld. De eerste release was de introductie van de nieuwe gebruikersinterface en het stabiliseren van de bluetoothverbinding. Door de problemen in het primaire proces direct op te lossen in de eerste release werd de mobiele app direct meer gebruikt, waardoor er ook weer meer feedback en waardevolle gebruikersdata werd gegenereerd. 

Door deze data te gebruiken in de opvolgende releases van de mobiele app werden stap voor stap de functionaliteiten toegevoegd waar de gebruikers van hadden aangegeven deze te willen hebben. De gebruiker werd dus centraal gesteld.  Uiteindelijk heeft deze aanpak ervoor gezorgd dat de officiële lancering van het product met de app naar voren is gehaald en het product dus eerder op de markt kon worden gebracht dan was verwacht. Dit was een positieve ontwikkeling voor zowel de klanten als de aandeelhouders van de scale-up. Er werd eerder omzet gemaakt zodat de ROI van het product hoger uitviel.

Herken jij de uitdagingen in deze case? Neem contact op, wellicht kunnen we elkaar verder helpen. 

CONTACT

Dan spreken we elkaar snel. 

Koen

Koen

Koen is marketeer en communicatiespecialist. Hij schrijft over o.a. Design Thinking, de IT-arbeidsmarkt en innovatie.