I styrer en udviklingsleverandør ved at aftale, hvad I vil se, og så se efter hver gang. Fire områder fortæller det meste uden at kræve, at nogen hos jer læser koden: kodegennemgang, test, udgivelser og dokumentation. Læg dem ind i en fast rytme med en demonstration, en kort status og et jævnligt møde mellem ledelserne, så har I et grundlag, der er bedre end leverandørens egen fortælling. Styring er et ledelsesarbejde, og det kan ikke overlades til den, der bliver styret.
Skift fra løfter til ting, der kan ses
Mange kunder følger en leverandør gennem statusmøder, hvor det hele er grønt, indtil det pludselig er rødt. Årsagen er sjældent uærlighed. Status bygger på vurderinger, og vurderinger er optimistiske. Spørg derfor efter spor i de systemer, leverandøren alligevel bruger. Det giver ikke ekstra arbejde for en velfungerende leverandør, for sporene findes allerede. Findes de ikke, har I lært noget vigtigt.
Fremdrift, set fra en ikke-teknisk stol, er beskrevet i sådan følger I fremdriften. Her handler det om kvaliteten af det arbejde, der foregår.
De fire områder
Kodegennemgang. En anden udvikler læser hver ændring, før den kommer med. Spørg: Sker det altid, og kan vi se det på kodeplatformen? Findes der ændringer, som samme person har skrevet og godkendt? I behøver ikke at forstå koden for at se, om der er en anden persons navn på godkendelsen.
Test. Automatiske test er små programmer, der kontrollerer, at produktet stadig virker efter en ændring. Tallet for, hvor meget af koden testene dækker, siger mindre, end det ser ud til. Spørg hellere: Bliver de vigtigste forløb, som oprettelse, betaling og login, testet automatisk? Kører testene ved hver ændring? Hvor mange fejl når kunderne, før I selv finder dem?
Udgivelser. En udgivelse, på engelsk release, er den handling, der bringer en ny version ud til brugerne. Sunde teams udgiver ofte og i små bidder. Se på, hvor tit det sker, hvor tit en udgivelse må rulles tilbage, og hvem der kan trykke på knappen. Sker det sjældent og med alle mand på vagt, er risikoen høj, se hver release er en risiko.
Dokumentation. Kan en ny udvikler komme i gang på få dage ud fra det skrevne? Er opsætningen af produktet beskrevet, og er de tekniske beslutninger skrevet ned med begrundelse? Testen er enkel. Bed om, at en person, der ikke har været med, følger vejledningen.
En rytme, der kan holdes
Styringen skal kunne bæres af en travl ledelse. Dette er en brugbar grundform:
- Hver eller hver anden uge: en demonstration af fungerende software, fra et miljø, I selv kan klikke i.
- Hver måned: en side med status på aftalt omfang, tid, risici og de fire områder.
- Hvert kvartal: et møde mellem ledelserne om samarbejdet, retningen og det, der skal ændres.
Skriv beslutninger ned, og lad en og samme person hos jer stå for kontakten. Mange stemmer fra kundens side er en almindelig årsag til forsinkelser, og den ligger hos jer selv. Hører flere hos jer ved direkte hos udviklerne, så saml det i én prioriteret liste.
Tegn på, at noget er ved at glide
Enkeltstående forsinkelser er normale i softwareudvikling. Hold øje med mønstre:
- Demonstrationerne bliver til skærmbilleder eller udskydes.
- Det samme punkt står som næsten færdigt flere måneder i træk.
- Fejl, der er rettet, kommer igen.
- Folk på opgaven bliver udskiftet uden varsel.
- Timerne stiger, mens de synlige resultater falder.
- I får forklaringer, I ikke kan efterprøve.
Tag det op, når I ser det. Bed om en plan med konkrete datoer. Holder planen ikke, er I på vej mod brændt af et udviklingshus, og så er det tid til at samle fakta.
Grænsen for, hvad styring kan afgøre
Styringen viser, om processen er sund, og om det aftalte kommer ud. Den siger mindre om, hvordan koden er indeni. Kodens kvalitet kræver en særskilt vurdering, som artiklen om uafhængig gennemgang beskriver. Ved rollen som fractional CTO er det almindeligt at læse sig ind på processen og vide, hvornår den slags gennemgang er pengene værd, mens selve vurderingen kan ligge hos en anden.
Også sikkerheden hører med. Hvad en aftale generelt bør sige om sikkerhed, kan I læse hos ciso-as-a-service.dk om leverandøraftaler. For leverandøren til produktet skal kravene også dække kode og udviklingsproces, se sikker softwareudvikling i et lille team.
Er der ingen hos jer med tid og erfaring til at holde rytmen, er det her, en beslutning skal træffes. Som fractional CTO kan Nielco IT stå for styringen af leverandøren, prioriteringen og møderne med ledelsen, og opgaven holder sig til ledelse, leverandører, teknologivalg og team. Kodearbejdet og vurderingen af leverandørens kode ligger uden for.
Det skal I lade være med
- At styre på statusfarver alene · spørg efter det, der kan ses i systemerne.
- At lade alle hos jer tale direkte med udviklerne · saml ønskerne i én prioriteret liste.
- At jage et bestemt dækningstal for test · tallet kan pyntes. Spørg til de vigtigste forløb.
- At vente med svære samtaler til kontrakten udløber · tag mønstret op, mens det kan rettes.
Det skal I kræve af den eksterne
- ☐ En aftalt liste over, hvad I får at se hver måned.
- ☐ Læsning af spor i systemerne frem for gengivelse af leverandørens status.
- ☐ En fast rytme for demonstrationer og ledelsesmøder.
- ☐ Skriftlig opfølgning på afvigelser med datoer.
- ☐ Klar besked, når et spørgsmål kræver en uafhængig udvikler.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Hvornår er en leverance færdig? · Når udviklingshuset også er jeres CTO
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
