Hvordan styrer man som iværksætter et it-projekt der vokser?

Et it-projekt der vokser skal efter min erfaring forbedres i små skridt. Begynd med det mest basale, få brugerne ind, og lær af dem. Hold samtidig igen med nye funktioner, for hver knap kan gøre både produktet og vedligeholdelsen mere besværlig.

Videoen er fra maj 2013. Jeg taler fra en lille virksomheds perspektiv og bruger Agera, Amino og Dinero som eksempler. Det er mine erfaringer og prioriteringer fra den tid.

Et system på nettet bliver aldrig færdigt

En webshop, en portal eller en større it-løsning er ikke som en bog, du kan få trykt og erklære færdig. Arbejdet fortsætter.

Der kommer nye teknologier og nye ting, systemet skal spille sammen med. Derfor mener jeg ikke, at du skal lede efter et endegyldigt slutpunkt. Målet flytter sig.

Spørgsmålet er, hvordan du løser opgaven bedst i den fase, virksomheden befinder sig i.

Agera skulle hurtigt ud og tjene penge

Agera skaffer tilbud på blandt andet revisorer, advokater og bogholdere. Da vi startede, vidste vi ikke, om idéen ville holde, og vi havde begrænsede ressourcer.

Vi skulle ikke bygge et stort, solidt system med alt tænkeligt fra begyndelsen. Vi skulle finde det mindste, vi kunne gå i luften med, som stadig løste de grundlæggende behov og gjorde det muligt at tjene penge.

Version 1.0 blev lavet på under en måned. Folk kunne bede om tre tilbud, og vi havde en administrationsdel, hvor vi kunne lægge samarbejdspartnere ind. De kunne få en mail, logge ind og give et tilbud.

Et system lavet af én mand på en måned tager dig ikke til månen. Men det gjorde, at vi kunne komme i gang med at sælge.

Du kender ikke alle spørgsmålene på forhånd

Før folk bruger systemet, ved du ikke engang, hvilke spørgsmål du skal stille. Det er først i brugen, du opdager, at en knap er overflødig, eller at en funktion er forkert.

Jeg kritiserer i videoen store offentlige projekter, hvor man prøver at beskrive alle behov og bygge alt på én gang. Min oplevelse er, at det skaber forsinkelser, komplekse systemer og svær oplæring, og at teknologien kan være forældet, når systemet kommer ud.

Mit råd til en iværksætter er at begynde enkelt. Få webshoppen til at sælge varer eller portalen til at fungere. Se, hvad brugerne faktisk har brug for, og byg videre derfra.

Et it-projekt der vokser har brug for fravalg

Når feedbacken kommer, bliver det svært. En programmør kan tilføje masser af knapper. Det er ikke det samme som, at produktet bliver bedre.

På Dinero får vi eksempelvis ønsker om at kunne skifte mellem flere logoer og mange andre ting. Hver ny mulighed øger kompleksiteten for dem, som skal bruge programmet.

Det, som få gerne vil have, kan gøre oplevelsen dårligere for resten. Derfor skal du have modet til at sige nej til både brugere og sælgere, hvis en funktion ikke giver rigtig god mening.

Jeg prøver først at spørge: Hvad kan vi fjerne for at løse problemet? Det er et andet spørgsmål end, hvad vi kan tilføje.

Flere funktioner giver også flere steder, hvor noget kan gå galt. De griber ind i hinanden og gør ændringer vanskeligere. Det er en reel pris.

Den første version får kapacitetsproblemer

Når kunder og brugere begynder at komme ind, kan den hurtige første version blive langsom eller ustabil.

Du byggede måske ikke fra starten til flere servere eller stor belastning. Du tog genveje, fordi du skulle i gang. Det er en del af den prioritering, jeg argumenterer for.

Nu skal der måske arbejdes med databasen, cache eller andre tekniske forhold. Jeg er ikke programmør, så jeg taler om det, jeg hører fra dem, jeg arbejder med.

Den fejl, jeg ser igen og igen, er at lade en ny programmør erklære, at alt skal skrives om fra bunden. Det er ikke min foretrukne løsning.

Vis brugerne en forbedring hver uge

Jeg foretrækker små iterationer: Arbejd fremad lidt ad gangen. Min regel er, at der ikke må gå en uge, uden at brugerne kan se en forandring.

