Når du begynner å lete etter en freelance-utvikler for å samarbeide med, vil du legge merke til at de er overalt. Online freelance markedsplasser er pakket til brim med dyktige kandidater. På toppen av dem er du nødt til å finne minst en eller to (hundre) i nærmeste by.
Nå er du igjen med den vanskelige oppgaven med å begrense dette talentpotet ned til den som vil fungere mest effektivt med deg. Det er skremmende selv om du har noe teknisk håp, men det kan virke nært umulig hvis du ikke gjør det. På den annen side er det lett å tenke tekniske overveier er de eneste som betyr noe. Alle som har ansatt et geni som er umulig å jobbe med, kan fortelle deg hvor feil det er.
I denne artikkelen vil vi fokusere på noen måter du kan være sikker på at du får den mest kompatible partneren.
Be om å se noen av utviklerens ferdige arbeid. Før du begynner å evaluere, må du sørge for at du forstår de delene du har tenkt på. Ta deg tid til å utforske prosjektet. Lag notater av hva du liker og ikke liker. Kanskje de bygget en web-app som er veldig rask, men det legger noen merkelige begrensninger på brukerens passord. Spør dem hva som førte dem til å ta de beslutningene.
Enhver form for programvareutvikling, enten det er web, mobilapper eller skrivebord, er et spill for å finne de beste kompromissene. Høring av de ulike avvikene en utvikler ble utsatt for, og deres tilnærming til å løse problemet er ekstremt verdifullt for å vurdere hvordan de vil løse problemer som prosjektet ditt vil møte.
Hvis du selv vet litt om kode selv, kan du grave inn i utviklerens GitHub-konto for å se hva de har skrevet og hvilke prosjekter de har bidratt til. Å se sin kode vil hjelpe deg å forstå om de passer godt fra et teknisk perspektiv. Dette gir deg en mer konkret ide om hva utviklerens liste over prestasjoner faktisk betyr når det gjelder ferdigheter.
Her er noen aspekter av freelancerens GitHub som kanskje ikke er åpenbare først, men du bør være spesielt oppmerksom på:
Fra den beste teknikken til den faktiske teknologien som brukes, endres programvareutviklingen i et raskt tempo. Hvis du ender med en utvikler som sitter fast i praksis og teknologi for 10 år siden, vil du gå glipp av verktøy og teknikker som kan gjøre prosjektet ditt bedre, raskere og enklere å vedlikeholde.
Spør prospekter hvordan de lærer nye ting, og hva er det siste de har lært som hjelper dem i utviklingen deres. Hva fikk de fra å lære det? Hva er det neste de ønsker å lære og hvorfor?
Selv om du ikke er kjent med detaljene i svarene sine, kan du få en følelse av hvor nysgjerrig denne utvikleren er. For mye nysgjerrighet kan føre til at prosjekter bygges på eksperimentelle, ubevisste grunnlag, men generelt kan en nysgjerrig utvikler bringe mer til prosjektet ditt.
Kommunikasjon kan gjøre eller ødelegge et prosjekt. Sørg for at utviklerne du jobber med, er villige og i stand til å kommunisere på en måte og med en frekvens du kan leve med. De fleste utviklere har kommunikasjonsverktøy på plass de bruker med kolleger. Se på dem og se om de vil fungere for deg. Hvis ikke, finn ut om utvikleren er i orden ved hjelp av alternative verktøy du foreslår.
Dette er også en flott tid å finne ut hvor ofte du hører fra utvikleren. Hvis svaret er, "En gang i slutten av hver milepæl," vil du sannsynligvis være ulykkelig. Hva er sjansene for at utvikleren vil forstå prosjektet akkurat slik du har tenkt det første gang? Hva er sjansene for at hvert enkelt stykke som utgjør en fullført milepæl, vil være helt på plass akkurat som du trodde det?
Regelmessige innsjekking (minst en gang i uka) kan fikse små misforståelser før de blir store.
Du lærer mer med denne metoden enn med alle de andre kombinert. Å spørre probing spørsmål og kikke inn i sin kode kan bare gi deg små glimt av hva som jobber med en person er som. Den beste måten å forstå hva det er å jobbe med, er å gjøre det. En test er også din beste mulighet til å komme forbi tekniske ting og inn i de ting som virkelig betyr noe: Skal vi være elendige prøver å jobbe med denne personen?
Hvis mulig, ta av et lite stykke prosjekt og jobbe med utsiktene for å fullføre det. Hvis det er mulig, betal dem for å gjøre det. Dette gjør noen fine ting for deg:
Jeg nevner dette siste punktet fordi noen ganger er selskaper fristet til å be utviklere å bygge et lite testprosjekt gratis for å evaluere dem og deres arbeidsstil. Dette er ikke en god måte å starte et forhold med utvikleren din. Hvis de kan bygge noe som vil være nyttig for deg - selv om det i begynnelsen ikke er hele prosjektet du vil bygge - er det ikke verdt å betale for?
Det er sannsynligvis best du ikke presenterer dette for utvikleren som et testprosjekt. Du trenger ikke å lyve eller bedra på noen måte, men presentere dette som prosjektet. Faktisk er det prosjektet for nå. Hvis alt går ut, har du et annet prosjekt å tilby, men hold ikke dette over dem. Det vil påvirke forholdet dynamisk. Ingen ønsker å være gjenstand for eksperimentering. Hvis alt går bra, vil utvikleren ønske å jobbe med deg på fremtidige prosjekter; du trenger ikke å bruke det i begynnelsen for å holde dem på kroken.
I løpet av dette engasjementet, hold øynene åpne for røde flagg. Tenk nøye på hva slags oppførsel du ikke kan jobbe rundt.
Hvis tidslinjen for prosjektgjennomføring nærmer seg og du ikke har tid til å ta alle disse trinnene, gjør du i det minste testprosjektet. Få potensialet til å bygge et stykke større prosjekt, slik at risikoen din er lav og ingen tid er bortkastet. Det er et ekstremt verdifullt verktøy for å sikre at dette er et forhold du vil ha. Selv om det mislykkes og du må finne noen andre, vil det koste deg mindre tid og penger enn å forplikte seg til en utviklingspartner for å bygge hele prosjektet bare for å få det til å falle gjennom.
Det er mye lettere i begynnelsen å velge noen du liker og håper på det beste. Noen ganger kan det fungere, men for det gode ved prosjektet, bør du inngå relasjoner med øynene åpne så mye som mulig.