Hvor står produktet? Selvtests for ledelsen

Testene her er til ledelsen i en virksomhed, hvor softwaren er forretningen. Der er syv korte test, en til hver af de situationer, vi oftest skriver om. Tag den, der ligner jeres, eller tag dem alle. Der er ingen formular, og intet bliver sendt nogen steder hen: I svarer ja eller nej og ser resultatet her på siden.

Svar kun ja, når I kan fremvise det: en aftale, en kørende version, en konto i virksomhedens navn eller en, der faktisk har prøvet det. Bag hvert nej står en artikel med det, I kan gøre ved det. Ingen af spørgsmålene kræver, at I selv kan læse kode. Er I i tvivl om et svar, så spørg den, der bygger produktet, om at vise jer det.

Test 1: Er I klar til at få bygget noget?

1. Kan I på to sider beskrive brugerne, kerneforløbet, og hvad der må vente? · Hvis nej: Før I beder om et tilbud
2. Ved I, hvad første version skal lære jer, og hvad der derfor kan blive ude? · Hvis nej: Hvad skal med i første version?
3. Kommer koden, cloudkontoen og domænet til at stå i virksomhedens navn fra første dag? · Hvis nej: Ejer I selv koden og kontiene?
4. Er det aftalt skriftligt, hvem der får rettighederne til det, der bliver skrevet? · Hvis nej: Hvem ejer koden?

Test 2: To uger uden stifteren

1. Kan en anden end stifteren rette en alvorlig fejl og lægge rettelsen ud til kunderne? · Hvis nej: Hvad slipper du først?
2. Kan salget få svar på et teknisk spørgsmål, uden at det ender i stifterens indbakke? · Hvis nej: Den tekniske stifter er blevet flaskehalsen
3. Kender mindst to personer de dele af koden, kunderne er mest afhængige af? · Hvis nej: Når én udvikler kender koden
4. Ligger alle konti og nøgler hos virksomheden frem for i stifterens private navn? · Hvis nej: Den tekniske stifter forlader virksomheden

Test 3: Går beslutningerne gennem én person?

1. Kan teamet træffe almindelige tekniske beslutninger uden at vente på den samme person? · Hvis nej: Lead developeren er blevet flaskehalsen
2. Kan ledelsen pege på, hvem der ejer arkitekturen, altså produktets tekniske opbygning? · Hvis nej: Tegn på manglende teknisk ledelse
3. Står de store tekniske beslutninger skrevet ned med begrundelse? · Hvis nej: Skriv de tekniske beslutninger ned
4. Har den, der leder teknikken, tid til at lede ved siden af kodningen? · Hvis nej: Har vi brug for en CTO?

Test 4: Hvis CTO’en stopper i morgen

1. Har I en opdateret liste over adgange, nøgler og konti, og kan andre end CTO’en åbne dem? · Hvis nej: CTO’en har sagt op
2. Ved I, hvad der holder op med at virke, hvis personens egen konto bliver lukket? · Hvis nej: CTO’en skal stoppe med det samme
3. Kan andre forklare, hvorfor produktet er bygget, som det er, og hvad der er skrøbeligt? · Hvis nej: Opsigelsesperioden
4. Er det aftalt, hvem der træffer de tekniske beslutninger, indtil en ny er på plads? · Hvis nej: Hvad en interim CTO skal afgøre

Test 5: Kan I svare på kundens spørgsmål?

1. Har I en kort arkitekturbeskrivelse, som en kundes IT-afdeling kan læse? · Hvis nej: Arkitekturbeskrivelsen på tre sider
2. Kan I sige præcist, hvor data ligger, også backup, logning og support? · Hvis nej: Hvor ligger data?
3. Ved I, hvem der svarer på kundens spørgeskema, og er svarene ens fra kunde til kunde? · Hvis nej: Kundens spørgeskema om produktet
4. Ved I, hvem der stiller op, når kundens IT-arkitekt vil have et møde? · Hvis nej: Møde med kundens IT-arkitekt

Test 6: Leverer dem, der bygger for jer?

1. Ser I en kørende version med faste mellemrum, som I selv kan prøve? · Hvis nej: Følg fremdriften uden at kunne kode
2. Er det aftalt på forhånd, hvad der skal til, før I godkender en leverance? · Hvis nej: Hvornår er en leverance færdig?
3. Kan I selv hente en kopi af koden i dag uden at spørge leverandøren om lov? · Hvis nej: Leverandøren vil ikke udlevere koden
4. Kan I gøre status over det byggede: hvad fungerer, og hvad står tilbage? · Hvis nej: Brændt af et udviklingshus

Test 7: Er produktet driftsklart?

1. Ved I, hvad der først giver sig, når kunderne bliver flere, og kan I se det komme? · Hvis nej: Skalering før det går galt
2. Har I genskabt produktet fra backup og taget tid på det? · Hvis nej: Kan I genskabe produktet?
3. Bliver nogen varslet, før kunderne ringer, og ved de, hvem der gør hvad? · Hvis nej: Overvågning, vagt og hændelser
4. Kan I rulle en dårlig udgivelse tilbage på kort tid? · Hvis nej: Hver release er en risiko

Sådan læser I resultatet

Fire ja i en test betyder, at grundlaget er på plads for den situation. Hold fast i det, der får det til at virke, og tag testen igen, når teamet eller produktet har ændret sig.

Et enkelt nej er almindeligt. Skriv det op med et navn og en dato, og giv det plads i planen.

To eller flere nej i samme test peger på en konkret svaghed, og den kommer sjældent på plads af sig selv. Læs artiklerne, og begynd med det spørgsmål, der kan gøre mest skade, hvis det går galt i morgen. Oftest er det adgange og konti, fordi resten er svært uden.

Nej i flere af testene tyder på noget andet: at ingen har fået opgaven at lede teknikken. Den vurdering kan I tage videre med Har vi brug for en CTO? og Er det for tidligt?. Vil I have tilstanden beskrevet af en udefra, før noget aftales, står det på Gennemgang af produktet som første skridt.

Det skal I lade være med

• At lade den, det handler om, svare alene · spørgsmålene virker bedst, når ledelsen og den tekniske person gennemgår dem sammen.
• At bruge testen som karakter til udviklerne · de fleste nej skyldes opgaver, ingen har fået, og det er ledelsens at rette.
• At tage alle nej på én gang · vælg rækkefølgen efter, hvad der kan gøre mest skade.

Det skal I kræve af den eksterne

• ☐ At hvert nej får en ansvarlig og en dato i den tekniske køreplan.
• ☐ At forklaringerne kan følges af en ledelse uden teknisk baggrund.
• ☐ At I kan se ændringen næste gang, I tager testen.

Senest gennemgået: november 2026.

Næste skridt

• Gennemgang af produktet som første skridt
• Fractional CTO: teknisk ledelse af produktet på deltid

Læs også: Tjeklister og skabeloner til produktet · Spørgsmål om CTO as a Service

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