Maak van je app geen Multipla! Zo wissel je van app-ontwikkelaar

Een chassis laten maken door Ferrari en de aankleding door NASA. Dan krijg je niet bepaald een mooie auto, eerder een Fiat Multipla. Dat geldt net zo goed voor apps. Als je de ene ontwikkelaar je app laat ontwikkelen en een ander het onderhoud laat doen, kun je met een ongewenst resultaat eindigen. Van lichte afwijking tot verschrikkelijk gedrocht. Om dat te voorkomen, gaan we ernaar kijken hoe je het beste je overstap maakt en hoe je de oorzaak voor deze overstap voor bent!

Lees het artikel hieronder of bekijk deze video:

App ontwikkelaar wisselen multipla david video

 

1. Hoe gaat het overzetten naar een nieuwe ontwikkelaar?

Je hebt een bestaande ontwikkelaar, hopelijk met een goede zakelijke relatie. Óf jullie vechten elkaar het kot uit. Hoe dan ook, je zit eraan te denken om over te stappen. Wat heb je nodig om over te stappen? 
 

  • Broncode, de achterliggende code van de app. Zonder deze code ben je nergens en kun je opnieuw beginnen met je appverhaal.
  • Servergegevens. Alles wat al is opgeslagen van gebruikers en de inhoud van de app.
  • Hulp bij overdracht; toestemming en medewerking van je oude partij. Belangrijke voorwaarde om überhaupt over te kúnnen stappen naar een andere ontwikkelaar.
  • De werkmethode moet overeenkomen; bijvoorbeeld dezelfde projectmanagement methode zoals scrum agile. Dat scheelt een hoop aanwennen.
  • Programmeertaal moet identiek zijn, of een waar de nieuwe ontwikkelaar mee uit de voeten kan. Ook de kwaliteit van deze code doet ertoe, en de documentatie ervan; waar staat wat? 

Hierna moment van overdracht waarop app live gaat bij een andere ontwikkelaar. Veel werk vooraf maar ook achteraf om het je app draaiende te houden. 
 

2. Waarom is overzetten zo lastig? 

Een app overhevelen komt niet even aanwaaien. Hoe komt dat? En wat kun jij er aan doen om die problemen te voorkomen? Geen zorgen, ik help je een eind op weg. Daarom begin ik hieronder met de 4 valkuilen en oplossingen. 
 

2.1 Onverwachte kosten

Valkuil: Nieuwe ontwikkelaars moeten helemaal gaan doorgronden hoe de app is opgebouwd. Afhankelijk van de kwaliteit van de oude en de nieuwe ontwikkelaar, gaat hier veel tijd en dus geld in zitten.

Oplossing: tijd vrijmaken voor 'code review'. Geen dagje, maar enkele weken waarin je de nieuwe ontwikkelaar de tijd geeft om jouw app van a tot z te begrijpen, om extra werk later te voorkomen.

2.2 Fouten bij het overzetten

Valkuil: Door andere inrichting of technische verschillen kan de app tijdens het overzetten op fouten lopen. Oftewel, de app werkt niet meer correct

Oplossing: Begin met een uitgebreid testtraject. Zorg ervoor dat je goed de tijd neemt om jouw app grondig te laten testen, voordat je deze live laat gaan bij je nieuwe ontwikkelaar. Houd er rekening mee dat dit wel 10-20% van de originele ontwikkelingskosten met zich mee kan brengen.

2.3 Ontwikkelaar niet gemotiveerd

Valkuil: Deze reden is simpel: de nieuwe ontwikkelaar verdient niet veel aan app overnames. Het meeste geld zit in de ontwikkeling, niet zozeer in de service erna. Daarnaast zijn ontwikkelaars meer te prikkelen voor nieuwe projecten met 'spannende' technologie. Een bestaand project waar weinig tot niets aan gedaan hoeft te worden is voor de werknemers van het bedrijf nou niet bepaald spannend of motiverend. 

Oplossing: zorg met de overdracht ook voor een uitdaging en inkomstenbron voor de nieuwe ontwikkelaar. Bijvoorbeeld met doorontwikkeling, waarmee de ontwikkelaar weer aan de slag kan.

2.4 Problemen met onderhoud

Valkuil: Door te kort testen of te weinig tijd te besteden aan het laten begrijpen van de app, kunnen onvoorziene problemen ontstaan met het onderhoud van de app. Dit heeft dus te maken met punt 1 en 2, maar waar die gaan over de daadwerkelijke overdracht, zorgen die dus bij slechte aanpak voor meer problemen further down the line.

Oplossing: maak geld en tijd vrij om ook na de aanvankelijke overdracht alles zo goed mogelijk op orde te hebben, voordat er daadwerkelijk onderhoud wordt gepleegd. 
 

3. Achterliggende redenen voor lastig wisselen van ontwikkelaar

Dus, je hoort het. Het kost je extra tijd en geld om je app goed over te zetten. Tot wel 50% van de oorspronkelijke ontwikkelkosten. Dat is een flinke duit. En dat doe je allemaal om ervoor te zorgen dat je achteraf niet nóg meer geld en tijd kwijt bent aan problemen (bugs, offline geraken, etc.). Ik heb het vaker gezien tijdens of na je overstap naar een nieuwe ontwikkelaar, en dan ben je nóg verder van huis. Laat het overigens niet ongezegd zijn dat die nieuwe ontwikkelaar alsnog gewoon z'n beste beentje voor heeft gezet.

