8 dyre fejl i appudvikling, som SMV'er bliver ved med at begå

Her er den ubehagelige sandhed om appprojekter, der går skævt: når koden først ser forkert ud, var projektet allerede tabt for uger siden. De dyre fejl i appudvikling for små virksomheder sker næsten aldrig ved tastaturet. De sker i tilfældige samtaler — briefen, der aldrig blev skrevet ned, funktionen nogen tilføjede ‘når vi nu er i gang’, udvikleren der blev valgt, fordi en ven anbefalede dem. Intet af det føles som en beslutning i øjeblikket. Det hele koster dig senere.

Jeg har set mange små virksomheder bestille deres første app, og jeg er blevet hidkaldt for at redde rigeligt af dem bagefter. Ejerne er sjældent skødesløse mennesker. De er skarpe, omhyggelige, dygtige til at drive forretning. Men software har sit eget sæt af fælder, der ikke findes nogen andre steder i deres arbejdsliv, og ingen advarede dem. Så de går lige ind i de samme otte faldgruber, i nogenlunde samme rækkefølge, hver gang.

Det her er listen, jeg ville ønske, enhver ejer havde haft, før de brugte en eneste øre. Ikke teori — de faktiske, gentagne fejl, og de små kursjusteringer, der ville have reddet hvert projekt. Hvis du er ved at bygge en app, eller du allerede er midt i byggeriet, og noget føles forkert, så læs det her først. De fleste af disse kan stadig rettes, hvis du fanger dem tidligt.

Fejl 1: At bygge, før du har bevist, at nogen vil have det

Den enkeltstående dyreste fejl er også den mest almindelige: at forpligte sig til et fuldt byggeri, før der er noget reelt bevis for, at appen løser et problem, folk vil betale for eller bruge. Idéen føles indlysende for ejeren — selvfølgelig vil kunderne have det her — og netop den vished er, hvad der er farligt. Vished føles som validering. Det er det ikke.

Validering betyder ikke at spørge ti venner, om de kan lide idéen; alle siger ja for at være søde. Det betyder at sætte den mindst mulige version foran rigtige brugere i en rigtig situation og se, hvad de rent faktisk gør. En klikbar prototype, en landingsside der måler tilmeldinger, en manuel ‘concierge’-version hvor du fingerer automatiseringen i hånden — enhver af disse fortæller dig mere end en færdig app bygget på en fornemmelse. Rækkefølgen betyder noget: bevis efterspørgslen billigt, byg så dyrt. Vend det om, og du kan bruge hele dit budget på at pudse noget, ingen åbner en anden gang.

Fejl 2: Omfangsskred forklædt som ambition

Enhver app starter slank og pæn. Så begynder ‘når vi nu er i gang’. Når vi nu bygger bookingskærmen, kunne den så ikke også håndtere gavekort? Og loyalitetspoint? Og et henvisningssystem? Hver tilføjelse lyder fornuftig for sig selv. Tilsammen tredobler de stille tidsplanen og regningen — og skubber lanceringen så langt ud, at den oprindelige fremdrift dør.

Løsningen er ikke at sige nej til gode idéer. Det er at parkere dem. Hold en synlig ‘version to’-liste, hvor enhver skinnende idé kommer hen og venter på sin tur. Det her gør noget psykologisk såvel som praktisk: folk holder op med at kæmpe for at presse funktioner ind i den første udgivelse, når de stoler på, at der er en rigtig plads til deres idé senere. Din første version skal gøre én ting genuint godt, ikke ti ting nogenlunde. En app, der rammer plet på ét enkelt arbejdsflow, bliver brugt. En app, der gør alt halvt, bliver opgivet.

Fejl 3: Ingen skriftlig brief — bare et delt mentalt billede

Den her er usynlig, indtil den bider. Ejeren har en klar app i hovedet. Udvikleren har en klar app i hovedet. Alle nikker til opstartsmødet. Ingen skriver det ordentligt ned — og de to billeder, viser det sig, var aldrig det samme billede. Du opdager det halvvejs inde, når det der bliver bygget, ikke er det du forestillede dig, og nu er der en strid om, hvem der sagde hvad.

