Når du nettopp har begynt i en webutviklingsvirksomhet, kan det være veldig fristende å prøve å håndtere de fleste (om ikke alle) arbeidet helt alene. Det er ikke vanskelig å forstå logikken: jo mer av arbeidet du fullfører personlig, jo mer av fortjenesten får du å beholde, ikke sant?

Men det er en side til denne tilnærmingen at mange nye aktører i bransjen overser når de bestemmer seg for å starte en uavhengig virksomhet i stedet for å bli med i et etablert byrå: Hvis du gjør det meste av arbeidet selv, kan du ende opp med å bruke nesten all din tid på å jobbe . Uunngåelig betyr dette sent netter, gallon cola og utallige hjemmelagde pizzaer. Du ender med røde øyne, dårlig hud og en hovent mage ... neppe hva du tenkte da du først bestemte deg for å gå inn i virksomheten!

Du vil sannsynligvis ikke gjøre nesten like mye penger, fordi hvis du er nedsenket i kode og håndterer kundeproblemer og oppfølgingsarbeid, kan du ikke bruke så mye energi til å generere nye kundeemner. Før du vet det, blir mange av disse solo flyers brent ut og nesten brutt.

Heldigvis behøver det ikke å komme til det, fordi hvis du kan se visdommen til lagbygging, delegering og deling av rikdom for gjensidig nytte, har du allerede forbedret dine muligheter for suksess. Det er bare en siste ting som står i veien ... du må finne de riktige menneskene til å jobbe med.

Å bygge et lag: du trenger folk med ferdigheter!

Et godt webutviklingsprosjekt har nesten alltid følgende nødvendige roller:

  • Salgsperson - hjelper til med å generere nye kunder for virksomheten
  • Prosjektarkitekt - utvikler prosjektets overordnede konsept (ikke design)
  • Prosjektleder - styrer prosjektet og holder alt på sporet
  • Nettsteddesigner - designer utseendet og funksjonaliteten til nettstedet
  • Back-end utvikler - skaper rammen som grensesnittet vil bli plassert på
  • Front-end-utvikler - skaper og implementerer grensesnittkomponenter
  • Site tester - ideelt gjør alt mulig for å prøve å bryte nettstedet til det kan brytes ikke mer.

bare fordi du bygger et lag betyr ikke at ingen kan multi-oppgave

I tillegg til kjernerollene som er nevnt ovenfor, er det noen ganger et behov for spesialister:

  • UI-spesialist - arbeider med frontend-utviklere for å gjøre mer fantastiske grensesnitt
  • UX-spesialist - undersøker i stor grad de menneskelige faktorene til et nettsted for å sikre en god brukeropplevelse
  • SEO-spesialist - bestemmer (og muligens implementerer) en SEO-strategi
  • Content Writer - gir tekstinnhold av høy kvalitet
  • Grafisk designer - skaper egendefinert grafikk

La meg være klar at bare fordi du bygger et lag, betyr det ikke at ingen kan multi-oppgave. Så laget du lager sammen, trenger ikke nødvendigvis å være stort, og faktisk kan det være ulemper å ha et lag som er for stort.

Generelt, jo større og viktigere et prosjekt er, desto mer spesialisert må laget ditt være. Mindre og mindre viktige prosjekter gir mer mulighet for enkeltpersoner til å utføre flere roller i utviklingsprosessen.

Hvem gjør hva?

Det første logiske trinnet er å bestemme din egen rolle i teamet. Du kan bli fristet på dette stadiet, siden du er bedriftseieren, for å automatisk anta at du også skal være prosjektarkitekt og prosjektleder, siden navnene på disse rollene innebærer lederskap.

Ikke la egoet din komme i veien for gode forretningsbeslutninger

Men stopp og tenk et øyeblikk ... er dette din styrke? Hvis du ser deg selv som flere av en koder eller en illustratør, kan det være lurt å vurdere å delegere lederrollene til noen med mer erfaring eller evne i disse rollene og ta ansvar for det kompetanseområdet hvor du er sterkest. Ikke la egoet din komme i veien for gode forretningsbeslutninger.

