Rollene i et utviklingsprosjekt forklart

Et digitalt prosjekt fullt av titler kan føles som en jungel for den som ikke er tekniker. Hva er egentlig forskjellen på en tech lead og en prosjektleder, og trenger dere virkelig alle rollene på én gang? Kortversjonen: Rollene er funksjoner som må utføres, ikke nødvendigvis personer som må ansettes. Her er kartet over hvem som gjør hva, og hvilke roller du aldri bør gi helt fra deg.

Rollekartet for et typisk produktteam

I et fullt bemannet produktteam går noen sentrale roller igjen. Tenk på dem som funksjoner: I store prosjekter er de ulike personer, i små kan flere fylles av samme person.

• Produkteier. Eier visjonen, prioriterer hva som skal bygges og i hvilken rekkefølge, og tar beslutningene. Rollen sitter som oftest på kundesiden.
• UX-designer. Former hvordan produktet fungerer og oppleves for brukeren: flyt, grensesnitt og at det faktisk er forståelig.
• Frontendutvikler. Bygger det brukeren ser og samhandler med.
• Backendutvikler. Bygger motoren under overflaten: databaser, logikk, kontoer og integrasjoner.
• Tech lead. Setter den tekniske retningen, veier arkitektur mot kvalitet og holder utviklerne samlet teknisk.
• Tester / QA. Sikrer at det som bygges, faktisk fungerer før det når brukerne.

I tillegg er det ofte en prosjektleder som samordner planlegging, kommunikasjon og leveranse. Hos et byrå er det som regel den du har mest kontakt med i hverdagen.

Minimumsbemanning i små prosjekter

Ikke alle prosjekter trenger et team på åtte personer. For et enklere produkt eller en MVP kan bemanningen reduseres kraftig uten at noen funksjon faller bort. De blir bare fordelt på færre hender.

Et lite, men komplett team kan bestå av én person som kombinerer UX og produkttenkning, én eller to fullstackutviklere som dekker både frontend og backend, og en senior utvikler som samtidig er tech lead. Testing blir vevd inn i utviklernes arbeidsform i stedet for å være en egen rolle. Produkteierskapet blir liggende hos deg som kunde.

Det avgjørende er ikke hvor mange personer som er involvert, men at hver nødvendig funksjon faktisk blir utført av noen. Faren er ikke et lite oppsett. Faren er en rolle som alle tror at noen andre tar seg av, men som ingen gjør. Spør deg heller hvem som eier hver funksjon enn hvor mange navn som står på listen.

Et konkret eksempel

La oss si at du skal bygge en enkel bookingapp som en MVP. Du trenger ikke å ansette seks spesialister. En UX-designer skisserer flyten og grensesnittet, en fullstackutvikler bygger både app og backend, og en senior utvikler trer inn som tech lead og kvalitetssikrer. Du selv er produkteier og bestemmer hva som er viktigst å få med i den første versjonen.

Det er fire roller fordelt på kanskje to og en halv person. Når produktet vokser og flere funksjoner kommer til, kan du dele opp rollene, for eksempel legge til en rendyrket backendutvikler eller en egen tester, i takt med at behovet blir reelt. Å bemanne for den størrelsen du faktisk har, er nesten alltid klokere enn å bemanne for den du håper på.

Roller du aldri bør sette helt ut

Et byrå kan fylle nesten hvilken som helst rolle i det tekniske arbeidet. Men én rolle bør alltid ha en tydelig eier hos deg: produkteierskapet.

Ingen ekstern part kjenner virksomheten, kundene og målene dine bedre enn du selv. Gir du bort beslutningene om hva som skal bygges og hvorfor, mister prosjektet kompasset sitt. Teamet bygger da det de tror du vil ha, heller enn det du faktisk trenger. Et byrå kan og bør støtte produkteieren med beslutningsgrunnlag og anbefalinger, men den endelige prioriteringsbeslutningen skal være din.

Den samme logikken gjelder den overordnede styringen: Du bør alltid ha noen som forstår helheten godt nok til å stille kritiske spørsmål og ta de store veivalgene.

Vi i Weapp setter sammen team etter hva akkurat ditt produkt krever, og ser gjerne at du beholder produkteierskapet. Det gjør resultatet bedre. Vil du vite hvordan et team ville se ut for ideen din? Les om tjenestene våre eller ta kontakt med en kort beskrivelse.