Når du først er på udkig efter en freelance-udvikler til at samarbejde med, vil du bemærke, at de er overalt. Online freelance markedspladser er pakket til overfladen med dygtige kandidater. På toppen af dem er du nødt til at finde mindst en eller to (hundrede) i den nærmeste by.
Nu er du tilbage med den vanskelige opgave at indsnævre denne pulje af talent ned til den, der vil fungere mest effektivt med dig. Det er skræmmende, selvom du har noget teknisk akumen, men det kan virke næsten umuligt, hvis du ikke gør det. På den anden side er det let at tænke tekniske overvejelser er de eneste der betyder noget. Enhver, der har hyret et geni, som er umuligt at arbejde med, kan fortælle dig, hvor forkert det kan være.
I denne artikel vil vi fokusere på et par måder, du kan være sikker på, at du får den mest kompatible partner.
Bed om at se nogle af udviklerens færdige arbejde. Før du begynder at evaluere, skal du sørge for, at du forstår de dele, din udsigt har fungeret på. Brug lidt tid til at udforske deres projekt. Lav noter af, hvad du kan lide og ikke kan lide. Måske har de bygget en webapp, der er virkelig hurtig, men det stiller nogle ulige begrænsninger på brugerens adgangskode. Spørg dem, hvad førte dem til at træffe disse beslutninger.
Enhver form for softwareudvikling, uanset om det er web, mobilapps eller skrivebord, er et spil for at finde de bedste kompromiser. Høring af de forskellige trade-offs en udvikler blev konfronteret med, og deres tilgang til at løse problemet er yderst værdifuldt ved at vurdere, hvordan de vil løse problemer, som dit projekt vil støde på.
Hvis du selv ved lidt om kode selv, kan du grave ind i udviklerens GitHub-konto for at se, hvad de har skrevet, og hvilke projekter de har bidraget til. At se deres kode hjælper dig med at forstå, om de passer godt ud fra et teknisk perspektiv. Dette giver dig en mere konkret ide om, hvad udviklerens liste over resultater faktisk betyder hvad angår færdigheder.
Her er et par aspekter af freelancers GitHub, som måske ikke er indlysende i starten, men du bør være særlig opmærksom på:
Fra den bedste praksis til den faktiske anvendte teknologi ændres softwareudvikling i et hurtigt tempo. Hvis du ender med en udvikler, der sidder fast i praksis og teknologi for 10 år siden, vil du gå glip af værktøjer og teknikker, som kan gøre dit projekt bedre, hurtigere og lettere at vedligeholde.
Spørg prospekter, hvordan de lærer nye ting, og hvad er det nyeste, de har lært, der hjælper dem med deres udvikling. Hvad fik de af at lære det? Hvad er den næste ting, de gerne vil lære, og hvorfor?
Selvom du ikke er bekendt med specifikationerne af deres svar, kan du få en fornemmelse for, hvor nysgerrig denne udvikler er. For meget nysgerrighed kan føre til, at projekter opbygges på eksperimentelle, ubeviste fundament, men generelt kan en nysgerrig udvikler bringe mere til dit projekt.
Kommunikation kan gøre eller bryde et projekt. Sørg for, at de udviklere, du arbejder med, er villige og i stand til at kommunikere på en måde og med en frekvens, som du kan leve med. De fleste udviklere har kommunikationsværktøjer på plads, som de bruger sammen med kolleger. Kig ind i dem og se om de vil arbejde for dig. Hvis ikke, find ud af om udvikleren er i orden ved at bruge de alternative værktøjer, du foreslår.
Det er også en god tid at finde ud af, hvor ofte du hører fra udvikleren. Hvis svaret er: "En gang i slutningen af hver milepæl" vil du sandsynligvis være utilfreds. Hvad er chancerne for, at udvikleren vil forstå dit projekt præcis som du har tænkt det første gang? Hvad er chancerne for, at hvert særskilt stykke, der udgør en færdiggjort milepæl, vil være helt på plads, som du forestillede dig?
Regelmæssige check-ins (mindst en gang om ugen) kan ordne små misforståelser, før de bliver store.
Du lærer mere med denne metode end med alle de andre kombineret. At stille spørgsmålstegn ved spørgsmål og kigge ind i deres kode kan kun give dig små glimt af, hvad der virker med en person, er. Den bedste måde at forstå, hvordan det er at arbejde med dem er at gøre det. En test er også din bedste chance for at komme forbi de tekniske ting og ind i de ting, der virkelig betyder noget: Skal vi være elendige forsøger at arbejde med denne person?
Hvis det er muligt, skal du afbryde et lille stykke af dit projekt og arbejde med udsigt til at fuldføre det. Hvis det overhovedet er muligt, skal du betale dem for at gøre det. Dette gør et par gode ting for dig:
Jeg nævner dette sidste punkt, fordi nogle gange er virksomheder fristet til at bede udviklere om at bygge et lille testprojekt gratis med det formål at evaluere dem og deres arbejdsstil. Dette er ikke en god måde at starte et forhold med din udvikler. Hvis de kan bygge noget, som vil være nyttigt for dig - selv om det i starten ikke er hele projektet, du vil bygge - er det ikke værd at betale for?
Det er nok bedst, at du ikke præsenterer dette til udvikleren som et testprojekt. Du behøver ikke at lyve eller bedrage dem på nogen måde, men præsenterer dette som projektet. Faktisk er det projektet for nu. Hvis alt går ud, har du et andet projekt at byde på, men hold det ikke over dem. Det vil påvirke forholdet dynamisk. Ingen ønsker at blive genstand for forsøg. Hvis alt går godt, vil udvikleren gerne arbejde med dig om fremtidige projekter; du behøver ikke bruge det i begyndelsen for at holde dem på krogen.
I løbet af dette engagement skal du holde øjnene åbne for røde flag. Tænk grundigt på, hvilke former for adfærd du ikke kan arbejde rundt.
Hvis din tidslinje for projektets gennemførelse nærmer sig, og du ikke har tid til at tage alle disse trin, skal du i det mindste gøre testprojektet. Få din udsigt til at bygge et stykke af det større projekt, så din risiko er lav, og der er ikke spildt tid. Det er et yderst værdifuldt værktøj for at sikre, at dette er et forhold, du vil have. Selv om det fejler, og du skal finde en anden, vil det koste dig mindre tid og penge end at begå en udviklingspartner til kun at bygge hele projektet for at få det til at falde igennem.
Det er meget nemmere i starten at vælge en person, du kan lide og håber på det bedste. Nogle gange kan det fungere, men for det gode af dit projekt skal du indgå i relationer med dine øjne åbne så meget som muligt.