Hvis udvikleren forsvinder ned i kælderen i fire måneder, mister vedkommende feedback og måske gejsten. Brugerne får bagefter et stort chok, og du har ændret så meget på én gang, at det er svært at finde fejlene.

Har du ændret 150 ting, hvilken af dem skabte så problemet? I min erfaring kan man ende med at rette det, der virkede, og få endnu flere fejl.

Jeg vil hellere arbejde med det system, vi har, og udskifte dele gradvist. Hvis databasen skal ændres, så begynd at tilpasse komponenterne til det. Tag først de store, oplagte problemer, og arbejd derfra mod en bedre arkitektur.

Så kan brugerne løbende mærke, at det bliver hurtigere og bedre.

En dyr rettelse kan være billigere end en total omskrivning

På Amino har vi indimellem haft problemer med hastigheden. Sidst måtte jeg hente en ekspert ind. Jeg husker regningen som omkring 50.000 kroner plus moms.

Han sagde, at problemerne kunne komme igen om otte måneder. Mit svar var, at så måtte vi måske betale for at rette dem igen.

Alternativet kunne være at binde fire-fem udviklere i seks-otte måneder til en helt ny arkitektur. Imens ville brugerne ikke se nye tjenester eller forbedringer, og udviklerne ville mangle den løbende respons.

Jeg sammenligner det med varmt vand i hanen. Når det virker, tænker du ikke over det. Du glæder dig ikke hver morgen over, at nogen har arbejdet i otte måneder på, at vandet ikke bliver koldt.

For mig kan det være billigere at bruge 50.000-100.000 kroner om året på mindre løsninger end at bruge måske en halv million på at løse noget én gang for alle.

Det er mit regnestykke i den situation. En stor omskrivning kan også trække ud, introducere fejl og koste kunder, fordi de ikke ser fremskridt. Når du endelig er færdig, kan der ovenikøbet være kommet en ny teknologi.

En lille skraldespand er også kompleksitet

På Dinero kan vi bruge en time på at diskutere en lille detalje: Hvor skal brugeren finde slettede ting?

I videoen skelner jeg mellem kontakter og fakturaer og fortæller om hensynene til at kunne finde noget igen. Det er den daværende produktdiskussion, jeg bruger som eksempel.

En skraldespand i hjørnet er let at tegne. Men skal alle se den på hver side, hvis næsten ingen har brug for den?

Jeg bruger et tænkt forhold på 99 procent mod én procent: Jeg vil hellere lade den lille gruppe lede lidt længere end gøre skærmen mere besværlig for alle de andre.

Én mailserie kan være bedre end to

På Amino drøfter vi også et velkomstforløb for nye brugere af Freelancer. Et forslag er en serie til Plus-medlemmer og en anden til dem, der ikke er medlemmer.

Jeg foreslår én serie med almindelige råd og et Plus-tip. Medlemmet kan bruge tippet. Den, der ikke er medlem, kan se fordelen og få mulighed for at læse mere.

Begge grupper kan godt leve med lidt tekst, som ikke kun er skrevet til dem. Til gengæld har vi ét forløb at holde styr på.

To forløb giver flere fejlmuligheder. Måske stopper den ene serie efter en ændring, og jeg opdager det ikke, fordi jeg selv modtager den anden.

Hold gevinsten op mod hele prisen

En stor virksomhed med et helt hold til mails og udvikling kan vælge anderledes. Vores projektleder kommer fra en virksomhed, der havde flere mennesker alene til den slags. Men jeg har ikke ressourcer til at ansætte folk bare for at holde komplicerede mailforløb i gang.

Når du som mig er nødt til at holde øje med hver krone, skal du veje gevinsten ved kompleksitet mod vedligeholdelse, fejl, fejlsøgning og overvågning.

Du skal også tænke på brugeren. Mere kompleksitet kan give mere support og lavere salg, fordi produktet bliver sværere at forstå.

Jeg har ikke altid været god til at holde tingene enkle, men jeg er blevet mere opmærksom på det. Jeg spørger mig selv, hvad Steve Jobs ville have gjort. Jeg er kritisk over for ham som menneske, men hans arbejde med produkter og ledelse inspirerer mig.

Kom hurtigt i gang, lær af brugerne, vælg fra og forbedr i små skridt. Det er den tilgang, mine erfaringer peger på.

Flere af mine erfaringer med at udvikle produkter og bygge virksomheder finder du i Iværksætter til jeg dør.