En second opinion på et tilbud er en uafhængig læsning af løsning og omfang, inden I skriver under. Den skal svare på tre spørgsmål: hvilke antagelser bygger tilbuddet på, hvad er udeladt, og hvem arbejder reelt på opgaven? Meget af det kan I selv se uden at kunne kode. Det, I ikke selv kan bedømme, er, om den foreslåede løsning passer til jeres produkt, og der hjælper en erfaren teknisk læser, som ikke selv skal levere opgaven. Her er en læsevejledning til jeres egen planlægning. Prisniveauet er et andet spørgsmål og behandles ikke her.
Læs antagelserne først
Hvert tilbud bygger på gæt om jeres produkt. Nogle står der, andre skal I selv finde. Understreg sætninger som “det forudsættes”, “standard” og “enkel”. Spørg derefter, hvad der sker, hvis antagelsen ikke holder.
Typiske steder at se efter:
- Integrationer. Er forbindelsen til jeres øvrige systemer antaget at være enkel, og hvem har set den anden parts dokumentation?
- Data. Tilbuddet kan regne med, at data er rene og klar til flytning. Er de det?
- Jeres egen indsats. Hvor hurtigt skal I svare, og hvem skal teste? Bliver I forsinkede, kan det tælle mod jer.
- Omfang. Står “login”, “administration” eller “rapporter” som ét ord, kan det dække over meget forskellige løsninger.
Find det, der ikke står
Det udeladte er oftest det vigtigste. Gå disse punkter igennem, og skriv “med”, “uden” eller “uklart” ud for hvert:
- Test. Hvem tester, med hvilke typer test, og er der automatiske test med i leverancen?
- Drift. Hvor kører produktet, hvem overvåger det, og hvem reagerer, når det går ned?
- Dokumentation. Får I en beskrivelse, som en anden udvikler kan arbejde ud fra?
- Overdragelse. Hvad får I med, hvis I skifter leverandør? Se også skift af udviklingsleverandør.
- Sikkerhed. Hvordan håndteres adgangsstyring, nøgler og personoplysninger?
- Vedligehold efter lancering. Hvem retter fejl og opdaterer biblioteker? Første version er leveret beskriver, hvad der følger efter.
- Ændringer. Hvordan håndteres ønsker undervejs, og hvem godkender dem?
Et “uklart” skal besvares på skrift, inden I underskriver. Ét eksempel, så I ved, hvad I kigger efter: tilbuddet nævner “support i 30 dage efter lancering”, men siger intet om, hvem der opdaterer systemet derefter. Så mangler et svar.
Hvem arbejder reelt på opgaven?
Den person, der var med til mødet, er ikke altid den, der skriver koden. Spørg:
- Hvem er på holdet, og hvor erfarne er de?
- Er de fastansatte, underleverandører eller i et andet land?
- Hvor stor en del af tiden arbejder de på jeres opgave?
- Hvem er teknisk ansvarlig, og kan I møde personen inden aftalen?
- Hvad sker der, hvis nøglepersoner skifter?
Hvis noget af arbejdet udføres ved en underleverandør eller i udlandet, er det ikke et problem i sig selv. Det kræver dog noget andet af jeres styring, se nearshore og offshore udvikling.
Passer løsningen til jeres problem?
Her kan I komme et stykke, men sjældent hele vejen selv. Stil disse spørgsmål til tilbudsgiveren, og lyt efter, om svaret handler om jeres situation:
- Hvorfor netop denne teknologi til netop vores opgave?
- Hvad ville I gøre anderledes, hvis opgaven var halvt så stor?
- Hvilken del er sværest, og hvordan afprøver I den først?
- Hvor ville I forvente, at projektet bliver dyrere eller langsommere?
Et godt udviklingshus svarer gerne på det. Bliver I mødt med fagord eller forsikringer, har I lært noget om samarbejdet. Sammenlign også tilbuddet med det, I faktisk bad om. Var jeres beskrivelse af opgaven uklar, vil tilbuddene pege i forskellige retninger, og så er det beskrivelsen, der skal rettes først.
Hvem skal læse med?
En second opinion skal komme fra en, der ikke selv kan få opgaven. En anden leverandør har en interesse i at finde fejl, og det udviklingshus, der har givet tilbuddet, kan ikke være dommer i egen sag, se når udviklingshuset også er jeres CTO. Bed den, der læser med, om at skrive svaret kort: hvad er i orden, hvad skal afklares, og hvad ville vedkommende spørge om.
Læsningen handler om at give ledelsen et bedre grundlag for jeres egen beslutning. Det, en erfaren teknisk læser kan give, er spørgsmålene, I skal stille, og en ærlig vurdering af, om omfanget hænger sammen med det, I vil opnå.
Har I brug for den slags læsning som del af et forløb, omfatter Nielco IT’s fractional CTO-opgaver netop leverandører og teknologivalg, og det kan begynde med en gennemgang som første skridt. 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 sammenligne tilbud, der ikke dækker det samme · bed alle svare på samme punkter.
- At spørge en konkurrent til tilbudsgiveren · vedkommende har en interesse i svaret.
- At lade uklarheder stå, fordi tonen er god · få svarene på skrift, før I underskriver.
Det skal I kræve af den eksterne
- ☐ Et kort skriftligt svar med det, der er i orden, og det, der skal afklares.
- ☐ En liste over spørgsmål, I kan sende til tilbudsgiveren.
- ☐ Oplysning om eventuelle bindinger til udviklingshuse.
- ☐ En ærlig melding, hvis det rigtige svar er at gå videre med tilbuddet, som det er.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Freelancer, bureau eller eget team · Hvornår er en leverance færdig?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
