8 skupih pogrešaka u razvoju aplikacija koje mali poduzetnici stalno rade

Evo neugodne istine o projektima aplikacija koji krenu po zlu: do trenutka kad kod izgleda pogrešno, projekt je već bio izgubljen tjednima ranije. Skupe pogreške u razvoju aplikacija za mala poduzeća gotovo nikad se ne događaju za tipkovnicom. Događaju se u usputnim razgovorima — opis koji nikad nije zapisan, značajka koju je netko dodao 'kad već radimo', programer odabran jer ga je prijatelj preporučio. Ništa od toga u tom trenutku ne djeluje kao odluka. Sve vas to košta kasnije.

Vidio sam mnogo malih poduzeća kako naručuju svoju prvu aplikaciju, a pozvali su me i da spasim podosta njih nakon činjenice. Vlasnici rijetko su nemarni ljudi. Oštroumni su, pažljivi, dobri u vođenju posla. No softver ima vlastiti skup zamki koje ne postoje nigdje drugdje u njihovom radnom životu, a nitko ih nije upozorio. Tako upadaju ravno u istih osam zamki, otprilike istim redoslijedom, svaki put.

Ovo je popis koji bih volio da svaki vlasnik ima prije nego potroši i lipu. Ne teorija — stvarne, ponavljajuće pogreške i male korekcije kursa koje bi spasile svaki projekt. Ako se spremate izraditi aplikaciju, ili ste već usred izrade i nešto vam se čini čudno, prvo pročitajte ovo. Većina se još može popraviti ako ih uhvatite na vrijeme.

Pogreška 1: Gradite prije nego što ste dokazali da je netko želi

Najskuplja pogreška ujedno je i najčešća: obvezati se na potpunu izradu prije nego što postoji ikakav stvaran dokaz da aplikacija rješava problem za koji će ljudi platiti ili ga koristiti. Ideja se vlasniku čini očitom — naravno da će je kupci htjeti — i upravo je ta sigurnost ono što je opasno. Sigurnost djeluje kao potvrda. Ona to nije.

Provjera ne znači pitati deset prijatelja sviđa li im se ideja; svi kažu da iz pristojnosti. Znači staviti najmanju moguću verziju pred stvarne korisnike u stvarnoj situaciji i promatrati što doista rade. Klikabilni prototip, odredišna stranica koja mjeri prijave, ručna 'concierge' verzija u kojoj automatizaciju lažirate vlastitim rukama — bilo što od toga govori vam više nego gotova aplikacija izgrađena na slutnji. Redoslijed je važan: jeftino dokažite potražnju, zatim skupo gradite. Obrnite to i možete potrošiti cijeli budžet polirajući nešto što nitko ne otvori dvaput.

Pogreška 2: Širenje opsega prerušeno u ambiciju

Svaka aplikacija počinje vitka i uredna. Zatim počinje ono 'kad već radimo'. Kad već gradimo ekran za rezervacije, bi li mogao obrađivati i poklon-bonove? I bodove vjernosti? I sustav preporuka? Svaki dodatak zvuči razumno sam za sebe. Zajedno tiho utrostruče vremenski okvir i račun — i odguraju lansiranje toliko daleko da izvorni zamah umre.

Rješenje nije reći ne dobrim idejama. Rješenje je parkirati ih. Vodite vidljiv popis 'verzija dva' na koji svaka blistava ideja odlazi čekati svoj red. To djeluje psihološki jednako kao i praktično: ljudi prestaju navaljivati da nagužvaju značajke u prvo izdanje čim povjeruju da za njihovu ideju postoji stvarno mjesto kasnije. Vaša prva verzija treba raditi jednu stvar uistinu dobro, ne deset stvari osrednje. Aplikacija koja savlada jedan tijek rada — koristi se. Aplikacija koja sve radi napola — napušta se.

Pogreška 3: Nema pisanog opisa — samo zajednička mentalna slika

Ova je nevidljiva dok ne ugrize. Vlasnik ima jasnu aplikaciju u glavi. Programer ima jasnu aplikaciju u glavi. Svi kimaju na uvodnom sastanku. Nitko to ne zapiše kako treba — a dvije slike, ispostavi se, nikad nisu bile ista slika. To otkrijete na pola puta, kad ono što se gradi nije ono što ste zamišljali, i sad se vodi rasprava o tome tko je što rekao.

