8 kostbare feil i apputvikling som SMB-er gjør om og om igjen

Her er den ubehagelige sannheten om appprosjekter som går skeis: når koden først ser feil ut, var prosjektet allerede tapt for uker siden. De kostbare feilene i apputvikling for små bedrifter skjer nesten aldri ved tastaturet. De skjer i tilfeldige samtaler — briefen som aldri ble skrevet ned, funksjonen noen la til ‘når vi nå holder på’, utvikleren som ble valgt fordi en venn anbefalte dem. Ingenting av det føles som en beslutning der og da. Alt sammen koster deg senere.

Jeg har sett mange små bedrifter bestille sin første app, og jeg har blitt tilkalt for å redde rikelig av dem i etterkant. Eierne er sjelden slurvete mennesker. De er skarpe, nøye, dyktige til å drive forretning. Men programvare har sitt eget sett av feller som ikke finnes noe annet sted i arbeidslivet deres, og ingen advarte dem. Så de går rett inn i de samme åtte fallgruvene, i omtrent samme rekkefølge, hver gang.

Dette er listen jeg skulle ønske at hver eier hadde hatt før de brukte en eneste krone. Ikke teori — de faktiske, gjentakende feilene, og de små kursjusteringene som ville ha reddet hvert prosjekt. Hvis du er i ferd med å bygge en app, eller du allerede er midt i byggingen og noe føles galt, les dette først. De fleste av disse kan fortsatt rettes hvis du fanger dem tidlig.

Feil 1: Å bygge før du har bevist at noen vil ha det

Den enkeltstående kostbareste feilen er også den vanligste: å forplikte seg til en full bygging før det finnes noe reelt bevis for at appen løser et problem folk vil betale for eller bruke. Idéen føles innlysende for eieren — selvfølgelig vil kundene ha dette — og nettopp den sikkerheten er det som er farlig. Sikkerhet føles som validering. Det er det ikke.

Validering betyr ikke å spørre ti venner om de liker idéen; alle sier ja for å være greie. Det betyr å sette den minst mulige versjonen foran ekte brukere i en ekte situasjon og se hva de faktisk gjør. En klikkbar prototype, en landingsside som måler påmeldinger, en manuell ‘concierge’-versjon der du fingerer automatiseringen for hånd — hvilken som helst av disse forteller deg mer enn en ferdig app bygget på en magefølelse. Rekkefølgen betyr noe: bevis etterspørselen billig, bygg så dyrt. Snu det rundt, og du kan bruke hele budsjettet ditt på å pusse noe ingen åpner en gang til.

Feil 2: Omfangssniking forkledd som ambisjon

Hver app starter slank og ryddig. Så begynner ‘når vi nå holder på’. Når vi nå bygger bookingskjermen, kan den ikke også håndtere gavekort? Og lojalitetspoeng? Og et henvisningssystem? Hvert tillegg høres fornuftig ut for seg selv. Sammen tredobler de stille tidslinjen og regningen — og skyver lanseringen så langt ut at det opprinnelige driv dør.

Løsningen er ikke å si nei til gode idéer. Det er å parkere dem. Hold en synlig ‘versjon to’-liste der hver skinnende idé får vente på tur. Dette gjør noe psykologisk i tillegg til praktisk: folk slutter å kjempe for å presse funksjoner inn i den første utgivelsen når de stoler på at det finnes en reell plass for idéen deres senere. Din første versjon skal gjøre én ting genuint godt, ikke ti ting tålelig. En app som treffer blink på én enkelt arbeidsflyt blir brukt. En app som gjør alt halvveis blir forlatt.

Feil 3: Ingen skriftlig brief — bare et delt mentalt bilde

Denne er usynlig til den biter. Eieren har en klar app i hodet. Utvikleren har en klar app i hodet. Alle nikker på oppstartsmøtet. Ingen skriver det ordentlig ned — og de to bildene, viser det seg, var aldri det samme bildet. Du oppdager dette halvveis inn, når det som bygges ikke er det du forestilte deg, og nå er det en krangel om hvem som sa hva.

