Cross-platform ontwikkeling bij Gamebasics

20 juni 2016

Rob Staring is student MSc Management of Innovation aan de Erasmus Universiteit Rotterdam. Hij onderzoekt de implicaties en succesfactoren bij het ontwikkelen van een product voor meer dan één platform. Hiervoor interviewde hij Jeroen Derwort, oprichter van Gamebasics. Hij vroeg hoe het bedrijf omgaat met de gelijktijdige ontwikkeling voor iOS, Android, web en Facebook.

RS: ‘Eerste vraag: “Kan je een korte introductie geven over Gamebasics en OSM (red. Online Soccer Manager)?”
JD: Gamebasics is het bedrijf dat OSM maakt. Wij hebben de missie om alle voetballers wereldwijd, manager van hun favoriete voetbalclub te maken. Online Soccer Manager is de manier waarop Gamebasics dat doet. De game/ app wordt door meer dan vier miljoen mensen wereldwijd gespeeld. Waarin ze dus manager van hun favoriete voetbalclub kunnen worden, ook een andere voetbalclub trouwens. We werken hier met 40 mensen aan het spel. Dat zijn programmeurs, maar ook marketeers. Want het adverteren en bekend maken van het spel doen we zelf.

RS: ‘In hoeverre is de OSM app jullie core business, hoe ligt dit in verhouding tot de website?’
JD: Als je het vergelijkt met de website: het is hetzelfde spel dat via vier verschillende platforms wordt aangeboden. Het is één spel, en dat is het enige wat we doen. Dat is 100% van onze business. Als je het splitst in website en apps, dan is het ongeveer 80% apps.

RS: ‘In hoeverre sta jij als CEO achter het idee van een app? Want jullie zijn begonnen met een website.’
JD: Ja, dat is denk ik, één van de belangrijkste dingen die wij hebben gedaan in de afgelopen jaren. In 2012 zijn de apps gelanceerd en sinds die tijd is meer dan 80% van de gebruikers overgegaan van de website naar de apps. De website is er nu om de apps te ondersteunen. Eerst was dat andersom. Het beweegt nog steeds, maar ik denk niet dat we helemaal geen website meer zullen hebben. Bij OSM 3 hebben we ook geïnvesteerd om een nieuwe website te bouwen, maar de rol is wel anders dan daarvoor.

RS: ‘Denk je dat de apps in de toekomst belangrijker zullen worden?’
JD: ‘Ik denk dat het in de toekomst naar 90% of misschien wel 95% appgebruikers zal gaan.

RS: ‘Waarom denk je dat dat is?’
JD: Het belangrijkste is de toegankelijkheid, dat mensen het altijd bij zich hebben. Dat ze push notificaties krijgen en gemakkelijk kunnen installeren. Het installeren zelf is wel een drempeltje, maar als je de app eenmaal geïnstalleerd hebt, blijf je die gebruiken, dat is een voordeel. Voor een website moet je een browser openen. Op een mobiel device is dat minder goed geïntegreerd, of je moet achter een pc gaan zitten. Dat is niet meer de manier hoe mensen gewend zijn om een game te spelen. Dat was 5 á 6 jaar geleden normaal. Gamebedrijven die het nog wel via de browser blijven doen, hebben gigantische problemen gekregen. Een grote concurrent van ons, Hattrick, was toen OSM begon het grootste voetbalspel ter wereld. Zij zijn heel lang de grootste gebleven, maar nu is het bijna niks meer, omdat zij geen app hebben ontwikkeld en er voor hebben gekozen om alleen hun website te houden, toen was het afgelopen. Dat is niet het enige voorbeeld; in Nederland heb je Spill Games. Op web nog steeds heel groot, maar toch een stuk minder. Het is, zeg maar, veel minder groot. Die richten zich nu ook op mobiele apps. Ze kunnen niet anders.

RS: ‘Jullie hebben nu weer vernieuwde apps, hoe zijn jullie op dat idee gekomen, van ontwikkeling tot aan de lancering?’
JD: Daar ging heel wat aan vooraf. Wij hadden drie grote wensen, die moeilijk uit te voeren waren. Toen hebben we besloten om daar één iteratie van te maken. Dus één hele grote update, omdat het ingrijpende dingen zijn. Normaal gesproken werken we liever met kleinere incrementele stappen. Dat was in dit geval heel erg lastig. De drie wensen waren: licenties, een nieuw verdienmodel en mobile first ontwikkeling, dus het spel zo maken dat het beter past bij de mobiele wereld. De timers die nu in de app zitten zijn een voorbeeld. Die ideeën hadden we al liggen, maar die konden heel moeilijk ingevoerd worden. Toen hebben we besloten dat we opnieuw moesten beginnen, om deze wensen er goed in te krijgen. Die ontwikkeling heeft 1,5 jaar gekost.