Du har ikke brug for en hundrede sider lang specifikation. Du har brug for nogle få sider, som enhver nytilkommen kunne læse og forstå: hvem bruger denne app, hvad er de tre eller fire ting, de skal kunne med den, hvordan ser et vellykket resultat ud. Tilføj en grov skitse af nøgleskærmene. Det er det. Pointen med briefen er ikke bureaukrati — det er en fælles reference, I begge kan pege på, når hukommelse og virkelighed begynder at glide fra hinanden, hvilket de altid gør.

Fejl 4: At vælge udvikleren på den forkerte måde

De fleste ejere vælger deres første udvikler ud fra et af to spinkle signaler: det laveste tilbud, eller en personlig anbefaling fra nogen i en helt anden branche. Begge kan virke ved held. Ingen af dem er en pålidelig måde at vælge nogen, du skal betro en betydelig sum penge og flere måneder af din virksomheds fremtid.

Det laveste tilbud er særligt forræderisk i software, fordi kløften mellem et tilbud og den færdige omkostning er enorm og usynlig. En billig udvikler, der har brug for tre runder omarbejdning, forsvinder i to uger og efterlader dig med kode, ingen anden kan vedligeholde, er langt dyrere end en lidt dyrere, der får det rigtigt. Pris er, hvad du ser; den samlede omkostning er, hvad du betaler.

Hvad du faktisk skal tjekke

Bed om at se ting, de har leveret, som stadig kører, og hvis du kan, så tal med de kunder uden udvikleren i rummet. Spørg, hvordan de håndterer ændringer midt i projektet, for der vil komme ændringer. Spørg, hvem der ejer koden og kontiene, når det er færdigt — svaret bør altid være dig. Og vær opmærksom på, om de stiller gode spørgsmål tilbage. En udvikler, der kun tager imod ordrer, vil bygge præcis den forkerte ting meget effektivt. De gode gør indsigelser, peger på huller i din tænkning og behandler briefen som et udgangspunkt for en samtale, ikke en fast indkøbsliste.

Fejl 5: At budgettere for byggeriet og glemme resten

En app er ikke et engangskøb som en trykt brochure. Det er en levende ting, der skal fodres. Ejere budgetterer rutinemæssigt for byggeriet og intet andet, og bliver så taget på sengen af de omkostninger, der kommer bagefter: hosting, app-store-gebyrer, vedligeholdelsen for at følge med telefonernes OS-opdateringer, og den uundgåelige runde af rettelser og små forbedringer, når rigtige mennesker begynder at bruge den.

En fornuftig tommelfingerregel: hvad end byggeriet koster, så afsæt en betydelig del af det igen til det første driftsår. Det nøjagtige tal varierer, men fejlen er universel — at behandle lanceringsdagen som målstregen, når den faktisk er startstregen. Appen, der lanceres og så stille opgives, fordi der ikke er noget budget til at vedligeholde den, er et af de mest triste og mest almindelige udfald i hele dette felt, og det kan helt undgås med ærlig planlægning på forhånd.

Fejl 6: At designe til dig selv i stedet for din bruger

Du kender din forretning ud og ind, hvilket gør dig til den værst tænkelige dommer af, om din app er let at bruge. Ting der er indlysende for dig — jargonen, rækkefølgen du udfører opgaver i, genvejene du tager uden at tænke — er forvirrende for en førstegangsbruger. En app der giver perfekt mening for ejeren og forvirrer alle andre har fejlet, uanset hvor smart den er.

Kuren er billig og en smule ydmygende: se rigtige mennesker bruge den, før du lancerer. Ikke dit team, der allerede ved, hvordan den er ment at virke — rigtige kunder eller medarbejdere, der aldrig har set den. Ræk dem appen, giv dem en opgave, og sig ingenting. Hvor de tøver, trykker på det forkerte eller sukker, der er din designfeedback. Fem personer er nok til at få de værste problemer frem. At springe dette trin over er, hvordan apps lanceres med en ‘send’-knap, ingen kan finde, og et tilmeldingsflow, der mister halvdelen af dem, der prøver.

