Een app laten maken, wij helpen klanten hier regelmatig bij, het is immers onze corebusiness. Maar dat geldt vaak niet voor de meeste mensen die een aanvraag doen. Sterker nog, zij zullen niet vaak en misschien zelfs slechts één maal in hun leven met dit soort processen te maken krijgen. We beseffen ons daarom heel goed dat het geen alledaagse projecten zijn en het niet zo eenvoudig is als het kopen van een product in de winkel. Daarom leggen we graag uit hoe wij onze iOS & Android apps ontwikkelen.
1. Kopje koffie
We beginnen zoals altijd rustig met een eerste kennismaking. We laten zien waar we goed in zijn en waar wij specifiek een meerwaarde voor het project kunnen bieden. Om ons te oriënteren op dit gesprek helpt het om alvast zoveel mogelijk concrete informatie te ontvangen waar de aanvraag precies vandaan komt.
We inventariseren op basis hiervan de problemen en we proberen alvast een beeld te vormen om zo de koers voor de ontwikkeling te kunnen bepalen.
Is er al een heel concreet concept of zelfs al wat designs en/of prototypes? Dan slaan we de volgende 2 (of soms zelfs 3) stappen over. Uiteraard niet zonder onze ongezouten mening, ideeën en adviezen te geven. Zo eigenwijs zijn we ook wel weer!
2. Brainstormen en creatieve sessies
Soms is er nog géén concrete oplossing voor het gestelde probleem. Dit is het moment waarop al onze creatieve gedachten aan het werk gaan. Meestal doen we dit binnen brainstorms of andere vormen van creatieve sessies. Idealiter doen we dit met mensen uit de doelgroep (eindgebruikers) maar als dat nog niet mogelijk is doen we dat gezamenlijk met de klant.
We bepalen aan de hand van deze brainstormsessie welke uitkomsten we het meest relevant achten en waar de meeste winst te halen valt.
3. Concept ontwikkeling
Klanten die bij ons komen hebben vaak een idee wat ze voor app willen laten ontwikkelen. Dit is echter niet altijd het geval, we krijgen ook vaak de vraag om een probleem op te lossen met software, in ons geval is dat resultaat vaak een maatwerk app met bijbehorend back-end.
Voor dit type klant ontwikkelen we concepten die goed aansluiten bij de wensen van de eindgebruikers of organisatie die de app in moet gaan zetten.
4. Prijsindicatie gevolgd door een officiële offerte
Hierna gaan we aan de slag met een eerste prijsindicatie. Deze is volledig afhankelijk van de te kiezen ontwikkelmethode: waterval (waarin processen opeenvolgend zijn, een beetje zoals deze pagina is geschreven) of agile / scrum (een ontwikkelmethode die veel flexibiliteit biedt maar ook een zekere mate van onzekerheid).
Waterval
Binnen waterval moeten we afspreken wat we gaan opleveren en hier consensus over bereiken. Welke functionaliteit zit er in de app? Op welke platformen zal de app komen te draaien? Wilt u een iPhone (iOS) app laten maken, een Android app laten maken, of misschien wel allebei? Welke devices worden er ondersteund? Smartphones of ook tablets?
Dergelijke vragen worden vaak in de eerste gesprekken al helder voor ons, zo niet dan helpen we bij het maken van de juiste keuze.
Op basis hiervan stellen we een eerste prijsindicatie op. Als de prijsindicatie aansluit bij de wensen werken we deze verder uit tot een officiële offerte. Zo niet? Dan passen we het aan tot we overeenstemming hebben over de specificaties en komen we tot een fixed-price.
Mocht gedurende het traject toch de wens ontstaan om zaken te wijzigen of toe te voegen vangen we dat onder meerwerk. Hier kunnen we eenvoudig concrete offertes voor opstellen, zeker als we al helemaal ingewerkt zijn in het project.
Agile / scrum
Bij agile / scrum trajecten staat de scope niet vast. Uiteraard kunnen we wel een fixed-budget afspreken en een spreekwoordelijke "stip op de horizon" zetten. Waar willen we ongeveer gaan eindigen? Welk probleem moet het eindproduct uiteindelijk gaan oplossen? Het is echter niet vooraf concreet gemaakt zoals we bij een waterval proces wel doen.
We managen het project en de klanten ook op een andere manier. Zij worden hierin volledig onderdeel van het project en bepalen meer de koers. Wij helpen daar gedurende het ontwerpen en ontwikkelen bij.
Meer over agile / scrum
Welke afweging maken we voor waterval of agile?
Hoe meer er bekend is over de specifieke wensen aan het eindproduct hoe meer het project zich leent voor een waterval methode. We kunnen dan een concrete scope aan functionaliteit definiëren. Hoe minder er bekend is over het eindproduct, hoe meer het project zich leent voor een agile / scrum traject omdat je daarin gaandeweg nog eenvoudig kunt wisselen van koers.
Kort gezegd: hoe concreter de functionaliteit omschreven is, hoe concreter de offerte en prijsindicatie zullen worden.
5. Bepalen van UX design
Het bepalen van de interactie, ook wel UX (user experience) design of interactieontwerp genoemd. Hierin bepalen we welke plek de app of het platform gaat krijgen in de klantreis (customer journey) en welke rol die zal innemen.
Tijdens dit proces komen we concreet op alle functionele vragen. Denk hierbij aan het moment van vragen om toestemming tot push-notificaties of hoe je bepaalde onderdelen van de app kunt bereiken.
We kunnen dit proces volledig intern uitvoeren. Soms hebben onze klanten echter al een ontwerpbureau of zelfs interne ontwerpers, we hebben veel ervaring met het werken met externe designers. Als /app-ontwikkelaar-rotterdam merken we wel dat een app ontwikkelen een vak apart is, we sparren dan ook graag in dit stadium van het project al over de mogelijkheden en kaarten eventuele problemen die wij constateren alvast aan.
6. Bepalen van UI design
Het definiëren van de visuele stijl van de interface, ook wel UI (user interface) design of visual design genoemd.
Eventueel kunnen we tijdens dit proces ook brand design uitvoeren indien er nog helemaal geen stijl of merk is van de app. We ontwikkelen dan een merk wat aansluit bij de doelgroep en zetten dat om in een herkenbare visuele stijl.
Ook bij het bepalen van het UI design hebben we ervaring in het werken met externe designers, we voeren zelfs vaak app ontwikkeling als losse dienst uit voor creatieve bureaus. Omdat we het proces ook zelf in huis hebben kunnen we goed communiceren met dergelijke partijen en weten we wat zij van ons nodig hebben om een optimaal design aan te leveren.
7. Ontwikkeling back-end en API's
Niet ieder project bevat een back-end maar in 95% van de gevallen is dit wel het geval. Apps moeten namelijk in de meeste gevallen wel data uit één of meerdere externe bronnen binnenhalen en middels een back-end kunnen we dat gecentraliseerd verwerken en distribueren.
Na overeenstemming van het project gaan we dan ook zo snel mogelijk aan de slag met het ontwikkelen van de back-end en de bijbehorende API's (data koppelingen). Tijdens back-end development komen namelijk altijd alle details van het project naar boven en weten we exact wat we aan de kant van de app nodig gaan hebben.
Onze back-ends worden ontwikkeld in de programmeertaal Elixir. Ondanks dat onze stack veel breder is dan Elixir (PHP, Python, Javascript et cetera) hebben we ervaren dat een functionele programmeertaal veel beter aansluit bij de huidige paradigma's van het internet.
Voor app ontwikkelaars geldt ook dat zij eigenlijk niet goed kunnen starten met hun werk zolang het back-end niet definitief is. Dit is helemaal het geval als de back-end extern wordt ontwikkeld. Wij schrijven in dat geval dan meestal de API documentatie, daarin zetten we wat we voor reacties uit het back-end verwachten, zodat we zelf alvast verder kunnen met het ontwikkelen van de app.
8. Ontwikkeling app(s)
Als app ontwikkelaar is dit voor ons de leukste tijd, we gaan hard aan de slag met het concreet maken van de app en wekken de app tot leven.
Dit proces loopt meestal iets achter op de ontwikkeling van het back-end en de API zodat we niet iedere feature op elkaar hoeven te wachten. We hebben tijdens het concept bepaald voor welke platforms de klant de app wil laten ontwikkelen. Soms ontwikkelen we iPhone / iPad apps, soms enkel Android apps maar ook regelmatig universele apps die voor beide platformen geschikt zijn.
Tijdens dit proces zullen we onze voortgang zoveel mogelijk laten zien maar enkel wanneer dit zinnig is. Voor ons is het immers makkelijker om te zien wat er tijdens een proces nog mist dan voor onze klanten.
9. Testen
Tijdens het project zullen we op zinnige momenten vragen aan de klant om mee te testen. Enerzijds om te laten zien wat we hebben ontwikkeld maar ook om te kijken of alles duidelijk is en (nog) aansluit bij de initiële wensen en afspraken.
Deze testversies zullen tijdelijk functioneren en zijn vooral bedoeld om te kijken of alles naar behoren werkt. Het heeft in dit traject dan ook nog weinig zin om "echt" gebruik te gaan maken van de app. Het doel van deze fase is vooral: kijken of de app stabiel werkt, of er geen vreemde bugs optreden en of alle functionaliteit er in zit.
10. Acceptatie en oplevering
Acceptatie gebeurt na het goedkeuren van de laatste testversie waarna we een traject van oplevering in gaan. Oplevering van de app gebeurt vrijwel altijd in de App Store of Google Play. We begeleiden dit totale proces van inrichten van de omgeving tot het uiteindelijk insturen van de apps. Er gelden ook verschillende wat regels op deze platformen waar we inmiddels zeer bekend mee zijn.
Als apps enkel voor intern gebruik zijn distribueren we ze via een Enterprise omgeving zodat alleen geautoriseerde gebruikers of devices de apps kunnen installeren.
11. Nazorg
Na het opleveren in de App Store staat alles live. Daarna gaat de app door het grote publiek gebruikt worden. Dit levert potentieel problemen op die we niet voorzien hebben tijdens het ontwikkelproces. Zeker voor Android kunnen we niet alle uitzonderingen testen (Android draait op te veel verschillende systemen) waardoor we hier pas later feedback op krijgen, vaak vanuit de eindgebruikers. We zien deze problemen overigens ook terug in onze analyse software zodat we snel kunnen anticiperen.
In de nazorg fase lossen we deze eventuele problemen zo snel mogelijk op. Onderhoud en doorontwikkeling
Als de oplevering echt definitief is — en alle problemen van de gelanceerde versie dus zijn opgelost — gaan we het traject van onderhoud en/of doorontwikkeling in.
Gedurende het project bepalen we of er een onderhoudscontract, ofwel Service Level Agreement (SLA) nodig is en geven we een indicatie van de eventuele kosten. Deze hangen vooral samen met de mate van support die we gaan leveren op het eindproduct. Gaat het puur om de app van updates te voorzien of moeten we ook vragen vanuit gebruikers opvangen en uitgebreide support leveren?
Ook kunnen we vanaf het moment van oplevering bepalen welke functionaliteit er doorontwikkeld dient te worden. Dit kunnen uitbreidingen zijn maar ook optimalisaties van bestaande functionaliteit, zodra gebruikers met de app aan de slag gaan is de kans groot dat zij feedback zullen geven.