RS: ‘Die ideeën, die drie wensen, hoe zijn jullie daarop gekomen?’
JD: Een beetje wisselend. Die licenties zijn iets wat we al wilden doen sinds de start van OSM, maar daar heb je financiële mogelijkheden voor nodig. Die hadden we opgebouwd om een deel van de licenties te kopen. Daar zijn we toen mee begonnen. In de marktcijfers zag je dat de concurrentie het qua verdiensten veel beter deed dan wij. Daar hebben we dus wat aan gedaan, door het nieuwe verdienmodel te implementeren. Daarnaast hadden we hele stapels met ideeën m.b.t. het mobile-first maken van de game. Die konden we meteen meenemen in de nieuwe versie.

RS: ‘Ik zag op jullie website dat jullie verschillende teams hebben. Development maar ook marketing. Hoe werken die samen bij het ontwikkelen van features?’
JD: We hebben twee marketing teams. Het eerste team is acquisition en revenue. Die zijn vooral bezig met binnenhalen van nieuwe spelers en verdienen aan spelers. Een ander team is Retention, die houden zich bezig met alles wat te maken heeft met hoe we gebruikers kunnen behouden. De marketeers zijn ook belast met het uitdenken van features, hoe het moet werken. Bijvoorbeeld de Boss Coins; hoeveel mogen ze kosten en hoeveel zouden mensen daarmee doen. Dat komt allemaal bij hen vandaan. Het wordt uitgewerkt, waarna het naar de development teams gaat. Die gaan het echt bouwen. En elk platform heeft een eigen team.

RS: ‘Je geeft het zelf al aan, er is dus sprake van cross-functionele teams?’
JD: Ja wij werken met scrum, dus we hebben scrum teams. Die bestaan uit ontwikkelaars, een tester, een designer en een product owner. Ook de marketing teams werken agile, met verschillende disciplines in één team.

RS: ‘Eén team is dus bezig met een specifieke taak zoals je die zojuist aangaf?’
JD: De ontwikkeling van de app op een platform. Die krijgen dan weer input via de backlog, en de backlog wordt gevuld door o.a. de product owner in samenwerking met de marketing teams.

RS: ‘Voordat jullie beginnen met ontwerpen, op welke manier brengen jullie de markt in kaart? Zijn er verschillen tussen iOS en Android?’
JD: Ja, absoluut. Er zijn hele grote verschillen, helemaal als je web en Facebook ook mee telt. Dat werkt heel anders. Maar Android en iOS zijn ook heel verschillend van elkaar in veel opzichten.

RS: ‘Waar zie je die verschillen in terug?’
JD: Je ziet die verschillen in ontwikkelomgeving en het gedrag van gebruikers. Android staat erom bekend dat er veel verschillende handsets zijn. Dus dat is een complicerende factor. Het platform is minder goed ontwikkeld, in vergelijking tot Apple. Maar het is wel veel opener. Het is makkelijker om mensen te werven die Android ontwikkelaar zijn, terwijl eigenlijk, als je allebei gedaan hebt, dat je een voorkeur zou moeten krijgen voor iOS. Maar veel developers weten dat niet, of zien het als een drempel dat je €100 moet betalen om developer te worden. Wat we ook zien is dat ontwikkeling van de native app op Android anderhalf keer zo lang duurt dan bij iOS, ondanks dat we bij iOS drie developers hebben en bij Android vijf. Het zijn allemaal hele goede developers, dus daar ligt het niet aan. Het platform is lastiger ja, het testen duurt langer en je hebt meer issues. Het platform is gewoon minder stabiel. De ontwikkelomgeving is een beetje gaar. Ik snap het nooit zo goed, als je kijkt naar de miljoenen die erin om gaan. Het heeft blijkbaar even tijd nodig, het wordt wel steeds beter. Toen we net begonnen was het dramatisch, maar nu is het al minder dramatisch.