Ne treba vam specifikacija od sto stranica. Treba vam nekoliko stranica koje bi svaki pridošlica mogao pročitati i razumjeti: tko koristi ovu aplikaciju, koje su tri ili četiri stvari koje s njom trebaju raditi, kako izgleda uspješan ishod. Dodajte grubu skicu ključnih ekrana. To je to. Smisao opisa nije birokracija — to je zajednička referenca na koju oboje možete pokazati kad sjećanje i stvarnost počnu odstupati, što uvijek čine.

Pogreška 4: Biranje programera na pogrešan način

Većina vlasnika bira svog prvog programera po jednom od dva slabašna signala: najnižoj ponudi ili osobnoj preporuci nekoga iz druge branše. Oboje može upaliti pukom srećom. Nijedno nije pouzdan način da odaberete nekoga kome ćete povjeriti znatan dio novca i nekoliko mjeseci budućnosti svog posla.

Najniža ponuda osobito je podmukla u softveru, jer je jaz između ponude i konačnog troška golem i nevidljiv. Jeftin programer kojem trebaju tri kruga prerade, nestane na dva tjedna i ostavi vas s kodom koji nitko drugi ne može održavati daleko je skuplji od malo skupljeg koji to napravi kako treba. Cijena je ono što vidite; ukupni trošak je ono što plaćate.

Što zapravo provjeriti

Zatražite da vidite stvari koje su isporučili, a koje još rade, i ako možete, razgovarajte s tim klijentima bez programera u prostoriji. Pitajte kako rješavaju izmjene usred projekta, jer izmjena će biti. Pitajte tko posjeduje kod i račune kad je gotovo — odgovor uvijek treba biti vi. I obratite pozornost postavljaju li vam dobra pitanja natrag. Programer koji samo prima naredbe vrlo će učinkovito izgraditi upravo pogrešnu stvar. Dobri se suprotstavljaju, ukazuju na rupe u vašem razmišljanju i tretiraju opis kao polazište za razgovor, ne kao fiksni popis za kupnju.

Pogreška 5: Budžetirate izradu, zaboravljate ostalo

Aplikacija nije jednokratna kupnja poput tiskane brošure. Ona je živo biće koje treba hranu. Vlasnici rutinski budžetiraju izradu i ništa drugo, a onda ih zateknu troškovi koji stignu poslije: hosting, naknade trgovina aplikacija, održavanje da se ide ukorak s ažuriranjima operacijskog sustava telefona te neizbježan krug ispravaka i malih poboljšanja čim stvarni ljudi počnu koristiti.

Razuman okvirni princip: koliko god izrada košta, izdvojite znatan dio toga ponovno za prvu godinu njezina rada. Točna brojka varira, ali pogreška je univerzalna — tretirati dan lansiranja kao ciljnu crtu kad je on zapravo startna crta. Aplikacija koja se lansira i potom tiho napusti jer nema budžeta za održavanje jedan je od najtužnijih, najčešćih ishoda u cijelom ovom području, a posve se može izbjeći poštenim planiranjem unaprijed.

Pogreška 6: Dizajnirate za sebe umjesto za svog korisnika

Svoj posao poznajete u dušu, što vas čini najgorim mogućim sucem toga je li vaša aplikacija laka za korištenje. Stvari koje su vama očite — žargon, redoslijed kojim obavljate zadatke, prečaci koje radite bez razmišljanja — zbunjuju korisnika koji ih vidi prvi put. Aplikacija koja vlasniku ima savršen smisao, a sve druge zbunjuje, propala je, koliko god bila domišljata.

Lijek je jeftin i pomalo ponizan: promatrajte stvarne ljude kako je koriste prije nego što lansirate. Ne svoj tim, koji već zna kako bi trebalo raditi — stvarne kupce ili osoblje koji je nikad nisu vidjeli. Dajte im aplikaciju, dajte im zadatak i ne govorite ništa. Gdje oklijevaju, dotaknu pogrešnu stvar ili uzdahnu — to je vaša povratna informacija o dizajnu. Pet ljudi dovoljno je da izađu na vidjelo najgori problemi. Preskakanje tog koraka razlog je zašto se aplikacije lansiraju s gumbom 'pošalji' koji nitko ne može naći i tijekom prijave koji izgubi pola onih koji pokušaju.