Du trenger ikke en spesifikasjon på hundre sider. Du trenger noen få sider som en hvilken som helst nykommer kunne lese og forstå: hvem bruker denne appen, hva er de tre eller fire tingene de trenger å gjøre med den, hvordan ser et vellykket resultat ut. Legg til en grov skisse av nøkkelskjermene. Det er alt. Poenget med briefen er ikke byråkrati — det er en felles referanse dere begge kan peke på når hukommelse og virkelighet begynner å gli fra hverandre, noe de alltid gjør.

Feil 4: Å velge utvikleren på feil måte

De fleste eiere velger sin første utvikler ut fra ett av to spinkle signaler: det laveste tilbudet, eller en personlig anbefaling fra noen i en helt annen bransje. Begge kan fungere ved flaks. Ingen av dem er en pålitelig måte å velge noen du skal betro en betydelig sum penger og flere måneder av bedriftens fremtid.

Det laveste tilbudet er spesielt forrædersk i programvare, fordi gapet mellom et tilbud og den ferdige kostnaden er enormt og usynlig. En billig utvikler som trenger tre runder med omarbeiding, forsvinner i to uker og etterlater deg med kode ingen andre kan vedlikeholde, er langt dyrere enn en litt dyrere som får det riktig. Pris er det du ser; total kostnad er det du betaler.

Hva du faktisk bør sjekke

Be om å få se ting de har levert som fortsatt kjører, og hvis du kan, snakk med de kundene uten utvikleren i rommet. Spør hvordan de håndterer endringer midt i prosjektet, for det kommer endringer. Spør hvem som eier koden og kontoene når det er ferdig — svaret bør alltid være du. Og legg merke til om de stiller gode spørsmål tilbake. En utvikler som bare tar imot ordre vil bygge nøyaktig feil ting svært effektivt. De gode protesterer, peker på hull i tenkningen din og behandler briefen som et utgangspunkt for en samtale, ikke en fast handleliste.

Feil 5: Å budsjettere for byggingen og glemme resten

En app er ikke et engangskjøp som en trykt brosjyre. Det er en levende ting som må mates. Eiere budsjetterer rutinemessig for byggingen og ingenting annet, og blir så tatt på sengen av kostnadene som kommer etterpå: hosting, app-store-avgifter, vedlikeholdet for å henge med på telefonenes OS-oppdateringer, og den uunngåelige runden med fikser og små forbedringer når ekte folk begynner å bruke den.

En fornuftig tommelfingerregel: hva enn byggingen koster, sett av en betydelig del av det igjen til det første driftsåret. Det nøyaktige tallet varierer, men feilen er universell — å behandle lanseringsdagen som målstreken når den faktisk er startstreken. Appen som lanseres og så stille forlates fordi det ikke finnes budsjett til å vedlikeholde den, er ett av de tristeste og vanligste utfallene i hele dette feltet, og det kan helt unngås med ærlig planlegging på forhånd.

Feil 6: Å designe for deg selv i stedet for brukeren din

Du kjenner bedriften din ut og inn, noe som gjør deg til den verst tenkelige dommeren av om appen din er lett å bruke. Ting som er innlysende for deg — sjargongen, rekkefølgen du gjør oppgaver i, snarveiene du tar uten å tenke — er forvirrende for en førstegangsbruker. En app som gir perfekt mening for eieren og forvirrer alle andre har feilet, uansett hvor smart den er.

Kuren er billig og litt ydmykende: se ekte folk bruke den før du lanserer. Ikke teamet ditt, som allerede vet hvordan den er ment å fungere — ekte kunder eller ansatte som aldri har sett den. Rekk dem appen, gi dem en oppgave, og si ingenting. Der de nøler, trykker på feil ting eller sukker, der er designtilbakemeldingen din. Fem personer er nok til å få frem de verste problemene. Å hoppe over dette steget er hvordan apper lanseres med en ‘send’-knapp ingen kan finne og en påmeldingsflyt som mister halvparten av dem som prøver.

