Den virkelige tidslinjen for apputvikling: fra idé til lansering

Hvis du spør ti byråer hvor lang tid det tar å lage en app, får du ti selvsikre svar, og ikke ett eneste av dem stemmer. Det ærlige svaret er at ingen kan si det presist på dag én — men alle som faktisk har levert programvare kan beskrive formen på det: hvilke faser som finnes, hvilke som i det stille spiser opp kalenderen, og hvor dine egne beslutninger setter fart på ting eller kjører dem i grøfta. Dette er nettopp den formen, skrevet rett ut.

Jeg har sett mange små bedriftseiere gå inn i et appprosjekt med forventning om en ryddig, rett marsj fra skisse til App Store. Det de i stedet får, føles som en rekke platåer og plutselige byks. Uker der det ser ut som om ingenting skjer, og så en dag der alt plutselig faller på plass. Ingenting av det er et tegn på at noe er galt. Det er bare slik programvare blir til — og når du kan sette navn på fasene, slutter hele prosessen å føles som en svart boks du betaler inn i og håper på det beste.

Så la oss sette realistiske forventninger. For en fokusert første versjon av en bedriftsapp — ikke en utflytende plattform, men en første versjon som gjør én ting godt — snakker man som regel om noe i spennet tre til fem måneder fra en seriøs start til en reell lansering. Hvor du lander i det spennet, har mindre med teknologien å gjøre enn med hvor tydelig du er, hvor raskt du tar beslutninger, og hvor mye du prøver å presse inn før lansering. La oss gå gjennom det.

Hvorfor estimatet du fikk sannsynligvis er feil

Seks-ukers-tallet er ikke akkurat en løgn — det er tiden det tar å bygge den delen alle kan se for seg. Skjermene. Knappene. Det du kan vise frem. Det tallet i det stille ser bort fra, er alt rundt den synlige appen: beslutningene, dataene, integrasjonene med verktøy du allerede bruker, testingen, gjennomgangen i appbutikken og den uunngåelige runden med «egentlig, kan den også gjøre dette?»

En nyttig måte å tenke på det: kodingen er sjelden flaskehalsen. Flaskehalsen er klarhet. Hver time utvikleren din venter på en beslutning — hvilken betalingsleverandør, hva som skjer når en booking avbestilles, hvem som ser hva — er en time tidslinjen sklir. Prosjektene som blir raskt ferdige, er ikke de med de beste ingeniørene. Det er de der eieren svarer på spørsmål på en dag i stedet for på fjorten dager.

Så når du leser fasene under, hold utkikk etter øyeblikkene der ballen ligger på din banehalvdel. Det er punktene der et prosjekt enten holder på momentet sitt eller i det stille stopper opp i tre uker fordi en e-post ble ubesvart. Tidslinjen er et delt ansvar, og kundedelen av den er den delen folk undervurderer.

Fase 1: Kartlegging og avgrensning (1–3 uker)

Før noen designer en eneste skjerm, finnes det en fase som ikke ser ut som fremgang, men avgjør alt: å finne ut hva du faktisk bygger, og enda viktigere, hva du ikke bygger. Det er her en vag idé («en app for kundene mine») blir til en konkret, fullførbar liste over funksjoner for versjon én.

Gjort godt er kartleggingen mest samtale og vanskelige spørsmål. Hvem bruker dette, og på hvilken enhet? Hva er den ene tingen den må gjøre strålende? Hva kan vente til versjon to? En god partner presser tilbake her, og det vil du gjerne — hver funksjon du kutter nå, er uker du får igjen. Resultatet er som regel en kort skriftlig avgrensning og en grov wireframe, noe du kan holde i hånden og si ja, det er den.

Fase 2: Design og prototype (2–4 uker)

Nå blir appen til noe du kan se og klikke på, før en linje med ekte kode binder deg til noe. Designere gjør om wireframen til skikkelige skjermer — fargene, flyten, den faktiske følelsen av å bruke den — som regel som en interaktiv prototype du kan trykke deg gjennom på din egen telefon.

