Waar moet je op letten als je een programmeur inhuurt?

Het lijkt zo eenvoudig. “Dan huren we toch even een programmeur in?” Probleem zo opgelost. Maar helaas, zo werkt het niet. Wij matchen onze programmeurs al 25 jaar aan opdrachtgevers en geloof me, er zijn veel ‘inleen-valkuilen’.  Om jou daarvoor te behoeden, hier een aantal tips.

De programmeur is niet het probleem. Jíj bent het probleem.

Misschien wat baud gesteld. Maar in veel gevallen lijkt het wel of de inzet van een dure programmeur de magische oplossing voor alle problemen is. Veel ondernemers en managers willen niet de tijd en moeite nemen om eerst eens goed te kijken naar hun organisatie, om de vraag àchter de vraag te formuleren. Om van daaruit processen te herstructureren en vervolgens daar software omheen te ontwikkelen. Dat kost te veel tijd, te veel moeite en misschien moeten er dan ook wel pijnlijke conclusies getrokken worden. Maar so be it, want doe je het niet, dan ben je bezig met het ontwikkelen van een doekje voor het bloeden en dat komt op een goede dag als een boomerang terug. 

Neem altijd de moeite om de vraag achter de vraag eerst te beantwoorden

Herman de Wilde

Een voorbeeld

Een potentiële klant wilde persé hun CRM-software laten ontwikkelen in Excel. Die keuze werd gemaakt omdat Excel, en ook de Excel-programmeur, een alleskunner is en daarmee zouden alle problemen in één keer opgelost zijn. Snap ik. Maar Excel is niet gemaakt om programma’s in te ontwikkelen. En als je een applicatie wilt maken (wat de klant wilde) waar veel gebruikers in de Cloud in de toekomst gebruik van kunnen maken, zit je met Excel echt niet op het juiste spoor. Hadden ze wat meer onderzoek vooraf gedaan, wat meer mensen gesproken, dan hadden ze dat geweten en ongetwijfeld anders gekozen. 

Lang verhaal kort, klant wist het beter, en bouwt nu nog aan een onmogelijke oplossing waarvan wij uit ervaring weten: daar komt geen eind aan.  

Zoek naar de vraag achter de vraag

We zeiden het al. Natuurlijk lijkt het tijd- en kostenbesparend als je ontwikkelprocessen sneller laat verlopen. Maar laten we beginnen met eens te kijken naar welke kant je eigenlijk op wilt met je bedrijf. Is daar goed over nagedacht en passen die snellere processen wel in dat kader. Of is het een tijdelijk lapmiddel. Geen fout antwoord. Maar wel een belangrijke keuze voor welke oplossing je kiest. Een State Of The Art webapplicatie of een Low Code gebouwde Power App of Access Applicatie.

Vergeet niet te prototypen

Tip numero uno voor een succesvol softwaretraject. Laat een Prototype maken. Iedere programmeur die zegt je te snappen en meteen software gaat ontwikkelen kun je beter meteen naar huis sturen. Ik kan jou nog zo goed uitleggen wat ik wil, jij zult het altijd anders begrijpen. Daarnaast is een prototype prettig voor iedereen. Het kost een beetje tijd om te maken, maar die tijd verdien je gemiddeld 5 (!) keer terug. 

Een prototype stelt je ook in staat om een vasteprijsafspraak te maken. Uitermate prettig als je door facturatie op basis van nacalculatie een beetje nerveuzig wordt. Want dat wordt iedereen. En dat is niet goed voor het eindresultaat. 

Prototypes maken kan met speciale software voor prototypes. Het kan in MS Access. Het kan in MS Excel. 

Laat de programmeur niet z’n skills doordrukken

Nog zo eentje. Een programmeur die heel goed is in een bepaald programma. Daar al veel applicaties in heeft gebouwd. En zeker weet dat jouw softwarewens daar ook het beste in ontwikkeld kan worden. Niet mee eens. Er zijn zo veel manieren om software te bouwen. En voor wat wij hebben gezien, wordt er voor een programmeur gekozen en niet voor software. En zit je voor je het weet met een misbaksel van een tool waarbij je je in allerlei bochten moet wringen om er iets van resultaat uit te krijgen. 

Klikt het een beetje?

Kan je opschieten met je softwarespecialist? Is zijn middle-name: ‘dat gaan we regelen, ik luister’? Het is belangrijk dat je een goede band hebt met de expert die jouw bedrijf een flinke stap voorwaarts laat maken. Geen ruimte voor concessies dus. Je gaat een langetermijnrelatie aan. Dat moet goed voelen. Meteen. Vanaf dag één.

En een keer het niet eens zijn hoort er ook bij. Is zelfs heel gezond. Maar dan wel constructief.

Hoor je wel wat ik zeg?

Probeer tijdens de eerste gesprekken er achter te komen of de programmeur wel écht geïnteresseerd is. Verplaatst hij zich in jouw situatie? Laat hij zien dat hij echt op dezelfde pagina zit als jij? Dat er iemand naast je zit, bij wijze van spreken. En niet tegenover je in een hele andere wereld. 

Afspraak is afspraak

Dat een programmeur goed kan programmeren en structureren, wil nog niet zeggen dat hij of zij ook goed voor de eigen planning kan zorgen. Houd daarom scherp in de gaten of alles wat is afgesproken ook wordt nagekomen. Vooral in het begin. Laat de teugels pas vieren als het lekker loopt. Ziet de software er exact zo uit als het prototype? Wordt het binnen de afgesproken tijd opgeleverd? Foutloos? Met voldoende foutmeldingen? Idiot proof? Of was dat geen voorwaarde?

Bezint eer ge begint

Al met al, denk eerst zelf na voordat je een programmeur inhuurt. Schrijf op wat je wilt, hoe je het wilt, wanneer je het wilt en wat het mag kosten. Bespreek het dan met verschillende professionals, mensen met andere achtergronden, interesses, werkvelden. Hoor het aan, laat je adviseren, denk ook zelf. Want pas als je goed bent voorgelicht over de verschillende mogelijkheden (pakket, taal, soort applicatie), kan je een beslissing nemen over de programmeur die daarbij hoort.