• Gi testeren en ekte oppgave, ikke en omvisning — ‘bestill en time til neste tirsdag’, og hold deg så taus.
• Se på hendene og ansiktet deres, ikke bare om de til slutt lykkes.
• Noter hver nøling; en pause er et designproblem du ikke kan se innenfra.
• Motstå trangen til å forklare — hvis du må forklare det, burde appen ha gjort det.
• Test med fem personer, fiks de åpenbare feilene, og test så igjen.

Feil 7: Å bygge nativ iOS og Android når du ikke trengte det

Det finnes en refleks om å bygge en ‘skikkelig’ app for både iPhone og Android fra dag én, fullt nativ, slik de store merkene gjør. For de fleste små bedrifter er det to til tre ganger kostnaden og kompleksiteten for en fordel brukerne dine aldri vil merke. Verre, du vedlikeholder nå to separate kodebaser for alltid og dobler hver fremtidig fiks.

Ofte er det riktige første trekket ikke en nativ app i det hele tatt. En velbygd webapp som fungerer i hvilken som helst telefons nettleser, eller en tverrplattform-tilnærming som produserer begge app-store-versjonene fra én kodebase, får deg raskere og billigere til markedet — og du kan alltid gå fullt nativ senere hvis reell bruk beviser at det er verdt det. Spørsmålet du bør stille er aldri ‘nativ eller web’ i det abstrakte. Det er: hva er den minste, billigste tingen som lar ekte brukere gjøre kjerneoppgaven? Bygg det, lær av det, og bruk så de store pengene med bevis i stedet for antakelse.

Feil 8: Å behandle lanseringen som slutten på arbeidet

Den åttende feilen er å tro at prosjektet er ferdig når appen går live. Det er det ikke — det er da det virkelige prosjektet begynner. En app uten plan for hvordan den skal nå brukernes hender, uten måte å høre hva de mener, og uten intensjon om å forbedre den ut fra det du lærer, er en app som visner bort innen måneder. Byggingen var den lette delen. Utbredelsen er den vanskelige delen, og nesten ingen planlegger for den.

Før du lanserer, kjenn til tre ting: hvordan folk skal få vite at appen finnes, hvordan du måler om de faktisk bruker den, og hvordan du samler inn det de forteller deg, slik at den neste arbeidsrunden styres av virkelighet i stedet for gjetninger. Ingenting av dette er dyrt. Det er bare en annen tankegang — appen er ikke en ting du gjør ferdig og går fra, det er et forhold du vedlikeholder. Eierne som forstår det får apper som blir mer nyttige over tid. De som ikke gjør det får en topp på lanseringsdagen og en lang, stille nedgang.

Hvordan holde deg unna alle åtte på én gang

Lest sammen deler disse feilene én eneste rot: å bevege seg raskt på antakelser i stedet for sakte på bevis. Hver eneste av dem er et sted der det føltes billigere å hoppe over det grundige steget. Og hver eneste av dem er langt billigere å håndtere før byggingen enn etter. Her er sekvensen som stille unngår alle åtte.

1. 1
   Bevis etterspørselen før du bygger

   En prototype, en landingsside eller en manuell versjon. Få reelt bevis for at noen vil ha dette før du binder budsjettet.
2. 2
   Skriv briefen og versjon to-listen

   Noen få klare sider alle kan forstå, pluss en parkeringsplass for hver ‘når vi nå holder på’-idé så den ikke avsporer v1.
3. 3
   Velg utvikleren på resultater, ikke pris

   Levert arbeid, referansesamtaler, klart eierskap til kode og kontoer, og en som stiller gode spørsmål tilbake.
4. 4
   Budsjetter for hele det første året, ikke bare byggingen

   Hosting, vedlikehold, fikser og support. Lanseringsdagen er startstreken, så finansier driften av tingen.
5. 5
   Velg den minste plattformen som gjør jobben

   Web eller tverrplattform først i de fleste tilfeller. Gå fullt nativ senere, med bevis, bare hvis bruken krever det.
6. 6
   Test med ekte brukere, planlegg så lanseringen

   Se fem fremmede bruke den, fiks de åpenbare feilene, og bestem på forhånd hvordan folk skal finne den og hvordan du måler bruk.

Vanlige spørsmål