När du börjar leta efter en frilansutvecklare att samarbeta med kommer du märka att de är överallt. Online-frilansmarknaderna är packade till randen med skickliga kandidater. Ovanpå dessa är du tvungen att hitta minst en eller två (hundra) i närmaste stad.

Nu är du kvar med den svåra uppgiften att begränsa denna pool av talang ner till den som kommer att fungera mest effektivt med dig. Det är skrämmande även om du har lite teknisk skull, men det kan tyckas nästan omöjligt om du inte gör det. Å andra sidan är det lätt att tänka tekniska överväganden är de enda som spelar roll. Den som har anställt ett geni som är omöjligt att arbeta med kan bara berätta hur felaktigt det kan vara.

I den här artikeln fokuserar vi på några sätt att du kan vara säker på att du får den mest kompatibla partnern.

Kolla in deras arbete

Be om att se några av utvecklarens färdiga arbete. Innan du börjar utvärdera, se till att du förstår de delar som din utsikter arbetade med. Tillbringa lite tid att utforska sitt projekt. Gör anteckningar om vad du gillar och gillar inte. Kanske byggde de en webapp som är väldigt snabb, men det ställer några märkliga begränsningar på användarens lösenord. Fråga dem vad ledde dem att fatta besluten.

Vilken typ av mjukvaruutveckling, oavsett om det är webben, mobilappar eller skrivbord, är ett spel att hitta de bästa kompromisserna. Att höra de olika kompromisserna en utvecklare ställdes inför och deras sätt att lösa problemet är mycket värdefullt för att bedöma hur de kommer att lösa problem som ditt projekt kommer att möta.

Om du själv känner lite om kod själv kan du gräva i utvecklarens GitHub-konto för att se vad de har skrivit och vilka projekt de har bidragit till. Att se deras kod hjälper dig att förstå om de passar bra utifrån ett tekniskt perspektiv. Detta ger dig en mer konkret uppfattning om vad den utvecklarens lista över prestationer verkligen betyder när det gäller skicklighet.

Här är några aspekter av frilansarens GitHub som kanske inte är uppenbara först men du bör ägna särskild uppmärksamhet åt:  

  • Språk: håller frilansaren sig till ett eller två favoriserade språk, eller stör de på många olika språk? Att hitta en specialist på den teknik du behöver för ditt projekt kan flytta saker framåt snabbt, men en frilansare med en bred erfarenhet kan erbjuda förslag på andra typer av verktyg som är bättre anpassade till ditt jobb.
  • Kommentarer och dokumentation: Hur väl är koden dokumenterad? Frilansens karaktär innebär att du kan ha andra som arbetar med koden vid någon tidpunkt. Kommer denna frilansarens kod vara lätt att arbeta med? Om inte, betyder det att du kan begå dem mer än du vill. Vissa utvecklare tror att de är självdokumenterande och innebär att de inte behöver några kommentarer. Om du inte ser kommentarer, hur läsbar hittar du koden?
  • Bidrar de till andra projekt? Som kontraintuitiv som det kan tyckas är det ofta svårare att bidra till andra open source-projekt än att bygga upp egna. Andra människors kod kan vara svårt att förstå, men det är en nödvändig skicklighet. Detta är särskilt viktigt om du tar med en utvecklare till ett befintligt kodbas. Om de har bidragit till öppen källkod, är det mer troligt att de kommer att skriva kod som andra kan behålla senare eftersom de förstår utmaningarna med att göra det.

Ta reda på hur (och vad) de lär sig

Från de bästa metoderna till den faktiska tekniken som används, ändras mjukvaruutvecklingen i snabb takt. Om du slutar med en utvecklare som fastnar i praktiken och tekniken för 10 år sedan, kommer du att sakna verktyg och tekniker som kan göra ditt projekt bättre, snabbare och lättare att underhålla.

Fråga prospekter hur de lär sig nya saker och vad är det senaste som de har lärt sig som hjälper dem i deras utveckling. Vad fick de av att lära sig det? Vad är nästa sak de vill lära sig och varför?

