Ikke undervurder oppstartsfasen. Den første måneden av samarbeidet avgjør mer enn du tror.
Du har brukt måneder på å finne de rette folkene, blitt enige om betingelser og ser frem til å komme i gang. Det er naturlig å ønske synlige resultater raskt, og likevel er det å presse på leveranser fra dag én en av de vanligste feilene vi ser.
Teamene som bruker de første ukene godt, leverer bedre kode, tar bedre beslutninger og trenger langt sjeldnere å gå tilbake og løse opp i det de allerede har bygd.
Her er tre ting vi anbefaler kundene våre å prioritere i oppstartsperioden:
Utviklerne er ansatt for å løse problemer, og for å gjøre det godt trenger de å forstå virksomheten din på et nivå som går langt dypere enn en kravspesifikasjon. Hvem er brukerne egentlig, og hva sliter de med? Hva er den underliggende logikken bak produktet, og hvilke beslutninger har dere tatt de siste årene og hvorfor?
De beste utviklerne er nysgjerrige på disse spørsmålene, og svaret på dem er sjelden skrevet ned noe sted. Det er noe du vet, og som teamet trenger å lære av deg.
Sett av tid til å forklare kontekst, ta dem med i relevante møter og vær raus med bakgrunnen for valgene dere har gjort. Et av teamene våre jobbet på et prosjekt for oljebransjen og fikk en grundig innføring i sektoren tidlig i oppstarten. Det endret måten de forstod produktet på, og den innsikten var umulig å lese seg til.
Alle kodebaser bærer historien til selskapet som har bygd dem. Det er arkitektoniske valg fra fem år siden, konvensjoner ingen husker opprinnelsen til og avhengigheter som bare den som har jobbet der lenge kjenner godt. Å forstå alt dette tar tid, og det er ikke bortkastet tid.
En god tilnærming er å la teamet starte med en bugfix, noe som gir dem et naturlig overblikk over systemet uten at de trenger å ta store arkitekturmessige beslutninger tidlig. Det lønner seg også å sette i gang kodegjennomganger raskt, slik at dere etablerer felles standard fra starten av.
Leif Arild Åsheim i Promineo forteller at teamet deres brukte de første ukene på å sette seg inn i en kodebase som var ti år gammel. Det la grunnlaget for et samarbeid som har vart i årevis.
Det meste av kommunikasjonen mellom deg og teamet kommer til å skje via skjerm, og det fungerer overraskende godt når folk kjenner hverandre fra før. Arkitekturdiskusjoner, vanskelige tilbakemeldinger og de samtalene som ikke har en naturlig plass i en Jira-ticket, flyter mye lettere når det ligger en solid relasjon i bunn.
Vi anbefaler derfor alltid et fysisk besøk tidlig i samarbeidet, gjerne i løpet av de første månedene. Det trenger ikke å være mer enn noen dager, men de dagene gjør noe med dynamikken som er vanskelig å gjenskape via en skjerm. Videre anbefaler vi å ha et teambesøk årlig for å vedlikeholde det som er bygd opp.