Koliko traje izrada mobilne aplikacije?

Većina ljudi koji postavljaju ovo pitanje već ima datum na umu - krug investicija, konferenciju, sezonu, ugovor koji počinje u martu. Ne zanima ih koliko aplikacije traju uopšteno. Zanima ih da li će njihova biti spremna.

Zato je ovaj tekst o tome gde odlaze nedelje, koje se mogu preklapati i koji delovi rasporeda se zaista mogu skratiti. Delove koji se ne mogu skratiti vredi znati rano, jer upravo oni pretvaraju samouveren datum u propušten.

Faze i čemu svaka služi

Gotovo svaki projekat aplikacije prolazi kroz iste faze, bez obzira na to ko ga radi. Nazivi se razlikuju; posao ne.

Greška je čitati to kao pet blokova u nizu. U praksi dizajn ide ispred razvoja, testiranje teče uporedo sa njim, a priprema za prodavnice počinje mnogo pre nego što je aplikacija gotova. Raspored koji ih tretira kao uzastopne duži je nego što treba.

Kako se ove faze raspoređuju na stvarnom projektu, pogledajte naš proces u osam koraka.

Da biste procenili cenu i broj nedelja za sopstveni obim, isprobajte besplatni kalkulator cene razvoja aplikacije.

Gde zaista odlaze nedelje

Osnivači rok obično zamišljaju kao gotovo isključivo programiranje. Retko je tako. Istraživanje i dizajn obično zauzimaju veći deo nego što se očekuje, a testiranje i lansiranje mnogo veći.

Istraživanje je kratko u kalendarskom smislu, ali presudno: svako pitanje koje tu ostane bez odgovora kasnije se vraća kao kašnjenje u razvoju. Dizajn traje duže nego što ljudi očekuju jer su ekrani iz prezentacije oni laki - posao je u tokovima oko njih i u praznim stanjima, stanjima učitavanja i greškama koje niko ne skicira.

Razvoj je vidljiva faza i najpredvidljivija, pod uslovom da se obim drži. Testiranje je faza koja se najčešće skraćuje, a njeno skraćivanje ne štedi vreme koliko ga premešta posle lansiranja, gde košta više.

Vreme oduzeto testiranju nije ušteđeno. Odloženo je za vaše korisnike, po lošijem kursu.

Delovi rasporeda koje ne kontrolišete

Dve stavke na svakom rasporedu mobilne aplikacije potpuno su van domašaja razvojnog tima, i obe zaslužuju rezervu umesto optimizma.

Prva je pregled u prodavnicama aplikacija. Apple i Google pregledaju svaku prijavu, i iako jednostavna verzija često brzo prođe, odbijanje vraća sat na početak. Odbijanja se obično tiču smernica, a ne grešaka - brisanja naloga, prikaza pretplata, obrazloženja dozvola, izjava o privatnosti - i zato je dizajn prema smernicama unapred važniji od reagovanja na njih posle.

Druga je bilo ko drugi od koga vaša aplikacija zavisi. Pružalac usluga plaćanja koji proverava vašu firmu, testno okruženje banke, servis za proveru identiteta, IT odeljenje klijenta koje odobrava pristup API-ju: niko od njih ne ide vašim tempom, a svi mogu da budu na kritičnoj putanji.

Počnite rano sa oba. Nalozi u prodavnicama, verifikacija firme i pristupni podaci trećih strana mogu se srediti dok je dizajn još u toku, i time se uklanja najčešći razlog kašnjenja lansiranja koji nema veze sa softverom.

Pet stvari koje pouzdano dodaju nedelje

Rokovi retko kasne zato što je inženjering bio spor. Kasne iz malog broja razloga koji se ponavljaju od projekta do projekta.

1. Obim o kom se još odlučuje posle početka razvoja. Svaka odluka doneta usred razvoja košta više od iste odluke donete mesec dana ranije.
2. Sadržaj i tekstovi koji kasne. Pravni tekstovi, tekstovi uvodnih ekrana, podaci o proizvodima i slike blokiraju ekrane koji su inače gotovi.
3. Integracije sa trećim stranama koje se pokažu težim nego što je dokumentacija nagoveštavala.
4. Spori krugovi povratnih informacija na vašoj strani. Nedelja čekanja na komentare je nedelja na kraju projekta, svaki put.
5. Kasno otkriven zahtev koji menja strukturu podataka. Ovo je skupa stavka, a istraživanje postoji da je spreči.

Četiri od ovih pet su na strani klijenta. To nije prigovor - to je koristan deo, jer znači da je veliki deo roka zaista pod vašom kontrolom.

Šta se iskreno može skratiti

Neki rasporedi se zaista mogu skratiti, i vredi biti precizan u tome kako.

Smanjivanje obima funkcioniše i jedina je poluga koja uvek funkcioniše. Prva verzija sa manje funkcija isporučuje se ranije i govori vam više od kompletne koja stiže kasnije. Lansiranje na jednoj platformi funkcioniše, ako su vaši korisnici uglavnom na njoj. Korišćenje proverenih servisa za plaćanja, autentifikaciju ili poruke funkcioniše, jer ne pravite ponovo već rešene probleme.

Dodavanje ljudi uglavnom ne funkcioniše. Posle određene tačke, dodatni inženjeri na istoj funkciji donose koordinaciju, a ne brzinu, a tim sastavljen usred projekta prve nedelje provodi učeći bazu koda umesto da je proširuje.

Preskakanje testiranja, dizajna ili istraživanja takođe ne skraćuje projekat. Ono premešta posao u fazu u kojoj je skuplji, i obično vidljiviji javnosti.

Kada je ograničenje datum, a ne spisak funkcija, rešenje je namerno ograničena prva verzija - upravo takav je naš MVP za 30 dana.

Kako postaviti datum koji možete da odbranite

Datum lansiranja je verodostojan kada je sastavljen od faza, a ne najavljen na početku. Krenite unazad od dana kada morate da budete dostupni, uračunajte pregled u prodavnicama i odobrenja trećih strana, ostavite prostor za krug testiranja koji pronalazi stvarne probleme i zadržite rezervu koja se ne potroši neprimetno u drugoj nedelji.

Zatim napredak procenjujte po onome što radi, a ne po onome što se prijavljuje. Nedeljne verzije koje možete da instalirate i koristite jedino su iskreno merilo roka, jer ne mogu da budu optimistične.

Vreme i novac idu zajedno, a drugu polovinu ovog pitanja obrađujemo u tekstu koliko zaista košta mobilna aplikacija.

Česta pitanja