RS: ‘Dat is interessant wat je zegt, dat er verschillen zitten tussen de platforms. Is dat organisatorisch ook zo? Welke stappen zijn daarin belangrijk geweest?’
JD: Voordat we begonnen aan dit project hebben we een nieuwe indeling van de teams gemaakt. En hebben we elk team dedicated gemaakt voor een platform. Daarvoor hadden we één mobiel team voor zowel Android als iOS. Het nadeel daarvan is dat je geen echte specialisten hebt. Dat nadeel was in het begin niet zo aanwezig, omdat iedereen het nog moest leren. Maar naarmate het project steeds groter werd, liepen we dat risico. Het is ook niet te doen om mensen te vinden die het allebei kunnen. Dat maakt het moeilijker om mensen te werven. Daarnaast waren er designers en die waren een apart team. Die hebben we juist ondergebracht in de development teams. Dat heeft geholpen om ze wat dichter bij de developers te krijgen. In het begin was het niet gemakkelijk. De nieuwe teamindeling ging niet zonder slag of stoot. Het heeft veel tijd gekost. Maar het resultaat is uiteindelijk goed. We hebben nu teams die verantwoordelijk zijn voor hun eigen platform, zoals het Android team. Die maken zelf de backend niet, maar voelen zich wel verantwoordelijk als er iets niet goed is in de backend, wat hun platform raakt. Zo is het bij iOS ook. Ze kijken ernaar of het platform goed gaat, zo niet dan schakelen ze mensen in die ze nodig hebben om het goed te krijgen.

RS: ‘Dus je geeft aan dat het maken van dedicated teams belangrijk is bij verschillende platforms?’
JD: Ja. Waar we in het begin de mist mee zijn ingegaan, hebben we later gecorrigeerd. Dat heeft veel energie gekost, maar heeft wel resultaat gehad. Omdat we native ontwikkelen, heb je in principe drie keer hetzelfde product; voor Android, iOS en web. Dat is heel vervelend, want je moet alles drie keer ontwikkelen. Dat wil eigenlijk niemand, maar we doen het toch omdat we dan een heel mooi product krijgen op dat platform, wat gebruik kan maken van alles wat dat platform te bieden heeft. Wat je in het begin heel erg zag waren verschillen tussen de platforms. Omdat we elk team hun eigen platform hebben gegeven, en die teams het moeilijk vonden om hun autonomie te bepalen. Ze gingen alles op hun eigen manier doen. Daardoor konden ze informatie niet met elkaar uitwisselen en de apps waren fundamenteel anders. Wat voor telefoon heb jij?

RS: ‘Ik heb een Android telefoon. De Nexus 5x.’
JD: Als je OSM opent op je telefoon en je kijkt naar het dashboard, dan ziet het er anders uit dan op iOS. De veranderingen die je nu ziet, zijn subtiel en gedaan om tegemoet te komen aan de specifieke gebruikerservaring die bij het platform past.

*RS & JD vergelijken het beeld van OSM op de iPhone met Android *

JD: Je ziet het al, het beeld is een klein beetje anders. Op het eerste oog ziet het er hetzelfde uit, alleen in het begin was op iOS het dashboard wit. Dat hebben we gelijk getrokken met Android. Ook heb je deze optie (het vegen van menu’s binnen het hoofdscherm, red.), dat is typisch iets van iOS, die bolletjes. Die zijn native ondersteund. Dat zijn de goede dingen die er nu nog inzitten. Maar zo zijn er tientallen verschillen en de teams gingen die dingen heel anders aanpakken. Niet altijd omdat het beter was, maar soms ook omdat iemand in de teams het mooier vond. Daar moesten we mee stoppen want dat betekent dat je twee keer een design moet maken, het twee keer getest moet worden, dat je geen ervaring meer kan uitwisselen. We zijn eenduidiger geworden, teams moesten overleggen met elkaar. Dat hebben we na een tijdje weer ingebouwd. We zagen redelijk snel dat product owners van beide teams regelmatig overleg met elkaar moesten hebben en dat de designs gedeeld moesten worden tussen de teams.

RS: ‘Je vertelde dat jullie native ontwerpen. In hoeverre wordt er samengewerkt tussen de verschillende platformen en draagt dat bij aan het succes van jullie app?’
JD: Wat we nu doen is een feature ontwikkelings process, waarbij het heel veel aan het begin doen. Er worden wireframes gemaakt en teams gaan het al bekijken. De feedback wordt dan teruggekoppeld. Als we echt tevreden zijn dan gaan we het aan de teams geven om het in te bouwen, je weet dus al in hoofdlijnen hoe het gaat worden in de apps. Er gaan geen grote verschillen ontstaan. Deze manier van werken heeft heel erg geholpen, want daarmee wordt de snelheid van het ontwikkelen veel beter. Je hebt alle input van iedereen gebruikt. Je hebt iets meer tijd gestoken in de voorbereiding, maar dat scheelt later weer. Sommige teams hadden in het verleden iets 2 of 3 keer ontworpen, omdat later bleek dat het niet goed was, en ze opnieuw moesten beginnen. Daar hebben we van geleerd.

