Sådan kører I en ærlig discovery-uge

De fleste softwareprojekter, der skrider, skrider ikke fordi nogen kodede langsomt. De skrider fordi I startede med en liste, alle nikkede til, og som betød tre forskellige produkter. En kravspecifikation på fyrre sider kan stadig være den liste — bare med mere tekst. "Systemet skal understøtte fakturering" er ikke et krav. Det er en kategori. Indtil I har besluttet hvem der fakturerer hvem, hvad der sker ved fejl, og om det er Stripe, et ERP eller en PDF, kan ingen ærligt sige, hvad der skal bygges.

Derfor beder seriøse bureauer om discovery før build. Det er ikke et salgstrick, og det er ikke det samme som at "lære jer at kende". Det er at tvinge de dyre antagelser frem, mens de stadig er billige. En uge med de rigtige mennesker koster tid. En kvartals forsinkelse fordi checkout og roller aldrig blev talt igennem, koster et projekt.

Det her er også det, I skal kunne skelne, når I vælger partner. Et bureau der lover at starte mandag uden at have set jeres data, jeres brugere eller jeres "må ikke ske", sælger jer et gæt. Et bureau der vil bruge fem dage på at skære, og som kommer ud med noget I kan sige nej til, sælger jer et scope. De to tilbud kan se ens ud på en slide. De er det ikke.

Vi skriver det, fordi I ikke skal forveksle en workshop-facilitering med et produkt. Post-its på et whiteboard er et værktøj. Beslutningen om, at v1 ikke har native apps, at admin er ét skærmbillede, og at I lever med en ugentlig CSV indtil integrationen er værd at bygge — det er produktet af ugen.

Den klassiske kravspecifikation er skrevet for at være komplet. Det er dens første fejl. Komplet betyder, at alt er nævnt, så ingen kan bebrejde forfatteren, at noget manglede. Estimerbart betyder det omvendte: at det, der er inde, er konkret nok til at bygge, og at det, der er ude, er skrevet ned. En komplet liste er et katalog. Et scope er et snit.

Den anden fejl er, at den beskriver systemet, som om det allerede findes. "Brugeren kan eksportere til Excel." Hvilken bruger? Hvilke kolonner? Hvad sker der med 40.000 rækker? Må eksporten tage to minutter? Skal den køre om natten? Uden de svar er sætningen sand og ubrugelig på samme tid. En udvikler vil fylde hullerne. To udviklere vil fylde dem forskelligt.

Den tredje fejl er, at den blander ønsker, politik og edge-cases i samme kapitel. "Skal overholde GDPR" ved siden af "skal have mørkt tema" ved siden af "skal håndtere konkursbo." Det første er et constraint. Det andet er polish. Det tredje er et domæne, I måske slet ikke skal bygge i v1. Når alt står som shall-statements, kan I ikke skære. Så skærer virkeligheden for jer — midt i et sprint.

Vi ser også specs, der er skrevet af én person, som ikke skal bruge systemet, og godkendt af én person, som ikke skal bygge det. Det er et dokument, ikke en samtale. Discovery-ugen er den samtale, med et output I kan pege på næste mandag.

Vi måler ikke en discovery-uge på, om alle gik derfra inspirerede. Vi måler den på fire ting, I kan tage med ud af rummet. For det første: en ude-liste. Ting I har sagt nej til, med en sætning om hvorfor. Uden den listen kommer ønskerne tilbage i uge tre som "det var jo implicit." For det andet: de to-tre flows, et menneske skal kunne gennemføre i v1 — ikke som user stories i et værktøj, men som skærme og tilstande, I har tegnet sammen.

For det tredje: snitfladerne. Hvad kommer ind udefra (ERP, betaling, login, et regneark), hvad går ud, og hvad I midlertidigt gør i hånden. En CSV hver fredag er et ærligt v1-snit. En "fuld integration" I ikke har set data fra, er et håb. For det fjerde: de tre risici, I ikke må ignorere — data I ikke ejer, en beslutning der sidder hos en person der ikke var i rummet, en compliance-antagelse I ikke har tjekket.

Det er også det, I skal kræve at få leveret: ikke et 30-siders inception-deck, men noget et andet hold kan bygge efter. Wireframes eller HTML-skitser. En liste over åbne spørgsmål med ejer og dato. Et forslag til den første iteration — typisk 1–2 uger — med en demo I kan sige nej til. Hvis outputtet kun lever i facilitatorens hoved, har I købt en uge, ikke en afklaring.

På et Next.js-MVP betyder det ofte: hvilke roller, hvilket login, hvilke lister og detaljer, og om I overhovedet har brug for et public site i samme repo. På en kundeportal: hvem inviterer hvem, og hvad der sker når en kontrakt udløber. På et marketing-site: hvilke sider der er inde, og hvilke kampagner der venter. Formen er den samme. Indholdet er jeres.

I skal have den person, der kan sige nej til et marked, en integration eller en dato. Uden den person er ugen et interview. I skal have den person, der kender de rigtige brugere — ikke den, der kender et org-diagram. Og I skal have den, der kender dataene: hvor kunderne faktisk bor, hvad der er rod i Excel, hvad ERP'et ikke kan. Tre til fem mennesker. Ikke tolv.

I skal ikke have hele ledelsen som tilhørere. I skal ikke have den leverandør, der kun er med for at forsvare det eksisterende system, medmindre I eksplicit har bedt dem om at kortlægge snitflader. Og I skal ikke have et design-team, der først kommer når "scope er låst" — for så designer de et andet produkt end det, I skar.

Facilitatoren — os eller jer — skal kunne stoppe en samtale, der er blevet til feature-ønskeseddel, og trække den tilbage til flowet. Et bureau der kun kan styre en Miro-tavle, men ikke udfordre et shall-statement, er en mødeleder. Det er et andet job end discovery.

Hvis den rigtige beslutningstager kun kan give to timer, så læg de to timer onsdag og fredag. Ikke mandag. Mandag kan I forberede. Onsdag skal nogen skære. Fredag skal nogen godkende ude-listen. Alt andet er kalender-optimering, der slår ugen ihjel.