Zodra u op zoek gaat naar een freelance ontwikkelaar om mee samen te werken, merkt u dat ze overal zijn. Online freelance marktplaatsen zijn tot de nok gevuld met bekwame kandidaten. Daar bovenop zult u zeker een of twee (honderd) vinden in de dichtstbijzijnde stad.

Nu blijf je achter met de moeilijke taak om deze pool van talent te versmallen tot degene die het meest effectief met je zal werken. Het is beangstigend, zelfs als je wat technisch inzicht hebt, maar het lijkt bijna onmogelijk als je dat niet doet. Aan de andere kant is het gemakkelijk om te denken dat technische overwegingen de enige zijn die er toe doen. Iedereen die een genie heeft ingehuurd dat onmogelijk is om mee samen te werken, kan je vertellen hoe verkeerd het kan zijn.

In dit artikel concentreren we ons op een aantal manieren waarop u er zeker van kunt zijn dat u de meest compatibele partner krijgt.

Bekijk hun werk

Vraag om een ​​deel van het voltooide werk van de ontwikkelaar te bekijken. Voordat je begint met evalueren, zorg ervoor dat je de onderdelen begrijpt waar je prospect aan werkte. Besteed wat tijd om hun project te verkennen. Maak aantekeningen van wat je leuk vindt en waar je niet van houdt. Misschien hebben ze een web-app gebouwd die erg snel is, maar het plaatst enkele vreemde beperkingen aan het wachtwoord van de gebruiker. Vraag hen wat hen ertoe bracht om die beslissingen te nemen.

Elke vorm van softwareontwikkeling, of het nu gaat om internet, mobiele apps of een desktop, is een spel om de beste compromissen te vinden. Het horen van de verschillende compromissen waar een ontwikkelaar mee te maken kreeg en hun aanpak om het probleem op te lossen is uiterst waardevol bij het beoordelen van hoe zij de problemen aanpakken die uw project zal tegenkomen.

Als je zelf wat over code weet, kun je in het GitHub-account van de ontwikkelaar graven om te zien wat ze hebben geschreven en aan welke projecten ze hebben bijgedragen. Het zien van hun code zal u helpen te begrijpen of ze technisch gezien goed passen. Dit geeft je een concreter idee van wat die ontwikkelaarslijst van prestaties eigenlijk betekent in termen van vaardigheden.

Hier zijn een paar aspecten van de GitHub van de freelancer die in eerste instantie misschien niet vanzelfsprekend zijn, maar waar je vooral op moet letten:  

  • Talen: houdt de freelancer vast aan een of twee favoriete talen, of zijn ze in veel verschillende talen actief? Het vinden van een specialist in de technologieën die u voor uw project nodig hebt, kan de zaken snel vooruit helpen, maar een freelancer met een ruime ervaring kan suggesties doen over andere soorten hulpmiddelen die beter bij uw functie passen.
  • Opmerkingen en documentatie: hoe goed is de code gedocumenteerd? De aard van freelancen betekent dat je op een gegeven moment andere mensen aan de code kunt laten werken. Is de code van deze freelancer gemakkelijk om mee te werken? Zo niet, dan betekent dat dat je je meer aan hen zult binden dan je wilt. Sommige ontwikkelaars zijn van mening dat een zelfdocumenterende code betekent dat ze geen opmerkingen nodig hebben. Als u geen opmerkingen ziet, hoe leesbaar vindt u de code?
  • Dragen ze bij aan andere projecten? Hoe contradictioend het ook lijkt, het is vaak moeilijker om bij te dragen aan andere open-sourceprojecten dan om uw eigen projecten te bouwen. De code van anderen kan moeilijk te begrijpen zijn, maar dat is een noodzakelijke vaardigheid. Dit is vooral belangrijk als je een ontwikkelaar binnenhaalt om aan een bestaande codebase te werken. Als ze hebben bijgedragen aan open-source, is het waarschijnlijker dat ze code schrijven die anderen later kunnen behouden, omdat ze de uitdagingen begrijpen om dit te doen.

Ontdek hoe (en wat) ze leren

Van de beste werkwijzen tot de huidige gebruikte technologie, de ontwikkeling van software gaat in hoog tempo. Als je een ontwikkelaar tegenkomt die vastzit in de praktijken en technieken van 10 jaar geleden, mis je tools en technieken die je project beter, sneller en gemakkelijker te onderhouden zouden kunnen maken.

Vraag prospects hoe zij nieuwe dingen leren en wat het meest recente is wat ze hebben geleerd dat hen helpt bij hun ontwikkeling. Wat hebben ze geleerd door het te leren? Wat is het volgende ding dat ze zouden willen leren en waarom?

