Udviklingsteam og udviklingsleverandører

Et softwareprodukt bliver bygget af mennesker, og hverdagens ledelsesopgaver handler mest om dem: hvem der skal bygge, hvordan arbejdet styres, og hvornår noget er færdigt. Det gælder, hvad enten det er tre egne udviklere, en freelancer eller et udviklingshus i et andet land. Siden her samler artiklerne om hverdagen med dem, der bygger, fra det første tilbud til et team, der er blevet for stort til at sidde om ét bord. Er forløbet allerede kørt fast, begynder I i stedet under udvikling, der ikke leverer.

Det, der går igen

Uanset model skal fire ting være på plads. Nogen hos jer skal eje produktet og afgøre prioriteringen. Koden og kontiene skal være jeres. Der skal være en aftale om, hvornår en leverance er færdig. Og viden må ikke forsvinde, når en person eller en leverandør stopper. Ejerskabet har sin egen tjekliste over kode, domæne og cloudkonto, og sammenhængen til ledelsen af de tekniske valg står under arkitektur og teknologivalg.

Hvem skal bygge?

• Freelancer, bureau eller eget team til første version De tre løsninger set fra jeres side: hvor meget I selv skal styre, og hvor viden ender bagefter.
• Nearshore og offshore udvikling: hvad det kræver af jer Krav til specifikation, gennemgang og tilstedeværelse, og hvilken rolle der skal blive hjemme.
• Når udviklingshuset også er jeres CTO Interessekonflikten, når samme leverandør anbefaler og leverer, og hvad en uafhængig rolle ændrer.

Tilbud og aftale

• Det skal I have klar, før I beder om et tilbud på en app To sider om brugere, kerneflow, data og integrationer, som gør tilbuddene til at sammenligne.
• Second opinion på et tilbud fra et udviklingshus Sådan læser I løsning og omfang: antagelser, det udeladte, og hvem der reelt arbejder på opgaven.
• De tekniske krav, der skal med i udviklingsaftalen Adgang til kode og miljøer, dokumentation, test, overdragelse og en enkel proces for ændringer.

Styring af leverancen

• Sådan styrer I en udviklingsleverandør, der bygger produktet Kvalitet, der kan følges løbende, gennem faste rutiner for gennemgang, test, release og dokumentation.
• Hvornår er en leverance færdig? Fælles kriterier, jeres egen test og den dokumentation, der skal ligge klar, inden I godkender.

Eget team

• Ansættelse af de første udviklere Profilen, den tekniske samtale og prøveopgaven, når ingen i ledelsen kan vurdere kode.
• En udviklingsproces, der passer til fem udviklere Det mindste sæt rutiner, også når kodegennemgange begynder at hobe sig op.
• Hvornår skal I have den første teamleder for udviklerne? Tegnet er tiden, personaleopgaver tager, og den bedste udvikler er ikke altid det rigtige valg.
• Fra fem til tyve udviklere: sådan organiserer I teamet Teams, ansvar, ejerskab af kode og møder, når folk ikke længere kan følge med i det hele.
• Er vores udviklere gode? Sådan vurderer I det uden selv at kunne kode De tegn, I kan læse uden teknisk baggrund, og hvor I må have hjælp fra en anden fagperson.
• Når de erfarne udviklere vil videre Faglige grunde til at blive, herunder indflydelse og et spor uden personaleansvar.

Når det er svært at vælge model

Valget af model afhænger mest af, hvor meget styring I selv kan bære. En leverandør kan bygge hurtigt og stiller samtidig krav til den, der bestiller. Eget team koster tid til ledelse, og til gengæld bliver viden i huset. Mange ender med en blanding, og så bliver grænsefladen mellem de to den vigtigste beslutning. Her kan en teknisk leder på deltid gøre en forskel ved at stå på jeres side af bordet, når aftaler indgås og leverancer godkendes.

Det skal I lade være med

• At sammenligne tilbud, der bygger på hver sin forståelse af opgaven · lav beskrivelsen først.
• At lade leverandøren godkende sin egen leverance · test i jeres eget miljø, før I siger ja.
• At bede den samme person om at bygge og vurdere alt · det giver en blind plet.

Det skal I kræve af den eksterne

• ☐ Uafhængighed af de leverandører, I bruger eller overvejer.
• ☐ Faste rutiner for opfølgning, som I selv kan læse.
• ☐ Klare kriterier for, hvornår en leverance godkendes.
• ☐ En plan for ansættelser, der passer til produktets fase.

Senest gennemgået: november 2026.

Næste skridt

• Sådan styrer I en udviklingsleverandør, der bygger produktet
• Sådan foregår et forløb

Læs også: Artikler om CTO as a Service · Når jeres tekniske leder ikke kan nå det hele

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT