Langt de fleste build-forløb fejler ikke på koden. De fejler på scope, uklare beslutninger og ventetid mellem møder. Når vi lover 14 dage fra prototype til produktion, er det ikke fordi vi arbejder hurtigere — det er fordi vi arbejder anderledes.

De sidste par år har vi kørt en række korte build-forløb for klienter der havde brug for at komme fra et godkendt koncept til en fungerende version i markedet. Nogle var MVPs til investor-samtaler. Andre var interne værktøjer der skulle testes med rigtige brugere. Fælles for dem var at klokken tikkede — og at et klassisk 2-3 måneders projekt ikke var en mulighed.

Det her er ikke en metode vi har opfundet. Det er et sæt beslutninger vi har taget, fjernet, testet igen, og til sidst holdt fast i. Her er hvad der virker for os.

Det handler ikke om at skrive kode hurtigere

Den største fælde er at tro at 14 dage handler om produktivitet. Det gør det ikke. Det handler om beslutningshastighed.

På et normalt build-projekt bruger teamet måske 60% af tiden på at kode og 40% på at vente — på feedback, på afklaring, på at nogen godkender et design, på at en tredje part leverer. Når vi komprimerer forløbet til 14 dage, skal den 40% ned til under 10%. Ikke ved at fjerne beslutninger, men ved at tage dem hurtigere og i et andet format.

Fem principper vi ikke går på kompromis med

1. Én beslutningstager fra klienten

Ikke et udvalg. Ikke "jeg skal lige vende det med Mette". Én person der kan sige ja eller nej på stedet — og som er tilgængelig på Slack hver dag i de 14 dage. Hvis den person ikke findes, er forløbet ikke klar til at starte.

2. Scope er låst. Alt andet er fleksibelt.

Vi skriver scope ned i et dokument på højst én A4-side før dag ét. Det er ikke et krav-dokument — det er en liste over hvad der skal virke når vi går live. Hvis noget er uklart, spørger vi før vi skriver. Hvis noget ændrer sig undervejs, betyder det at noget andet ryger ud. Ingen undtagelser.

3. Daily check-in. 15 minutter. Samme tid hver dag.

Ikke et møde. Et check-in. Tre punkter: hvad er færdigt, hvad er i gang, hvad blokerer. Står nogen fast på en beslutning, løser vi den dér — eller aftaler at den er løst inden næste check-in.

4. Produktion fra dag ét

Vi bygger ikke en prototype og konverterer. Vi bygger i produktions-setup'et fra første commit. Det koster en halv dag ekstra i starten og sparer tre dage i slutningen.

5. Fredag er deploy-dag

Den anden fredag er go-live. Det lyder trivielt, men at have datoen i kalenderen — med tid, med invitation, med mails der er forberedt — ændrer hvordan hele teamet prioriterer i den anden uge.

De fleste build-projekter bliver ikke forsinkede af teknik. De bliver forsinkede af tvivl. — Noget vi har sagt ofte. Og ment hver gang.

Hvornår det ikke virker

14 dage er ikke svaret på alting. Det virker når:

Det virker ikke når kravene stadig er under diskussion, når flere interessenter skal blive enige undervejs, eller når projektet er afhængigt af eksterne aftaler der endnu ikke er i hus. I de tilfælde anbefaler vi et to-ugers afklaringsforløb først — og så selve build'en bagefter.

Hvad det betyder for os

At køre korte build-forløb kræver mere af os end af klienten. Vi skal sige nej når scope vokser. Vi skal tage beslutninger der normalt ville ligge hos klienten, når klienten ikke er tilgængelig. Vi skal være ærlige om hvad der ikke nåede, i stedet for at shippe noget vi ved ikke er godt nok.

Det er den slags arbejde hvor relationen betyder mere end kontrakten. Det fungerer kun med klienter der behandler os som en partner — ikke som en leverandør der skal leveres til tiden.

Take-aways

Vi kører typisk 6-8 af denne type forløb om året. Hvis du har et koncept der er klar til at blive bygget — og en ambition om at ramme markedet før sommer — så skriv til os. Det tager en 20-minutters samtale at afklare om det er det rigtige setup for jer.