Et eksternt udviklingsteam er udviklere, der arbejder fast på jeres produkt, men er ansat hos en leverandør. I styrer prioriteterne, leverandøren står for ansættelse, ledelse af folkene og udskiftning. Her er, hvordan den fungerer i praksis, og hvad I skal have styr på, før I starter.
Det skal I vide
- I betaler for kapacitet over tid, ikke for en fastlåst leverance.
- Modellen passer bedst til et produkt, der skal udvikles løbende, og hvor kravene ændrer sig.
- I ejer prioriteterne. Leverandøren ejer bemandingen. Den deling skal stå i kontrakten.
- Regn med en indkøringsperiode, før teamet leverer i fuldt tempo.
- Mål på leveret værdi og kvalitet, ikke på timer.
- Aftal exit før opstart: kode, adgange og dokumentation skal kunne overtages.
Hvornår et eksternt udviklingsteam er det rigtige valg
Valget står typisk mellem tre modeller. Et fastprisprojekt passer, når opgaven kan beskrives færdigt på forhånd og har en tydelig slutdato. Freelancere passer til en afgrænset opgave, der kræver én bestemt kompetence i en kort periode. Et eksternt udviklingsteam passer, når arbejdet ikke stopper: et produkt med en køreplan, brugere der giver feedback, og prioriteter der flytter sig fra måned til måned.
Løbende produktudvikling i et fastprisprojekt giver ændringsanmodninger og diskussioner. Med freelancere ligger viden om systemet hos enkeltpersoner, der kan forsvinde med kort varsel. Et fast team løser begge dele.
Hvad I styrer, og hvad leverandøren styrer
Den mest almindelige misforståelse er, at I køber et team og så er fri for ledelse. Det er I ikke. Nogen hos jer skal eje produktet: beslutte hvad der bygges, i hvilken rækkefølge, og hvornår noget er godt nok.
- Jeres ansvar: prioriteter, accept af leverancer, adgang til forretningen og hurtige svar.
- Leverandørens ansvar: rekruttering, faglig ledelse, ferie- og sygdomsdækning, udskiftning af folk der ikke passer ind.
- Fælles: arbejdsgange, kodestandarder, test og udrulning.
Skriv delingen ned. Det er den aftale, I falder tilbage på, når noget går skævt.
Indkøring: de første uger afgør meget
Et nyt team kender hverken jeres kode, jeres kunder eller jeres uskrevne regler. Giv adgang til kode, miljøer og værktøjer fra dag ét. Sæt en person af til at svare på spørgsmål. Og start med små, rigtige opgaver frem for en lang introduktion.
Arver teamet et eksisterende system, er en kodeaudit i starten en god investering. Den giver jer og teamet samme billede af risiciene, før nogen bygger ovenpå.
Sådan måler I, om det virker
Timesedler fortæller, at folk har været på arbejde, ikke om I får noget for pengene. Se på det, der bliver leveret.
- Leverancer: hvor ofte kommer der noget i produktion, og bliver det brugt?
- Kvalitet: hvor mange fejl finder brugerne, og hvor hurtigt bliver de rettet?
- Forudsigelighed: holder teamet det, det siger, det når i en periode?
- Stabilitet: er det de samme mennesker, I arbejdede med for et halvt år siden?
Viden om jeres system sidder i hovederne på folk. Høj udskiftning betyder, at I betaler for indkøring igen og igen.
Exit og overtagelse af koden
Den bedste tid at aftale exit er, før I starter. Koden skal ligge i jeres eget repository, ikke leverandørens. Jeres virksomhed skal eje cloudkonti, domæner og licenser. Dokumentation og opsætning af udrulning skal være en del af det løbende arbejde, ikke noget der skrives i sidste måned.
Aftal også en overdragelsesperiode med opsigelsesvarsel, så et internt team eller en ny leverandør kan nå at lære systemet at kende. Er de forhold på plads, er I aldrig låst.
Sådan arbejder vi
Vores dedikerede udviklingsteams arbejder i jeres tidszone, i jeres værktøjer og efter jeres prioriteter. Har I kun brug for enkelte profiler, kan I leje udviklere enkeltvis, for eksempel full-stack-udviklere. Skal hele leverancen lægges ud med fast omfang, dækker outsourcing af softwareudvikling det, og et system i drift kan overgå til softwarevedligeholdelse.
Ofte stillede spørgsmål
Start mindre, end I tror. To eller tre udviklere med en klar produktejer hos jer leverer ofte mere end et stort team, der venter på afklaring. Udvid, når I kan holde dem, I har, beskæftiget med rigtige opgaver.
Ja, det bør I kunne. Bed om at møde de konkrete personer, før de starter, og sikr jer, at det er dem, der sidder på opgaven bagefter. Leverandøren finder kandidaterne og erstatter dem, der ikke fungerer.
Det skal I gøre, og det skal stå i kontrakten. Koden bør ligge i jeres repository fra første dag, så ejerskabet ikke afhænger af en overdragelse senere.
Leverandøren finder en afløser, og den nye person bliver kørt ind af resten af teamet. Aftal på forhånd, hvor hurtigt en afløser skal være på plads.
Hvad vi ville gøre
Vi ville starte med en produktejer hos jer, et lille team og en afgrænset første periode med rigtige opgaver. Kode og konti ligger hos jer fra dag ét, og exit-vilkårene står i kontrakten. Efter et par måneder ved I, om tempo og kvalitet holder.
Overvejer I et eksternt udviklingsteam? Skriv til os eller book et møde, så ser vi på, om modellen passer til jeres opgave.