Nå kommer du til den morsomme delen, som også er den aller vanskeligste delen. Det er på tide å velge medarbeidere. Det første du må vite om dette er at det vanligvis er bedre å opprettholde et permanent kjerneteam som utfører de samme rollene i hvert prosjekt, og når det er nødvendig, kan du vurdere å innføre flere freelancearbeidere midlertidig for å fylle spesielle behov i et prosjekt.

Hvis du må rote rundt å bygge nye lag for hvert prosjekt, vil du kaste bort mer tid og bruke mer penger, og noen ganger får du skuffende resultater. Du kan til og med miste klienter. Finn så folk som du liker og stoler på, og gjør dem til en fast del av teamet ditt.

Finne gode lagmedlemmer

Feilen som mange mennesker gjør når man ansetter, er å definere lister over ferdigheter som er for komplekse og for restriktive. Noen ganger forstår ansettelsesledere ikke engang rollen. For eksempel, her er kravene angitt for en nylig annonsert front- end utvikler rolle:

  • Minst 3 års erfaring i PHP utvikling
  • Minimum 3 års erfaring i SQL / MySQL
  • Ferdig i WordPress, egendefinerte temaer, plugins, widgets, HTML, CSS, JS, JQuery.
  • Forstå grunnleggende Unix CLI
  • Opplev å jobbe med GIT
  • Erfaring med enhetstesting og QA
  • Sterk kunnskap om Unix Administrasjon
  • God kunnskap om UI-design
  • Erfaring med Agile Scrum-metodikk (essensielt)
  • Sterke dokumentasjonsferdigheter
  • Erfaring med e-postmarkedsføring, SEO og sosiale medier

Hvis du ikke kan se problemene med det ovenfor, er du en del av problemet. Svært få av ferdighetene som er oppført som påkrevd, har noe å gjøre med front-end-utvikling. De fleste ferdigheter er back-end, administrasjon og markedsføring ferdigheter. Det er absolutt ikke fornuftig å kreve disse ferdighetene til en front-end-utvikler, og du kan miste kvalitetskandidater ved å lage en så restriktiv liste.

En annen ting du trenger å vite er at kravet om kjennskap til fleksibel metodikk også er latterlig. Agile utvikling er effektiv i programvareutvikling hvor prosjektene er store og krever måneder av høyt nivå investering. Webprosjektene er helt forskjellige, og det er bare et rett utslag av penger for å bruke smidige metoder i de fleste webutviklingsmiljøer, ettersom du trenger å ansette ekstra kodere som du egentlig ikke trenger.

En mye bedre måte å annonsere for en front-end-utvikler ville være å bare angi:

  • Evne til å skrive tilpasset JavaScript-kode
  • Kjennskap til CSS
  • Evne til å tenke på føttene

Under intervjuprosessen fokuserer du hovedsakelig på den tredje faktoren, fordi det er langt viktigere for prosjekts suksess enn noen form for kodingsevne. Du må anta at alle som kan skrive kvalitet tilpasset JavaScript, har muligheten til å slå opp hvordan man gjør alt som må gjøres i et annet mer uklart språk. Ikke oppgi det uklare utviklingsspråket som en nødvendig ferdighet, fordi du vil gå glipp av å få en førsteklasses JavaScript-programmerer, noe som er viktigere for bedriften din.

Vok ditt team og din bedrift til en bærekraftig sats

De fleste små utviklingsbyråer skal kunne fylle alle nødvendige kjerneroller med bare 3 eller 4 ansatte, og utnevne frilansere når det er nødvendig. Etter hvert som bedriften din vokser, bør du begynne å tenke på å begrense oppgavene som hver person må dekke og skape et større lag.

Prøv å unngå å utvikle et bedriftshierarki og kultur. Den slags ting er det som fører til stagnasjon og fiasko av kreative bedrifter; Med en hierarkisk struktur får du konkurranse mellom dine ansatte, du får folk til å bli oppgradert til nivået av inkompetanse, og du får deltakelse.

Det du virkelig vil ha er at alle har likhet innen organisasjonen, ingen store forskjeller i lønn mellom mennesker med ulike roller, og alle føler at de gir et verdifullt bidrag til teamets suksess. På den måten kan du sikre at du har et effektivt utviklingslag som vil utvide virksomheten din og utvide porteføljen din raskere.

Utvalgt bilde, teamwork bilde via Shutterstock.