Zelfs als u niet bekend bent met de details van hun antwoorden, kunt u een idee krijgen van hoe nieuwsgierig deze ontwikkelaar is. Te veel nieuwsgierigheid kan ertoe leiden dat projecten worden gebouwd op experimentele, onbewezen fundamenten, maar over het algemeen kan een nieuwsgierige ontwikkelaar meer aan uw project bijdragen.

Zoek een compatibele communicator

Communicatie kan een project maken of breken. Zorg ervoor dat de ontwikkelaars waarmee je werkt bereid en in staat zijn om te communiceren op een manier en met een frequentie waarmee je kunt leven. De meeste ontwikkelaars beschikken over communicatiemiddelen die ze gebruiken met collega's. Kijk daarin en kijk of ze voor jou zullen werken. Als dit niet het geval is, zoek dan uit of de ontwikkelaar in orde is met de alternatieve tools die u suggereert.

Dit is ook een goed moment om erachter te komen hoe vaak u van de ontwikkelaar hoort. Als het antwoord luidt: "Aan het einde van elke mijlpaal", zult u waarschijnlijk niet tevreden zijn. Hoe groot is de kans dat de ontwikkelaar uw project precies zal begrijpen zoals u het de eerste keer wilde? Hoe groot is de kans dat elk afzonderlijk stuk dat een voltooide mijlpaal vormt perfect op zijn plaats zal zijn precies zoals u het zich had voorgesteld?

Regelmatige check-ins (minstens één keer per week) kunnen kleine misverstanden oplossen voordat ze groot worden.

Test ze met een project

Je leert meer met deze methode dan met alle andere gecombineerd. Door indringende vragen te stellen en in hun code te gluren, kun je maar een klein beetje zien hoe werken met een persoon eruit ziet. De beste manier om te begrijpen hoe het is om met hen te werken, is door het te doen. Een test is ook je beste kans om voorbij de technische dingen te komen en in de dingen die er echt toe doen: gaan we ellendig zijn om met deze persoon te werken?

Sluit zo mogelijk een klein deel van uw project af en werk samen met de prospect om het af te maken. Als het enigszins mogelijk is, betaal ze om het te doen. Dit doet een paar leuke dingen voor je:  

  • het geeft u een risicovolle manier om het werken met de ontwikkelaar te testen;
  • het laat je een nuttig resultaat zien, zelfs als de relatie niet lukt;
  • als u het zich kunt veroorloven om een ​​eerlijke prijs te betalen, is dit wederzijds voordelig voor zowel u als de ontwikkelaar.

Ik noem dit laatste punt omdat bedrijven soms in de verleiding komen om ontwikkelaars te vragen om gratis een klein testproject te bouwen om ze en hun werkstijl te evalueren. Dit is geen goede manier om een ​​relatie met uw ontwikkelaar te starten. Als ze iets kunnen bouwen dat nuttig voor je is - zelfs als het in het begin niet het hele project is dat je wilt bouwen - is dat niet de moeite waard om voor te betalen?

Het is waarschijnlijk het beste dat je dit niet presenteert aan de ontwikkelaar als een testproject. Je hoeft ze op geen enkele manier te liegen of te misleiden, maar presenteer dit als het project. In feite is dit het project voor nu. Als alles goed gaat, heb je een ander project te bieden, maar houd dit niet over hen. Het zal de relatie-dynamiek negatief beïnvloeden. Niemand wil het onderwerp zijn van experimenten. Als alles goed gaat, wil de ontwikkelaar met u samenwerken bij toekomstige projecten; je hoeft dat in het begin niet te gebruiken om ze vast te houden.

Houd tijdens deze verloving je ogen open voor rode vlaggen. Denk goed na over wat voor soort gedrag je niet kunt omzeilen.

Zorgvuldige doorlichting loont

Als uw tijdlijn voor voltooiing van het project nadert en u geen tijd hebt om al deze stappen te nemen, doe dan op zijn minst het testproject. Laat uw prospect een deel van het grotere project bouwen, op die manier is uw risico laag en wordt er geen tijd verspild. Het is een uiterst waardevol hulpmiddel om ervoor te zorgen dat dit een relatie is die u wilt hebben. Zelfs als het faalt en je moet iemand anders vinden, kost het je minder tijd en geld dan een ontwikkelpartner om het hele project alleen maar te laten doorkomen.

Het is in het begin veel gemakkelijker om iemand te kiezen die je leuk vindt en er het beste van te hopen. Soms kan dat lukken, maar voor het welzijn van uw project moet u zo veel mogelijk relaties aangaan met uw ogen open.

Uitgelichte afbeelding, teamwerk afbeelding via Shutterstock.