Software-ontwikkeling, hoe werkt dat?

Marien de Gelder is het hoofd van de business unit Software-ontwikkeling bij OGD. Hier een samenvatting uit een reeks van vier komende blogposts over hoe hij software-ontwikkeling ziet.

Drie aandachtspunten bij het succesvol detacheren van een software-ontwikkelaar

Mijn ervaring met detachering laat me een paar cruciale punten zien die je in de gaten moet houden als je een software-ontwikkelaar inhuurt. Dat zijn onder andere de mate van ervaring van de organisatie met software-ontwikkeling. Maar ook de denkfout dat er onmiddellijke resultaten ontstaan na het inhuren van een ontwikkelaar. En tot slot de ontstane valkuilen binnen het ontwikkelproces doordat iedereen in zijn eigen rol blijft denken.

De mate van ervaring met software-ontwikkeling is cruciaal

Er zijn veel verschillende soorten organisaties die ontwikkelaars in willen huren. Hoe een organisatie het beste geholpen is, hangt af van een aantal zaken. Ervaring is cruciaal. Een vraag die ik altijd stel is daarom “Heeft u ervaring met het ontwikkelen van software?” Dat is het geval bij bijvoorbeeld organisaties die op structurele basis software ontwikkelen, of een team dat structureel voor de eigen organisatie software ontwikkelt. Zij hebben veel ontwikkelervaring en weten hoe zij een ontwikkeltraject succesvol laten verlopen. Zijn zij op zoek naar tijdelijke versterking, dan is het detacheren van een ontwikkelaar een prima oplossing. De kennis en ervaring om zo'n ontwikkelaar goed aan te sturen, hebben ze zonder twijfel in huis.

Voor organisaties die op incidentele basis ontwikkelen, ligt het iets gevoeliger. Omdat de dagelijkse aansturing soms lastig blijkt, is het raadzaam om voor de dagelijkse begeleiding een coördinator in te schakelen die de aansturing overneemt. Elke medewerker heeft namelijk sturing en begeleiding nodig. Ook iemand die zo slim is als een ontwikkelaar.

Dan zijn er nog organisaties die nooit zelf software hebben ontwikkeld, en dus geen ervaring hebben in zowel het ontwikkelen als het begeleiden van software processen. In dat geval is het meestal slim om een volledig team in te huren. Of het project uit te besteden aan een externe partij. Je kunt je gemakkelijk verkijken op hoe gecompliceerd het software-ontwikkelproces kan zijn. Voor je het door hebt, ben je maanden verder zonder tastbare resultaten. Of het nu alleen om de begeleiding gaat of om het gehele proces.

Een ontwikkelaar levert niet onmiddellijk snelheidswinst op

Op het moment dat een bedrijf een extra ontwikkelaar inhuurt is dat vaak omdat er achterstand is in een softwaretraject. En er dus behoefte aan kennis of capaciteit is die het bedrijf op dat moment te kort komt. Als je een ontwikkelaar inhuurt, zal er aanvankelijk echter altijd een stagnatie zijn in het ontwikkelproces. Dat klinkt krom. Maar het is heel logisch. De vertraging zit ‘m onder andere in het inwerken en opleiden van de tijdelijke kracht. En dat duurt een bepaalde periode. Daarna zal er weer een groei in de productiviteit komen. Wat dit proces versnelt, is de ontwikkelaar in het begin kleine afgebakende taken geven. Zo blijft er goed zicht op de resultaten van de ontwikkelaar en kan hij of zij zich het ontwikkelproces op een laagdrempelige manier eigen maken.

Let erop dat iedereen elkaars rol goed begrijpt!

Ik heb ontdekt dat er een aantal valkuilen bestaat binnen het software-ontwikkelproces waarvoor je op moet passen. Een voorbeeld daarvan is de aansturing van de ontwikkelaar. Zoals hierboven genoemd gebeurt dat soms door het bedrijf zelf, wanneer dat bedrijf er ervaring in heeft. Of er wordt een expert ingehuurd die een vinger aan de pols houdt. Er ontstaat namelijk heel snel miscommunicatie tussen de opdrachtgever en de ontwikkelaar. Er is een coördinator nodig die de taal van de ontwikkelaar goed spreekt, en de vraag goed kan vertalen. Zo ontstaat er geen ruis op weg naar het einddoel.

Dit einddoel moet vervolgens goed in het oog gehouden worden. Een opdrachtgever kan vanuit enthousiasme steeds nieuwe taken aan het project toevoegen, een proces dat scope creep genoemd wordt, en zo het ontwikkelproces vertroebelen en de focus verliezen. Of er ontstaat bij de ontwikkelaar juist zo’n tunnelvisie dat er geen oog meer is voor het eventueel bijstellen van doelen na tussentijdse evaluaties en het in de gaten houden van de planning.

Ik adviseer dan ook het agile ontwikkelprincipe toe te passen. Dit zorgt er onder andere voor dat er heel vaak controlemomenten zijn. Op deze momenten kan het proces worden bijgesteld en wordt er dus goed gelet op de zogenaamde cost of change curve. Een vroegere wijziging is namelijk goedkoper dan diezelfde wijziging op een veel later punt in het proces.

Detachering in de toekomst

Het wordt nu alleen maar belangrijker de juiste kennis en capaciteit op de juiste plek te hebben en deze dan goed aan te sturen. Ik zie tijdens mijn werk dat organisaties hun middelen efficiënter willen inzetten. Dus wordt er kritisch gekeken naar welke ontwikkelaars nodig zijn. Het loont vaak niet om voor een bepaald budget eenvoudigweg een groep gedetacheerde ontwikkelaars intern te laten meedraaien op de werkvloer. Het is veel doelmatiger om op projectbasis te werken en goed te letten op welke expertise voor welke periode je in huis haalt.

Dit artikel verscheen eerder op de site van computable.