Fremdrift i et softwareprojekt kan følges uden at læse en eneste linje kode. Tre vaner gør det meste: bed om en kørende version hver uge, som I selv kan prøve, få et testmiljø, som I har adgang til, og stil de samme få spørgsmål på hvert statusmøde. Statusrapporter og fremdriftstal siger meget lidt. Det, I kan klikke på, siger til gengæld næsten alt. Det gælder, uanset om I arbejder med freelancere, et bureau eller egne udviklere.
Regel et: en kørende version hver uge
Det stærkeste værktøj, I har, er at se produktet virke. Aftal, at der hver uge eller hver anden uge bliver vist en version, som kører, og som I selv kan prøve. Skærmbilleder og tegninger tæller ikke. Har udviklerne arbejdet i to uger uden noget at vise, er det et tegn, I skal tage alvorligt, selv om forklaringen lyder fornuftig.
Bed også om, at arbejdet skæres i små stykker. En stor funktion, der er “næsten færdig” i seks uger, siger intet. Fem små funktioner, hvor tre er færdige, siger meget. Aftal, hvad der gør en funktion færdig, se hvornår er en leverance færdig?.
Regel to: et testmiljø, I selv kan komme ind i
Et testmiljø er en særskilt udgave af produktet, som kunderne aldrig ser. Bed om eget login, og prøv det hver uge. Lav en lille liste over forløb, I gennemgår hver gang, fx oprette en bruger, gennemføre en bestilling og annullere den igen.
Gør det til en vane at skrive, hvad I finder, ét sted. Fejl, I selv har set, er det bedste grundlag for en samtale. I lærer også produktet at kende på en måde, ingen rapport kan give.
Få samtidig adgang til værktøjet, hvor opgaver og fejl registreres, og til kodearkivet. I behøver ikke læse koden. Det er nok at kunne se, at der sker ændringer, og at I ejer stedet, de ligger, se hvem der ejer koden og kontiene.
Regel tre: spørgsmål uden fagord
Stil de samme spørgsmål hver gang. Så bliver svarene sammenlignelige fra uge til uge.
- Hvad kan jeg gøre i produktet i dag, som jeg ikke kunne sidste uge?
- Hvad var planlagt, men blev ikke færdigt, og hvorfor?
- Hvad er der mest usikkerhed om lige nu?
- Hvad venter I på fra os?
- Hvis datoen skal holde, hvad skal så ud?
Svarene behøver ikke være perfekte. Det, I lytter efter, er, om I får besked om problemer, før de bliver til forsinkelser. Bliver et spørgsmål besvaret med fagord, så sig: “Forklar det, som du ville forklare det for en kunde.”
Tegn på, at noget er galt
- Datoen flytter sig i små ryk. En uge her og en uge der, altid med en ny grund.
- Alt er næsten færdigt. Mange ting er i gang, og få er afsluttet.
- Fejl kommer tilbage. Det, der er rettet, går i stykker igen, ofte fordi automatiske test mangler.
- Kun én kan forklare det. Spørgsmål går altid til samme person.
- I får et nyt ord for den samme forsinkelse. Refaktorering, arkitektur eller opgradering kan være nødvendigt. Bed om at få forklaret, hvad det giver produktet.
- Mødet bliver aflyst, når der ikke er noget at vise. Tag det som en melding.
Et enkelt tegn er sjældent alvorligt. Hold fast i at se på mønstre over flere uger. Fortsætter de, kan I læse videre i brændt af et udviklingshus, og spørgsmålet om, hvorfor tidsplaner glider, står i hvorfor holder estimaterne aldrig?.
Mødet på tredive minutter
En enkel rytme er nok til de fleste små projekter:
- Demo: udvikleren viser det nye i det kørende produkt.
- Prioritering: I vælger, hvad der er vigtigst i næste periode.
- Risici: det, der kan forsinke, og hvem der gør hvad ved det.
Skriv tre linjer efter mødet, og send dem rundt. Hvad er besluttet, hvad er flyttet, hvem gør hvad. Den lille note beskytter begge parter.
Det, I ikke selv kan se
Der er grænser for, hvad en ikke-teknisk stifter kan bedømme. Kvaliteten af koden, sikkerheden og om produktet kan vokse, viser sig sjældent i en demo. Et produkt kan se fint ud og være svært at bygge videre på. Det, I kan gøre, er at bede om test, kodegennemgang mellem udviklerne og en løbende kort melding om teknisk gæld, altså de hurtige løsninger, der senere skal rettes.
Har I behov for en erfaren person til at holde øje med det, I ikke selv kan se, kan en fractional CTO stille de tekniske spørgsmål på jeres vegne og samtidig lære jer, hvad I skal lytte efter. Hos Nielco IT ligger det i ledelsen af leverandører og team, mens selve koden forbliver hos dem, der bygger. Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Det skal I lade være med
- At måle på antal timer eller kodelinjer · de viser aktivitet, og I har brug for resultater.
- At vente med at prøve produktet til det er færdigt · brug det hver uge.
- At tie, fordi I føler jer utekniske · jeres spørgsmål om brugeren er de vigtigste.
Det skal I kræve af den eksterne
- ☐ En fast rytme for demo og status, der passer til jeres projekt.
- ☐ Klare kriterier for, hvornår en leverance er færdig.
- ☐ Oversættelse af tekniske forhold til betydningen for dato og risiko.
- ☐ Et overblik over de risici, der ikke kan ses i en demo.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Er vores udviklere gode? · Første version er leveret: hvad nu?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
