Kratak odgovor
Cena mobilne aplikacije za firmu zavisi od zadatka koji rešava, korisničkih uloga, potrebnih platformi, serverskog dela i povezivanja sa drugim sistemima. Broj ekrana sam po sebi nije dovoljan za procenu: jednostavna lista povezana sa neuređenim poslovnim podacima može zahtevati više rada od većeg, samostalnog interfejsa.
Pre iznosa dogovorite šta prva verzija mora da završi od početka do kraja, ko je koristi i kako proveravate da radi. U ponudi odvojite početni razvoj, spoljne usluge i održavanje. Ovde ne navodimo univerzalni cenovnik, jer bi bez tog obima iznos bio pretpostavka. Dajemo okvir pomoću koga možete tražiti i porediti konkretne procene.
Šta najviše utiče na cenu izrade mobilne aplikacije?
Procena treba da prati ceo poslovni tok, uključujući posao koji korisnik ne vidi na telefonu. Za svaku stavku označite šta već postoji, šta treba napraviti i ko obezbeđuje pristup ili sadržaj.
Pomerite tabelu levo ili desno da vidite sve kolone.
| Deo projekta | Šta treba definisati | Šta proveravate u ponudi |
|---|---|---|
| Korisnici i zadaci | Ko unosi, odobrava i vidi podatke; koje radnje završava. | Uloge, prava pristupa i dogovoreni tokovi. |
| Dizajn i platforme | iOS, Android ili web; jezici i podržani uređaji. | Ekrani, stanja greške i obuhvat testiranja. |
| Serverski deo i administracija | Nalozi, podaci, pravila i uređivanje sadržaja. | Šta se razvija, a šta koristi postojeći sistem. |
| Integracije | Poslovni program, plaćanje, raspored ili drugi servis. | Dostupan API, probni pristup i obrada neuspelog prenosa. |
| Rad bez interneta | Koji podaci se čitaju ili unose bez veze. | Sinhronizacija, prikaz statusa i provera konflikata. |
| Objava i predaja | Način distribucije, nalozi i obuka korisnika. | Priprema izdanja, pristupi, uputstva i odgovornosti. |
Ako API već postoji, prvo proverite dokumentaciju, prava korišćenja i primere odgovora. To ne znači automatski da je povezivanje završeno. Dva sistema mogu drugačije označavati istog kupca, proizvod ili status, pa i ta pravila ulaze u plan API integracije.
Šta treba da sadrži prva verzija, odnosno MVP?
Prva verzija treba da omogući jednom jasno određenom korisniku da završi važan posao. Izraz MVP ovde znači najmanji dogovoreni obim koji je upotrebljiv i može da se proveri u radu. Ne znači izostavljanje osnovnih prava pristupa, provere podataka ili oporavka kada radnja ne uspe.
Sledeći primeri su predlozi za definisanje obima, a ne gotovi paketi ili tvrdnje o rezultatima klijenata:
- Zakazivanje usluge: izbor usluge i slobodnog termina, potvrda i otkazivanje po dogovorenim pravilima. Za kasnije mogu ostati program lojalnosti i preporuke. Provera: dva korisnika ne mogu dobiti potvrdu za isti nedeljivi termin.
- Rad zaposlenih na terenu: pregled dodeljenih zadataka, unos nalaza i fotografije, slanje nadređenom. Za kasnije mogu ostati napredna analitika i optimizacija ruta. Provera: zadatak i prilog ostaju vezani za odgovarajući objekat i ovlašćenog korisnika.
- Portal povezan sa poslovnim sistemom: prijava partnera, njegov katalog ili dokumenti, slanje zahteva i praćenje statusa. Za kasnije mogu ostati dodatna tržišta i složenija odobravanja. Provera: partner vidi svoje podatke, a zahtev stiže u dogovoreni sistem bez dupliranja.
Za svaki tok napišite i šta se dešava kada nedostaje podatak, korisnik izgubi vezu ili nema dozvolu. Želje za sledeću fazu zadržite u posebnoj listi, sa razlogom za prioritet. Tako procena prve verzije ostaje vezana za jasan rezultat.
Da li aplikacija mora da bude u App Store-u i Google Play-u?
To zavisi od korisnika i funkcija. Za neke poslovne zadatke odgovara web aplikacija koja se otvara preko linka, dok je za druge potreban razvoj i distribucija za iOS ili Android. Ako tek birate pristup, prvo pogledajte poređenje mobilne aplikacije, web aplikacije i sajta.
Nemojte izjednačavati ikonicu na telefonu sa objavom u prodavnici. MDN objašnjava instaliranje web aplikacija, uz razlike između pregledača i platformi. U proceni zato navedite konkretan način pristupa i uređaje na kojima mora da radi.
Šta treba uračunati u testiranje i objavu?
Dogovorite listu uređaja i verzija sistema, korisničke uloge i scenarije koji potvrđuju prihvatanje. Pored uspešnog završetka zadatka, proverite odbijenu dozvolu za kameru, neispravan unos, prekid prenosa i ponovni pokušaj. Obim provera prati funkcije koje aplikacija stvarno ima.
Rad bez interneta posebno definišite. Android dokumentacija razdvaja lokalne i mrežne podatke i opisuje sinhronizaciju i konflikte. Za ponudu napišite praktičan scenario: šta korisnik može da sačuva bez veze, kako vidi da slanje čeka i šta treba da se dogodi kada se veza vrati.
Za App Store, Apple traži pripremljeno i proverljivo izdanje, uz tačne podatke, pristup funkcijama za proveru i dostupan serverski deo. Priprema i odgovor na pitanja tokom provere su poslovi koje treba imenovati u ponudi. Predaja aplikacije na proveru nije isto što i odobrena objava.
Koji troškovi ostaju posle prve objave?
Razdvojite trošak razvoja od naknada dobavljačima i podrške. U zavisnosti od rešenja, stavke mogu obuhvatiti hosting i bazu podataka, skladištenje fotografija, slanje poruka, spoljne API servise, naloge za distribuciju, praćenje grešaka i održavanje. Za svaku navedite ko plaća, kako se obračunava i šta se dešava kada poraste korišćenje.
Promene operativnog sistema i pravila distribucije takođe ulaze u plan. Na primer, Google Play propisuje zahteve za ciljnu Android API verziju. Zato održavanje ne treba svesti samo na dodavanje novih funkcija. Ugovorite obim provera i podrške, a kasniji razvoj procenjujte zasebno.
Kako se obim vidi na stvarnim poslovnim projektima?
Kore, aplikacija za distribuciju, povezuje zaduženje robe, isporuku, povrate i evidenciju smene. To je poslovna web aplikacija za rad vozača i administracije. Primer pokazuje zašto uz unos sa telefona treba planirati i zajedničke podatke, prava i pregled za kancelariju.
Livsmedelsstädarna je poslovna web aplikacija sa portalom kupaca: zaposleni beleže rad, kontrolori proveravaju nalaze, a kupci pregledaju podatke svojih objekata i izveštaje. Obim zato uključuje različite uloge i korake odobravanja.
Šta da pošaljete za konkretnu procenu aplikacije?
Za prvi razgovor dovoljan je kratak opis procesa. Nije potrebno da unapred izaberete tehnologiju. Koristite ovaj obrazac, uz anonimizovan primer dokumenta ili toka ako ga već imate:
- Korisnici: ko koristi aplikaciju i ko odobrava ili uređuje podatke?
- Tri najvažnija zadatka: šta svaka uloga mora da završi u prvoj verziji?
- Postojeći sistem: gde su sada podaci i da li postoji dokumentovan API?
- Integracije: sa kojim servisima se razmenjuju podaci i u kom smeru?
- Uređaji i veza: koji telefoni se koriste i šta mora da radi bez interneta?
- Distribucija i odgovornost: interni pristup, web ili prodavnice; ko obezbeđuje naloge i podršku?
Dodajte željeni rok, raspoloživi budžetski okvir i ono što sigurno ne ulazi u prvu fazu. Od ponuđača tražite iste stavke: isporuke, pretpostavke, isključenja, kriterijume prihvatanja, predaju pristupa i uslove održavanja. Tako poredite obim rada, a ne samo dva ukupna iznosa.
Za izradu mobilne aplikacije polazimo od ovog opisa i proveravamo zavisnosti pre procene. Pošaljite opis projekta i navedite najvažniji zadatak prve verzije.