• Giv testeren en rigtig opgave, ikke en rundvisning — ‘book en tid til næste tirsdag’, og forhold dig så tavs.
• Se på deres hænder og deres ansigt, ikke bare om de til sidst lykkes.
• Notér hver tøven; en pause er et designproblem, du ikke kan se indefra.
• Modstå trangen til at forklare — hvis du skal forklare det, burde appen have gjort det.
• Test med fem personer, ret de åbenlyse fejl, og test så igen.

Fejl 7: At bygge nativt iOS og Android, når du ikke behøvede

Der er en refleks om at bygge en ‘rigtig’ app til både iPhone og Android fra dag ét, fuldt nativ, på den måde de store brands gør. For de fleste små virksomheder er det to til tre gange omkostningen og kompleksiteten for en fordel, dine brugere aldrig vil bemærke. Værre endnu vedligeholder du nu to separate kodebaser for evigt og fordobler enhver fremtidig rettelse.

Ofte er det rigtige første træk slet ikke en nativ app. En velbygget webapp, der virker i enhver telefons browser, eller en cross-platform-tilgang, der producerer begge app-store-versioner fra én kodebase, får dig hurtigere og billigere på markedet — og du kan altid gå fuldt nativ senere, hvis reel brug beviser, at det er det værd. Spørgsmålet du skal stille er aldrig ‘nativ eller web’ i det abstrakte. Det er: hvad er den mindste, billigste ting, der lader rigtige brugere udføre kerneopgaven? Byg det, lær af det, og brug så de store penge med bevis i stedet for antagelse.

Fejl 8: At behandle lanceringen som arbejdets afslutning

Den ottende fejl er at tro, at projektet er færdigt, når appen går i luften. Det er det ikke — det er, når det rigtige projekt begynder. En app uden plan for, hvordan den når brugernes hænder, uden måde at høre, hvad de synes, og uden hensigt om at forbedre den ud fra, hvad du lærer, er en app, der falmer inden for måneder. Byggeriet var den lette del. Udbredelsen er den svære del, og næsten ingen planlægger for den.

Før du lancerer, så kend tre ting: hvordan folk skal finde ud af, at appen eksisterer, hvordan du måler, om de rent faktisk bruger den, og hvordan du indsamler det, de fortæller dig, så den næste arbejdsrunde styres af virkelighed i stedet for gætterier. Intet af dette er dyrt. Det er bare en anden tankegang — appen er ikke en ting, du gør færdig og går væk fra, det er et forhold, du vedligeholder. Ejerne der forstår det, får apps der bliver mere nyttige over tid. De der ikke gør, får en spids på lanceringsdagen og en lang, stille nedtur.

Sådan holder du dig fri af alle otte på én gang

Læst sammen deler disse fejl én enkelt rod: at bevæge sig hurtigt på antagelser i stedet for langsomt på bevis. Hver eneste af dem er et sted, hvor det føltes billigere at springe det omhyggelige trin over. Og hver eneste af dem er langt billigere at håndtere før byggeriet end efter. Her er rækkefølgen, der stille undgår alle otte.

1. 1
   Bevis efterspørgslen, før du bygger

   En prototype, en landingsside eller en manuel version. Få reelt bevis for, at nogen vil have det her, før du binder budgettet.
2. 2
   Skriv briefen og version to-listen

   Nogle få klare sider, alle kan forstå, plus en parkeringsplads til enhver ‘når vi nu er i gang’-idé, så den ikke afsporer v1.
3. 3
   Vælg udvikleren på resultater, ikke pris

   Leveret arbejde, referenceopkald, klart ejerskab af kode og konti, og en der stiller gode spørgsmål tilbage.
4. 4
   Budgettér for hele det første år, ikke kun byggeriet

   Hosting, vedligeholdelse, rettelser og support. Lanceringsdagen er startstregen, så finansier driften af tingen.
5. 5
   Vælg den mindste platform der løser opgaven

   Web eller cross-platform først i de fleste tilfælde. Gå fuldt nativ senere, med bevis, kun hvis brugen kræver det.
6. 6
   Test med rigtige brugere, planlæg så lanceringen

   Se fem fremmede bruge den, ret de åbenlyse fejl, og beslut på forhånd hvordan folk finder den, og hvordan du måler brug.

Almindelige spørgsmål