Hieronder biedt je daarom wat alternatieven aan, zodat je kosten kunt besparen. We kijken daarom eerst naar de reden dat je wil overstappen, voordat we dat ook echt gaan doen.

3.1 Schaalvergroting of professionalisering

Als je vindt dat je met je app toe bent aan een groter of professioneler bedrijf, hoeft dat nog geen overstap te betekenen. Als je werkt met een klein bureau of freelancer, kun je ook kijken naar de mogelijkheid om het bureau of de freelancer in dienst te nemen. Daarmee trek je het team naar je toe en zorg je ervoor dat alle aandacht aan jouw app wordt besteed.

3.2 Conflict of ontevredenheid

Lig je in de clinch met je ontwikkelaar? Zonde, maar nog geen reden om gelijk op te stappen met je app. In dit artikel beschrijf ik je mogelijkheden om je conflict te verhelpen. Of beter nog: om het te voorkomen, mocht je nog prima met je ontwikkelaar boteren.

3.3 Ontwikkelaar kapt ermee

Wil de ontwikkelaar zelf met een ander project aan de slag, of zien ze geen toekomst meer in jou te helpen? Dan is het handig om na te denken hoe die ontwikkelaar jou kunnen helpen. Zij trekken zich immers terug, dat hoeft niet meteen 100% jouw probleem te zijn. Oftewel, hoe kunnen ze investeren in jouw overdracht. Je mag namelijk prima wat commitment vragen van de ontwikkelaar die uitzwaait, voordat je goed en wel bij de nieuwe ontwikkelaar gevestigd bent. Denk bijvoorbeeld over het instrueren van de nieuwe ontwikkelaar, het in fases overzetten van je app of het tijdelijk delen van de verantwoordelijkheid over het onderhoud van je app.

3.4 Verouderde technieken

Als de techniek van je app is verouderd, en je huidige ontwikkelaar niet mee kan in die techniek, kan het een logische stap zijn om een nieuwe ontwikkelaar te zoeken. Eentje die wel bij is met de nieuwe ontwikkeltalen. Want blijven hangen kan enkel het vooruitschuiven van je probleem betekenen. Het is slimmer om na te denken hoe je je huidige app opnieuw kan opbouwen met nieuwe taal. 
 

4. Nieuwbouw als verlossing?

Opnieuw pijlOverweeg je het opnieuw bouwen van je app? Dat is logisch als de techniek verouderd is. Kijk, in de wereld van de app bewegen dingen snel en kan een programmeertaal binnen een aantal jaar al weer verouderd zijn. Dus het is helemaal niet gek dat je bijvoorbeeld elke 5 jaar de app in een nieuwe taal moet laten zetten. Ter vergelijking: de markt van apps is nu 15 jaar oud.

Iets overnieuw maken heeft het gevoel dat je met een schone lei kan beginnen. Dat geeft een fris gevoel en voelt soms als het afronden van een 'oude manier van werken'. Dat gevoel kan er zijn, maar feitelijk heeft nieuwbouw ook andere consequenties. Nieuwbouw heeft scherpe randjes, dus overweeg dan in ieder geval deze zaken:

4.1 Nieuw is niet altijd beter

Dat is wel zo, maar waarschijnlijk heb je in de tijd dat je originele app nog in ontwikkeling was, steeds kleine verbeteringen doorgevoerd. Denk aan kleine aanpassingen die alles nét iets beter laten verlopen voor de gebruiker, voor je administratie, voor de samenwerking met andere systemen en voor de ontwikkelaar. Dat soort leringen zitten verborgen in de app en het lijkt of ze er altijd zijn geweest. Bij het opnieuw bouwen van de app maak je deze vaak niet expliciet; je denkt "dat hoort er gewoon bij". Maar een nieuwe ontwikkelaar weet dat niet. Dus hij vergeet ze en dat kost extra tijd, de fijne manier van werken van je app gaat verloren en het kost je enorm veel geld en tijd om je oude niveau te behouden

Puzzelstuk4.2 Herbouw in gedeeltes

Ga met je ontwikkelaar na of het mogelijk is om gedeeltes opnieuw te maken. Soms is het mogelijk om een gedeelte van de techniek te verbeteren. Dat bespaart kosten en zorgt dat je bovenstaande manier van werken niet verliest.

cancel kruis4.3 Niet tevreden ≠ alles overnieuw

Als je niet tevreden bent over je app, of het is "niet goed gebouwd", dan hoeft dat niet te zeggen dat je alles helemaal opnieuw hoeft te bouwen. Je kunt gerust de programmeur vragen de kwaliteit van de app te verbeteren of aanpassingen te maken. Bouw pas echt iets opnieuw als je echt niet verder kunt of je bijvoorbeeld snelle groeiplannen hebt die beperkt worden door de bestaande techniek.

Op zoek naar je nieuwe partner? Spreek zijn taal

Ben je op zoek naar zo'n ontwikkelaar die de modernste programmeertalen spreekt? Met de Ontwikkelingsvergelijker hieronder krijg je een overzicht van ontwikkeltechnieken en -talen, waarmee je nagaat welke ontwikkelaar jij eigenlijk nodig hebt.

Vul hieronder je gegevens in en ontvang hem kosteloos in je mailbox:

-David van AppSpecialisten

doel van jouw app
fase van jouw app
geschreven door
David van der Loo