RS: ‘Ik heb me een beetje in het ontwerpen verdiept en weet dat je bijvoorbeeld ook hybrid apps kan ontwikkelen. Wat voor voordelen heeft het voor jullie om voor twee platformen apart te ontwerpen?’
JD: Het belangrijkste voordeel is dat je heel dicht op het operating system zit. Je kunt van alles gebruik maken van wat dat OS te bieden heeft. Wat je vaak ziet bij hybrid apps is dat de mogelijkheden kleiner zijn, omdat je het minste device is bepalend wat je kan doen. Wij kunnen op Android gebruik maken van alles wat Google bedacht heeft en in Android gestopt heeft. Voor iOS geld dat nog meer, daar zitten heel specifieke dingen in die voor iOS zijn bedacht door Apple. Vaak is het ook lichter, al is dat ook afhankelijk van je eigen efficiency. Je ontwikkeld met de tools van Apple en Google zelf, dat zit in het OS, dat hoef je niet meer met de app mee te sturen. Daar wordt die sneller en soepeler van. Dat zie je, denk ik, ook terug in de app; dat hij goed werkt. Dat zijn de voordelen die je hebt.

RS: ‘En de nadelen?’
JD: Je moet alles twee keer doen. Er waren wat nadelen waar we niet bewust van waren tijdens de ontwikkeling. Een van die nadelen is dat je, om al die leuke toeters en bellen te kunnen gebruiken van Android en Google, je moet meegaan met hun OS versie. Als je Unity of PhoneGap gebruikt, dan is de versie van het OS niet zo belangrijk, dan zit in de toolkits zelf wat je kan en niet kan. Er zijn apps die iOS 6 ondersteunen en die prima in elkaar zitten en mooie dingen kunnen. Maar als wij die animaties willen gebruiken, moeten we ons beperken tot iOS 8 of 9 en dan vallen er gebruikers af die nog een oude OS versie hebben. Elke keer dat Apple of Google met een nieuwe versie voor hun OS komt, zitten er hele coole dingen in. Maar het duurt misschien wel twee jaar voordat dat iedereen over is. Wij moeten twee jaar terug in de functies die wij mogen gebruiken. Anders verliezen wij gebruikers. Daar moeten we ons dus bewust van zijn.

RS: ‘En het design, werkt apart voor beide platforms?’
JD: Deels. Dat is een voordeel dat we nu hebben, dat je verschillen kunt aanbrengen per design. Op iOS heb je altijd een terug knopje nodig, bij Android zit die al op je telefoon. Dat soort dingen kun je meenemen als je native ontwikkelt. Bij een framework kan je dit ook invoegen, maar dat is lastiger.

RS: ‘In hoeverre is het belangrijk dat beide apps op elkaar lijken?’
JD: Dat is niet het belangrijkste, maar de gebruikers experience moet wel hetzelfde zijn op iOS en Android. En je moet zoveel mogelijk ontwerpen delen. Het zou niet efficiënt zijn als je dat niet zou doen, dat is gewoon verspilling van resources. Wij zijn al met 42 mensen en zouden naar 100 mensen moeten, als we niets delen. Die kant willen wij dan ook niet op. Het moet wel efficiënt blijven. Als wij een hele mooie feature ontwikkelen, moeten we dat één keer doen en niet drie keer.

RS: ‘Maar implementeren ze het tegelijk, of apart zodat het andere team ervan kan leren?’
JD: Meestal apart. Hoe het vaak gaat is dat het iOS team bijvoorbeeld een feature ontwikkelt, die naar beste inzicht wordt ingebouwd in iOS. Ze kunnen daarna de feedback en data daarvan zien, en dan kan Android daarvan leren. Als zij dat gaan bouwen, kunnen ze verbeteringen aanbrengen. Dan gaan die weer terug naar iOS. Er zit wel een klein beetje competitie in, wie dat het snelste en beste kan. Dat is het soort mensen dat hier werkt. Maar je moet elkaar juist helpen. Het webteam is verantwoordelijk voor de hele backend. De backend raakt iedereen en dat is iets waar iedereen zich druk over moet maken.

RS: ‘Wat bedoel je met de backend?’
JD: Dat is bij ons de wedstrijdengine, de api en ook de databases met gegevens die in de app naar voren moeten komen.

RS: ‘Worden de consumenten betrokken?’
JD: Ja, bij het testen halen we de consumenten naar binnen. In een UX lab en met eye-tracking testen we de apps zodat we daar van kunnen leren.

RS: ‘Dit gebeurt voor alle platformen?’
JD: Ja. Alle drie de platformen apart. Dat doen we ook om ze met elkaar te vergelijken. Soms denk je dat er geen verschillen zijn, maar als consumenten ze dan gebruiken, zie je toch kleine verschillen, die impact hebben. Zoals bijvoorbeeld het gebruik van timers en notificaties. Daar kun je weer van leren.