Även om du inte är bekant med specifika svaren kan du få en känsla för hur nyfiken den här utvecklaren är. För mycket nyfikenhet kan leda till att projekt byggs på experimentella, ofrivilliga fundament, men i allmänhet kan en nyfiken utvecklare föra mer till ditt projekt.

Hitta en kompatibel kommunikator

Kommunikation kan göra eller bryta ett projekt. Se till att utvecklarna du arbetar med är villiga och kunna kommunicera på ett sätt och med en frekvens som du kan leva med. De flesta utvecklare har kommunikationsverktyg på plats som de använder med kollegor. Titta på dem och se om de kommer att fungera för dig. Om inte, ta reda på om utvecklaren är ok med hjälp av alternativa verktyg du föreslår.

Det här är också en bra tid att ta reda på hur ofta du kommer att höra från utvecklaren. Om svaret är: "En gång i slutet av varje milstolpe" kommer du förmodligen att vara olycklig. Vad är chansen att utvecklaren kommer att förstå ditt projekt precis som du tänker det första gången? Vad är chansen att varje enskilt stycke som utgör en färdig milstolpe kommer att vara helt på plats precis som du föreställde dig det?

Regelbundna incheckningar (minst en gång i veckan) kan fixa små missförstånd innan de blir stora.

Testa dem med ett projekt

Du lär dig mer med den här metoden än med alla andra kombinerade. Att ställa frågor om söka och kika in i deras kod kan bara ge dig små glimt av vad som fungerar med en person är som. Det bästa sättet att förstå hur det är att jobba med dem är att göra det. Ett test är också din bästa möjlighet att komma förbi de tekniska grejerna och in i saker som verkligen betyder något: Ska vi vara olyckliga och försöker arbeta med den här personen?

Om möjligt, bryt av en liten bit av ditt projekt och arbeta med möjligheten att slutföra det. Om det är möjligt, betala dem för att göra det. Detta gör några fina saker för dig:  

  • det ger dig ett riskfyllt sätt att testa att arbeta med utvecklaren;
  • det lämnar dig med en användbar leverans även om förhållandet inte fungerar.
  • om du har råd att betala en rättvis kurs är det ömsesidigt fördelaktigt för både dig och utvecklaren.

Jag nämna denna sista punkt eftersom ibland företag frestas att be utvecklare att bygga ett litet testprojekt gratis för att utvärdera dem och deras arbetsstil. Det här är inte ett bra sätt att starta ett förhållande med din utvecklare. Om de kan bygga något som kommer att vara användbart för dig - även om det i början inte är hela projektet du vill bygga - är det inte värt att betala för?

Det är nog bäst att du inte presenterar detta för utvecklaren som ett testprojekt. Du behöver inte ljuga eller lura dem på något sätt, men presentera detta som projektet. Det är faktiskt projektet för nu. Om allt fungerar, har du ett annat projekt att erbjuda, men håll det inte över dem. Det kommer att påverka förhållandet dynamiskt negativt. Ingen vill bli föremål för experiment. Om allt går bra, vill utvecklaren arbeta med dig om framtida projekt. du behöver inte använda det i början för att hålla dem på kroken.

Under det här engagemanget, håll ögonen öppna för röda flaggor. Tänk noga på vilka typer av beteende du inte kan arbeta runt.

Noggrann vetting lönar sig

Om din tidslinje för genomförandet av projektet närmar sig och du inte har tid att ta alla dessa steg, gör du åtminstone testprojektet. Få din framtid att bygga en bit av det större projektet, så att din risk är låg och ingen tid är bortkastad. Det är ett extremt värdefullt verktyg för att se till att detta är ett förhållande du vill ha. Även om det misslyckas och du måste hitta någon annan, kommer det att kosta dig mindre tid och pengar än att begå en utvecklingspartner att bara bygga hela projektet för att få det att falla igenom.

Det är mycket lättare i början att välja någon du gillar och hoppas på det bästa. Ibland kan det träna, men för det bästa av ditt projekt borde du gå in i relationer med dina ögon öppna så mycket som möjligt.

Utvald bild, lagarbete bild via Shutterstock.