• Dajte testeru stvaran zadatak, ne obilazak — 'rezervirajte termin za sljedeći utorak', pa šutite.
• Promatrajte njihove ruke i lice, ne samo uspiju li na kraju.
• Zabilježite svako oklijevanje; pauza je problem dizajna koji iznutra ne možete vidjeti.
• Oduprite se porivu da objašnjavate — ako morate objasniti, aplikacija je to trebala.
• Testirajte s pet ljudi, ispravite očite propuste, pa testirajte ponovno.

Pogreška 7: Gradite nativni iOS i Android kad vam nije trebalo

Postoji refleks izgraditi 'pravu' aplikaciju i za iPhone i za Android od prvog dana, potpuno nativnu, kako to rade veliki brendovi. Za većinu malih poduzeća to je dva do tri puta veći trošak i složenost za korist koju vaši korisnici nikad neće primijetiti. Još gore, sada zauvijek održavate dvije zasebne baze koda, udvostručujući svaki budući ispravak.

Često pravi prvi potez uopće nije nativna aplikacija. Dobro izrađena web-aplikacija koja radi u pregledniku bilo kojeg telefona, ili višeplatformski pristup koji iz jedne baze koda proizvodi obje verzije za trgovine, izvodi vas na tržište brže i jeftinije — a uvijek možete poslije prijeći na potpuno nativno ako stvarna uporaba dokaže da se isplati. Pitanje koje treba postaviti nikad nije 'nativno ili web' apstraktno. Ono je: koja je najmanja, najjeftinija stvar koja stvarnim korisnicima omogućuje da obave ključni posao? Izgradite to, učite iz toga, pa potrošite veliki novac s dokazima umjesto s pretpostavkama.

Pogreška 8: Tretiranje lansiranja kao kraja posla

Osma je pogreška vjerovati da je projekt gotov kad aplikacija ode u rad. Nije — tu počinje pravi projekt. Aplikacija bez plana kako je dovesti u ruke korisnika, bez načina da se čuje što misle i bez namjere da je se poboljša na temelju onoga što naučite jest aplikacija koja iščezne u nekoliko mjeseci. Izrada je bila lak dio. Prihvaćanje je teški dio, a gotovo ga nitko ne planira.

Prije lansiranja znajte tri stvari: kako će ljudi saznati da aplikacija postoji, kako ćete mjeriti koriste li je doista i kako ćete prikupiti ono što vam kažu da sljedeći krug posla vodi stvarnost umjesto nagađanja. Ništa od toga nije skupo. To je samo drukčiji način razmišljanja — aplikacija nije stvar koju dovršite i odete od nje, ona je odnos koji održavate. Vlasnici koji to razumiju dobivaju aplikacije koje s vremenom postaju korisnije. Oni koji ne razumiju dobivaju skok na dan lansiranja i dug, tih pad.

Kako ostati izvan svih osam odjednom

Čitane zajedno, ove pogreške dijele jedan korijen: brzo kretanje na pretpostavkama umjesto sporo na dokazima. Svaka od njih mjesto je gdje se činilo jeftinije preskočiti oprezan korak. I svaku od njih daleko je jeftinije riješiti prije izrade nego poslije. Evo slijeda koji tiho izbjegava svih osam.

1. 1
   Dokažite potražnju prije izrade

   Prototip, odredišna stranica ili ručna verzija. Pribavite stvaran dokaz da netko ovo želi prije nego što obvežete budžet.
2. 2
   Napišite opis i popis verzije dva

   Nekoliko jasnih stranica koje svatko može razumjeti, plus parkiralište za svaku ideju 'kad već radimo' da ne izbaci v1 iz tračnica.
3. 3
   Odaberite programera po rezultatima, ne po cijeni

   Isporučen rad, razgovori s preporukama, jasno vlasništvo nad kodom i računima i netko tko postavlja dobra pitanja natrag.
4. 4
   Budžetirajte cijelu prvu godinu, ne samo izradu

   Hosting, održavanje, ispravci i podrška. Dan lansiranja je startna crta, pa financirajte rad te stvari.
5. 5
   Odaberite najmanju platformu koja obavlja posao

   Web ili višeplatformski prvo u većini slučajeva. Na potpuno nativno prijeđite poslije, s dokazima, samo ako to uporaba zahtijeva.
6. 6
   Testirajte sa stvarnim korisnicima, pa planirajte lansiranje

   Promatrajte pet stranaca kako je koriste, ispravite očite propuste i unaprijed odlučite kako će je ljudi naći i kako ćete mjeriti uporabu.

Česta pitanja