Slik onboarder du din nye utviklingspartner
God onboarding gir byrået tilganger, kontaktpunkter, beslutningsmyndighet og domenekunnskap allerede de første dagene. Samle kontoer, miljøer og dokumentasjon før oppstart, hold et oppstartsmøte (kickoff) som setter målbilde og arbeidsform, og sett av tid til å overføre virksomhetskunnskap. Det forebygger måneder med misforståelser og tomgang.
De første tretti dagene med et nytt utviklingsbyrå avgjør mer enn de fleste tror. Et byrå som får tilganger, kontekst og beslutningslinjer med en gang, kan levere verdi i løpet av et par uker. Et byrå som må jage innlogginger og gjette hvem som bestemmer, mister den første måneden på tomgang, og den tiden betaler du for. Onboardingen er ditt ansvar, ikke byråets, og den er en billig forsikring mot dyre misforståelser.
Samle tilgangene før de begynner
Ingenting dreper tempoet som en utvikler som sitter klar, men mangler innlogging. Samle alt byrået trenger fra dag én på forhånd, i én liste:
- Kode og kodelagre (repositorier), med rettigheter til å bidra, ikke bare lese.
- Miljøer: utviklings-, test- og ved behov produksjonsmiljø, med instruksjoner for hvordan de startes.
- Tredjepartstjenester som byrået skal jobbe mot: betaling, e-post, kart, analyse, det som er relevant.
- Design og dokumentasjon: eksisterende designfiler, tidligere kravdokumenter, arkitekturskisser og API-beskrivelser.
- Kontaktpunkter: hvem spør man om hva, i hvilken kanal, og hvem har myndighet til å ta hvilke beslutninger.
Å ordne dette tar dere noen timer. Å la være koster byrået dager, dager dere blir fakturert for.
Hold et oppstartsmøte som setter retningen
Et oppstartsmøte (kickoff) er ingen høflighetsgest. Det er der det felles bildet skapes. Møtet skal svare på fire spørsmål: Hvor skal vi? Hvordan jobber vi sammen? Hvem bestemmer hva? Hva gjør vi de nærmeste ukene?
Gå gjennom målbildet og hvordan dere måler suksess slik at byrået bygger verdi og ikke bare funksjoner. Presenter produktet og virksomheten i grove trekk. Bli enige om arbeidsform og møterytme: hvor ofte det er demo, hvordan fremdriften rapporteres, og hvor den daglige dialogen foregår. Og gjør roller og beslutningsmyndighet tydelige slik at ingen blir sittende og vente på et svar som ingen visste at de skulle gi.
Overfør virksomhetskunnskap bevisst
Byrået kan kode, men det kjenner ikke virksomheten deres. Det er den kunnskapen som skiller et produkt som passer, fra et som nesten passer: hvorfor en prosess ser ut som den gjør, hvilke unntak som finnes og hva kundene faktisk vil ha. Kunnskapsoverføringen er mest intens de første ukene, så planlegg for den.
Bland kanaler: Gi tilgang til skriftlig dokumentasjon, men sett også av tid til gjennomganger der byrået kan stille spørsmål og grave. La dem møte nøkkelpersoner i virksomheten, ikke bare prosjektledelsen. Regn med mange spørsmål i starten. Det er et godt tegn. Et byrå som ikke spør, har enten forstått alt eller ingenting, og det siste er vanligst.
Utpek en kontaktperson med tid og myndighet
Byrået trenger et fast kontaktpunkt inn i organisasjonen deres: en person med myndighet til å svare og ta løpende beslutninger, ofte en produkteier eller prosjekteier. Uten den personen stopper arbeidet opp, og hvert ubesvart spørsmål blir en blokkering.
Like viktig er det at personen har avsatt tid. Rollen fungerer ikke som en bigeskjeft ved siden av en full jobb. En fraværende kunde er en av de vanligste årsakene til at prosjekter sklir ut, for teamet blir tvunget til å gjette eller vente, og begge deler koster.
En enkel tidslinje for de første ukene
| Periode | Fokus |
|---|---|
| Før oppstart | Samle tilganger, kontoer og dokumentasjon i én liste |
| Dag 1–5 | Oppstartsmøte, målbilde, arbeidsform, byrået får miljøene opp og gå |
| Uke 2–3 | Intens kunnskapsoverføring, byrået leverer de første små resultatene |
| Uke 4 | Første skikkelige oppfølgingsmøte: Holder planen og rytmen? |
Den vanligste feilen: å jage tempo for tidlig
Den dyreste tabben er å presse byrået til å begynne å bygge før konteksten er på plass. Det føles effektivt: Dere betaler jo fra dag én og vil se kode. Men et byrå som begynner uten å forstå målbildet, virksomheten og beslutningene, bygger raskt i feil retning, og det som bygges feil, må bygges om. Tiden dere trodde dere sparte, taper dere dobbelt.
De første ukenes «treghet» er altså ikke bortkastet tid, men en investering. Et byrå som får tilganger, kontekst og beslutningslinjer på plass skikkelig, leverer mer på tre måneder enn et som ble kastet inn på én dag. Stå imot fristelsen til å måle fremdrift i kodelinjer den første uken. Mål den i hvor godt teamet har forstått hva de skal bygge, og hvorfor.
En siste detalj som ofte blir glemt: Bestem allerede i oppstarten hvordan dere skal jobbe sammen, ikke bare hva som skal bygges. Hvor foregår den daglige dialogen, hvor ofte blir det demo, og hvordan tas beslutninger når noe er uklart? Et team som vet hvordan samarbeidet fungerer, blir ikke sittende fast i unødvendig venting senere.
Vi i Weapp pleier å be om en samlet liste over tilganger og et oppstartsmøte før utviklingen starter, nettopp for at de første ukene skal gå til arbeid i stedet for venting. Vil du se hvordan et samarbeid kan legges opp? Se på tjenestene våre eller ta kontakt.
Ofte stilte spørsmål
Hvor lang tid tar det før et byrå er produktivt?
Med god onboarding kan de levere verdi i løpet av én til to uker; uten den kan det ta måneder. Forskjellen ligger nesten helt i hvor raskt de får tilganger, forstår domenet og vet hvem som bestemmer. Forberedelsene er kundens ansvar, ikke byråets, og de betaler seg med en gang.
Hvilke tilganger trenger byrået fra dag én?
Kodelagre, utviklings- og testmiljøer, relevante tredjepartstjenester, designfiler og den dokumentasjonen som finnes. Like viktig er kontaktpunkter og hvem som har myndighet til å bestemme hva. Samle alt på forhånd slik at den første dagen går til arbeid og ikke til å jage innlogginger.
Hva skal et oppstartsmøte inneholde?
Målbilde og suksesskriterier, en gjennomgang av produktet og virksomheten, arbeidsform og møterytme, roller og beslutningsmyndighet samt planen for de nærmeste ukene. Formålet er et felles bilde og tydelige kontaktpunkter, ikke en statusgjennomgang. Book gjerne møtet før utviklingen kommer i gang.
Hvordan overfører vi virksomhetskunnskap effektivt?
Bland skriftlig og muntlig: Gi tilgang til eksisterende dokumentasjon, men sett også av tid til gjennomganger der byrået kan stille spørsmål. La dem møte nøkkelpersoner i virksomheten. Regn med at kunnskapsoverføringen er mest intens de første ukene og deretter avtar.
Hvem bør være byråets faste kontaktperson hos oss?
En person med myndighet til å svare på spørsmål og ta løpende beslutninger, ofte en produkteier eller prosjekteier. Uten et tydelig kontaktpunkt blir byrået sittende og vente på svar. Den personen trenger også avsatt tid; rollen fungerer ikke som en bigeskjeft ved siden av alt annet.