Denne fasen er gull av én grunn: å endre et design er billig, å endre ferdig programvare er dyrt. Å flytte en knapp i en prototype tar fem minutter. Å flytte den etter at funksjonen er kodet, testet og koblet til dataene dine, kan ta en dag. Så det er nå du skal være kresen, vise den til noen ekte kunder eller ansatte, og fange «å, det kommer ingen til å forstå»-problemene mens de fortsatt er smertefrie å rette.

Den vanligste måten denne fasen trekker ut på, er ikke designeren — det er ubesluttsomhet på din side. Endeløse runder med små justeringer, eller tre personer med vetorett som aldri er enige. Bestem tidlig hvem som godkjenner, gi tilbakemelding samlet i stedet for i drypp, så holdes fasen stram.

Fase 3: Bygging (6–12 uker)

Dette er delen alle ser for seg når de tenker «å lage en app», og det er den lengste enkeltstrekningen — men sjelden den mest uforutsigbare, hvis de to første fasene ble gjort skikkelig. Utviklere bygger appen i biter, som regel i korte sykluser der du ser fungerende deler hver uke eller to i stedet for at de forsvinner i tre måneder og dukker opp med et ferdig produkt.

Den rytmen betyr noe. Du vil reagere på ekte, kjørende programvare tidlig, ikke på en statusrapport. Når du faktisk kan bruke booking-flyten i uke fire, vil du legge merke til ting ingen spesifikasjon kunne ha fanget — og å rette dem i uke fire er langt billigere enn i uke ti. En god byggeprosess gjør appen synlig for deg løpende, ikke bare til slutt.

Hva som i det stille trekker ut byggingen

To ting utvider en bygging mer enn noe annet. Det første er integrasjoner — hvert eksterne system appen må snakke med (betalingsleverandøren din, det eksisterende bookingverktøyet ditt, regnskapsprogramvaren din, en leveringstjeneste) legger til arbeid, og hver av dem kan kaste sine egne overraskelser. Det andre er scope creep: det jevne dryppet av små tillegg som hvert føles bitte lite, men som til sammen skyver lanseringen en måned ut. Begge er håndterbare, men bare hvis du ser dem komme.

• Hver ekstern integrasjon legger til dager, noen ganger uker — budsjettér for dem eksplisitt, ikke anta at de er gratis.
• «Bare én liten funksjon til» er den enkeltstående vanligste årsaken til en bommet lanseringsdato.
• Ekte data er rotete sammenlignet med testdata; planlegg tid til særtilfellene regnearket ditt i det stille tolererte.
• Brukerkontoer, betalinger og varslinger er bedragersk dype — de koster alltid mer enn de ser ut til.
• Godkjenninger og innhold du skylder teamet (logoer, tekster, juridisk tekst) kan stoppe en bygging like sikkert som en feil.

Fase 4: Testing og feilretting (2–4 uker)

Her er en fase folk glemmer eksisterer, og så ergrer seg over når den dukker opp. Når appen først er bygget, må den settes på prøve — på forskjellige telefoner, med dårlig internett, av folk som ikke bygde den og som gjør ting ingen forutså. Testing er ingen formalitet. Det er forskjellen mellom en app kundene dine stoler på og en de avinstallerer etter den første kræsjen.

Forvent at en liste med feil og ujevnheter dukker opp her. Det er ikke et tegn på at byggingen gikk dårlig; det er hele poenget med fasen. Noen er raske rettelser, noen avslører en beslutning som må vurderes på nytt. Teamene som håndterer dette godt, behandler det som en normal, planlagt del av arbeidet — ikke en nødssituasjon, og ikke noe å hoppe over fordi lanseringen nærmer seg. Å hoppe over testing sparer ikke tid. Det flytter bare feilene fra testtelefonen din til kundenes telefoner, der de koster ti ganger så mye å rette.

