Holder det med én utvikler, eller trenger du et team?
Én utvikler holder for små, avgrensede prosjekter og tidlige prototyper. For et produkt som skal settes i produksjon og leve over tid, gir det tre risikoer: nøkkelpersonavhengighet, ingen som går gjennom koden og for smal kompetanse. Det minste fornuftige teamet for et fullverdig produkt består av utvikling, design og en form for kodegjennomgang eller QA.
Det er det første spørsmålet mange små kunder stiller: Kan ikke én flink utvikler fikse alt sammen? Noen ganger er svaret ja. Men spørsmålet rommer en skjult avveiing, for forskjellen mellom én person og et lite team handler ikke bare om kapasitet, men om risiko og bredde. En utvikler alene kan bygge imponerende ting, helt til produktet skal ut i virkeligheten og fungere dag etter dag.
Hva én utvikler klarer godt
Det finnes mange situasjoner der én person er det selvsagte og billigste valget. Små, godt avgrensede oppgaver. Interne verktøy med en håndfull brukere. Og kanskje viktigst: tidlige prototyper, bygget for å teste om en idé i det hele tatt holder før det satses større penger.
Felles for dem er at lite står på spill, og at avhengigheten er lav. Ingen får panikk om verktøyet er nede en ettermiddag, og ingenting forretningskritisk står og faller med at systemet alltid fungerer. Så lenge det stemmer, er én utvikler raskere, enklere og billigere enn et team. Ikke overdimensjoner løsningen på et lite problem.
De tre risikoene når én person bærer alt
Så snart produktet skal settes i produksjon og leve over tid, endrer regnestykket seg, og tre risikoer trer frem:
- Nøkkelpersonavhengighet. Blir personen syk, slutter eller bare forsvinner en periode, stopper alt opp. Kunnskapen om hvordan systemet fungerer, kan sitte i ett eneste hode og forsvinne ut døren sammen med personen.
- Ingen kodegjennomgang. Et ekstra par øyne fanger opp feil, snarveier og tvilsomme beslutninger før de blir dyre. En utvikler alene går gjennom sitt eget arbeid, og det man har bygget selv, er man dårligst til å se kritisk på.
- For smal kompetanse. Et ferdig produkt krever design, backend, sikkerhet og drift. Nesten ingen behersker alt på høyt nivå. Det som ligger utenfor personens sterke side, blir ofte det som svikter.
Ingen av risikoene merkes i begynnelsen. Alle tre merkes akkurat når det koster mest å oppdage dem.
Det minste fornuftige teamet for et produkt i drift
Skal noe faktisk settes i produksjon og vedlikeholdes, er minimum som regel tre funksjoner. Det trenger ikke å være tre personer på heltid, men tre roller som må være dekket:
- Utvikling: den som bygger.
- Design og brukeropplevelse: den som sørger for at produktet er brukbart, ikke bare at det fungerer teknisk.
- Gjennomgang eller QA: noen som tester og kvalitetssikrer, formelt eller ved at kollegene går gjennom hverandres kode.
Poenget er ikke antall hoder, men at funksjonene finnes. Faller én av dem bort, er det den som senere viser seg å ha vært viktigst. Et produkt uten noen som går gjennom arbeidet, blir ustabilt; et produkt uten design blir vanskelig å bruke; et produkt uten tydelig utviklingsansvar blir ingenting i det hele tatt.
Kostnadstrappen
Et team koster mer per time enn en konsulent alene. Det er sant, men ikke hele sannheten. Trappen ser omtrent slik ut: En frilansutvikler er billigst per time og passer for små oppdrag; et lite team koster mer, men bærer risiko og bredde som én person ikke kan; et større team gir kapasitet og trygghet, men også overhead.
Det avgjørende er å sammenligne riktig. En utvikler alene som kjører seg fast, overser et sikkerhetshull eller bygger noe ingen andre kan ta over, kan til slutt bli dyrere enn et lite team som gjør ting riktig fra start. Timeprisen er den synlige kostnaden; risikoen og det langsiktige eierskapet er de usynlige, og ofte de største.
Et scenario
Si at du har en idé og vil se om den har noe for seg. La en dyktig utvikler bygge en prototyp: raskt, billig, én person er nok. Testen går bra, og ideen skal bli et produkt som kunder betaler for og stoler på. Nå endrer behovet karakter: Du trenger design som holder mål, noen som går gjennom koden, og en plan for drift og forvaltning. Å presse alt dette inn hos den samme utvikleren er å bygge inn alle tre risikoene på én gang. Den kloke veien er å vokse fra én person til et team i takt med at det står mer på spill.
Vi i Weapp setter sammen team etter hva prosjektet faktisk krever (noen ganger en håndfull personer, noen ganger flere) og sørger for at ingen funksjon faller mellom to stoler. Vil du vite hvilken bemanning ideen din trenger? Se på tjenestene våre eller ta kontakt.
Ofte stilte spørsmål
Når holder det virkelig med én eneste utvikler?
For små, godt avgrensede oppgaver, interne verktøy med få brukere og tidlige prototyper som skal teste en idé. Så lenge lite står på spill og ingen er avhengig av at systemet alltid fungerer, er én utvikler både raskere og billigere. Spørsmålet blir et annet så snart produktet skal settes i produksjon.
Hva er risikoene ved å stole på én person?
Det er tre. Nøkkelpersonavhengighet: Blir personen syk, slutter eller forsvinner, stopper alt opp, og kunnskapen kan være borte. Ingen kodegjennomgang: Feil og snarveier blir ikke oppdaget av et ekstra par øyne. Og for smal kompetanse: Ingen behersker alt et ferdig produkt krever, altså design, backend, sikkerhet og drift på samme tid.
Hvor lite kan et fullverdig team være?
For et produkt som skal settes i produksjon, er minimum som regel tre roller, selv om ikke alle er på heltid: noen som utvikler, noen som har ansvar for design og brukeropplevelse, og en form for kodegjennomgang eller kvalitetssikring. Rollene kan fordeles på færre personer, men funksjonene må finnes. Ellers faller noe mellom to stoler.
Er ikke et team alltid dyrere enn én enkelt utvikler?
Per time, ja. Men totalt er det ikke gitt. En utvikler alene som kjører seg fast, overser sikkerhetshull eller bygger noe ingen andre kan ta over, kan til slutt bli dyrere enn et lite team som gjør ting riktig fra begynnelsen. Regn på risiko og langsiktig eierskap, ikke bare på timeprisen.
Kan jeg begynne med én utvikler og vokse til et team senere?
Ja, og det er ofte en klok vei. En prototyp eller en første test kan godt bygges av én person. Men planlegg overgangen bevisst: Når ideen skal bli et produkt i drift, trengs flere funksjoner, og kunnskapen fra den første utvikleren må kunne føres videre i stedet for å sitte fast i ett hode.