Fase 5: Lansering og ventetiden i appbutikken (1–2 uker, pluss gjennomgang)

Lansering er mindre ett enkelt øyeblikk og mer en omhyggelig utrulling. Er det en webapp, styrer du timingen helt — du skrur på når du er klar. Skal den inn i Apples App Store eller Google Play, overlater du en del av planen til dem: gjennomgangsprosessen deres kan ta fra en dag til over en uke, og av og til sender de den tilbake med noe å rette. Det er verdt å vite på forhånd, så det ikke overrasker en lanseringsdato du har lovet kunder.

Den smarte måten å lansere på er ikke en stor avsløring til hele kundebasen din. Det er en stille utgivelse til en liten gruppe først — en håndfull velvillige kunder eller dine egne ansatte — så du fanger virkelighetens problemer før alle ser dem. Deretter åpner du døren på vidt gap. En lansering som føles kjedelig begivenhetsløs, er en lansering som gikk bra.

1. 1
   Soft-lanser til en liten gruppe

   Slipp først til en håndfull velvillige brukere eller ansatte. Ekte bruk finner det testingen overså, med innsatsen skrudd helt ned.
2. 2
   Send inn tidlig hvis du skal til appbutikkene

   Apple og Google styrer gjennomgangsklokken, ikke du. Send inn med en buffer, så en treg gjennomgang eller en avvisning ikke sprenger den lovede datoen din.
3. 3
   Følg nøye med den første uken

   Ha noen for hånden som reagerer raskt. Den første uken bringer frem virkelighetens særtilfeller som ingen testmiljø noen gang gjør.
4. 4
   Planlegg dagen-etter-arbeidet før du lanserer

   En app er aldri 'ferdig' ved lansering. Avtal på forhånd hvem som tar de uunngåelige små rettelsene og den første tilbakemeldingsrunden.

Å sette sammen hele tidslinjen

Stablet ende mot ende gir de fasene deg et realistisk bilde. Ingen av dem er eksotiske; det som setter krokfot for folk, er å glemme at de uglamorøse — kartlegging, testing, ventetiden i appbutikken — er reell tid i kalenderen, ikke avrundingsfeil. Her er omtrent hvordan en fokusert første versjon pleier å fordele seg over månedene.

Legg det sammen, og du ser hvorfor tre til fem måneder er det ærlige spennet for en ekte første versjon, og hvorfor de som lover seks uker i det stille omdefinerer hva «en app» betyr. Det er ikke pessimisme — det er forskjellen mellom en dato du faktisk holder og en du bruker prosjektet på å unnskylde.

Hvordan du virkelig setter fart på det (og hvordan du ikke gjør det)

Du kan gå raskere, men de virkelige spakene er ikke de folk griper etter. Å kaste flere utviklere på et halvdefinert prosjekt gjør det som regel tregere, ikke raskere. De ærlige akseleratorene er uglamorøse: bestem hva du skal la være, svar raskt på spørsmål og motstå trangen til å legge til ting midt i byggingen.

Den enkeltstående største er nådeløs avgrensning. Jo mindre og tydeligere den første versjonen din er, desto før lanseres den — og en lansert app som tjener til livets opphold, lærer deg mer på to uker enn ytterligere to måneders planlegging noen gang gjør. Du kan alltid legge til. Du kan ikke få tilbake månedene som gikk med på å bygge funksjoner som det viste seg ingen ville ha.

Det finnes en beslektet sannhet verdt å si høyt: ikke alt trenger å være en skreddersydd app i det hele tatt. Noen ganger er det virkelige problemet en strekning manuelt arbeid som et stykke automatisering i det stille kunne håndtert, uten noen app. En god partner sier ifra når det er tilfellet, i stedet for å selge deg den større byggingen — for den billigste appen er den du ikke trengte å lage.

Vanlige spørsmål