Stvarni vremenski okvir razvoja aplikacije: od ideje do lansiranja

Ako pitate deset agencija koliko traje izrada aplikacije, dobit ćete deset samouvjerenih odgovora i nijedan od njih neće biti istinit. Iskren odgovor jest da vam nitko ne može precizno reći prvog dana — ali svatko tko je doista isporučio softver može vam opisati njegov oblik: koje faze postoje, koje tiho jedu kalendar i gdje vaše vlastite odluke ubrzavaju stvari ili ih zaustavljaju. To je taj oblik, jednostavno zapisan.

Vidio sam mnogo vlasnika malih tvrtki kako ulaze u projekt aplikacije očekujući uredan, linearni marš od skice do App Storea. Umjesto toga dobivaju nešto što se doima kao niz zaravni i naglih skokova. Tjedni u kojima izgleda kao da se ništa ne događa, a zatim dan kada se cijela stvar iznenada sklopi. Ništa od toga nije znak da nešto nije u redu. Tako se softver jednostavno radi — i čim možete imenovati faze, cijeli proces prestaje djelovati kao crna kutija u koju uplaćujete nadajući se najboljem.

Postavimo dakle realna očekivanja. Za fokusiranu prvu verziju poslovne aplikacije — ne raspršenu platformu, već prvu verziju koja jedan posao radi dobro — obično je riječ o rasponu od tri do pet mjeseci od ozbiljnog početka do stvarnog lansiranja. Gdje ćete pasti unutar tog raspona manje ovisi o tehnologiji, a više o tome koliko ste jasni, koliko brzo donosite odluke i koliko toga pokušavate ugurati prije lansiranja. Prođimo kroz to.

Zašto je procjena koju ste dobili vjerojatno pogrešna

Brojka od šest tjedana baš i nije laž — to je vrijeme potrebno za izradu dijela koji svatko može zamisliti. Zaslona. Gumba. Onoga što možete demonstrirati. Ono što ta brojka tiho zanemaruje sve je oko vidljive aplikacije: odluke, podaci, integracije s alatima koje već koristite, testiranje, pregled u trgovini aplikacija i neizbježni krug „zapravo, može li ovo i ono?“

Koristan način razmišljanja: kôd je rijetko usko grlo. Usko grlo je jasnoća. Svaki sat koji vaš programer čeka na odluku — koji pružatelj plaćanja, što se događa kada se rezervacija otkaže, tko što vidi — sat je za koji vremenski okvir klizi. Projekti koji brzo završe nisu oni s najboljim inženjerima. To su oni u kojima vlasnik odgovara na pitanja u jednom danu umjesto u dva tjedna.

Dok dakle čitate faze u nastavku, pratite trenutke u kojima je lopta na vašoj strani. To su točke u kojima projekt ili zadržava zamah ili se tiho zaustavlja na tri tjedna jer je e-pošta ostala neodgovorena. Vremenski okvir je zajednička odgovornost, a polovicu na strani klijenta ljudi podcjenjuju.

Faza 1: Otkrivanje i određivanje opsega (1–3 tjedna)

Prije nego što itko dizajnira ijedan zaslon, postoji faza koja ne izgleda kao napredak, ali određuje sve: shvatiti što zapravo gradite i, još važnije, što ne gradite. Tu nejasna ideja („aplikacija za moje kupce“) postaje konkretan, dovršiv popis značajki za prvu verziju.

Kad se dobro odradi, otkrivanje je uglavnom razgovor i teška pitanja. Tko ovo koristi i na kojem uređaju? Koja je ona jedna stvar koju mora raditi briljantno? Što može pričekati drugu verziju? Dobar partner će vam se ovdje suprotstaviti, a vi to i želite — svaka značajka koju sada izrežete tjedni su koje vraćate. Rezultat je obično kratak pisani opseg i gruba žičana shema, nešto što možete držati u ruci i reći da, to je to.

Faza 2: Dizajn i prototip (2–4 tjedna)

Sada aplikacija postaje nešto što možete vidjeti i kliknuti, prije nego što vas ijedan redak stvarnog koda na išta obveže. Dizajneri pretvaraju žičanu shemu u prave zaslone — boje, tijek, stvarni osjećaj korištenja — obično kao interaktivni prototip kroz koji možete tapkati na vlastitom telefonu.

Ova je faza zlato iz jednog razloga: promjena dizajna je jeftina, promjena izgrađenog softvera je skupa. Pomicanje gumba u prototipu traje pet minuta. Pomicanje nakon što je značajka kodirana, testirana i povezana s vašim podacima može trajati dan. Dakle, ovo je trenutak da budete probirljivi, da to pokažete nekolicini stvarnih kupaca ili zaposlenika i da uhvatite probleme „o, to nitko neće razumjeti“ dok ih je još bezbolno popraviti.

Najčešći način na koji se ova faza otegne nije dizajner — to je neodlučnost na vašoj strani. Beskrajni krugovi malih izmjena ili tri osobe s pravom veta koje se nikad ne slože. Odlučite rano tko odobrava, dajte povratne informacije u skupinama umjesto u kapljicama i ova faza ostaje zbijena.

Faza 3: Izrada (6–12 tjedana)

Ovo je dio koji svatko zamišlja kad pomisli na „izradu aplikacije“ i to je najduža pojedinačna dionica — ali rijetko najnepredvidljivija, ako su prve dvije faze dobro odrađene. Programeri grade aplikaciju u dijelovima, obično u kratkim ciklusima u kojima vidite radne dijelove svaki tjedan ili dva, umjesto da nestanu na tri mjeseca i ponovno se pojave s gotovim proizvodom.

Taj je ritam važan. Želite reagirati na stvaran, pokrenut softver rano, a ne na izvješće o statusu. Kada zaista možete koristiti tijek rezervacija u četvrtom tjednu, primijetit ćete stvari koje nijedna specifikacija nije mogla uhvatiti — a njihovo ispravljanje u četvrtom tjednu daleko je jeftinije nego u desetom. Dobar proces izrade čini aplikaciju vama vidljivom neprekidno, a ne samo na kraju.

Što tiho rasteže izradu

Dvije stvari proširuju izradu više od svega ostalog. Prva su integracije — svaki vanjski sustav s kojim aplikacija mora razgovarati (vaš pružatelj plaćanja, vaš postojeći alat za rezervacije, vaš računovodstveni softver, dostavna služba) dodaje posao, a svaki može donijeti vlastita iznenađenja. Druga je širenje opsega: stalno kapanje malih dodataka koji se svaki čine sićušnim, ali zajedno guraju lansiranje mjesec dana unaprijed. Oboje je upravljivo, ali samo ako ih vidite kako dolaze.

• Svaka vanjska integracija dodaje dane, ponekad tjedne — predvidite ih izričito, nemojte pretpostaviti da su besplatne.
• „Samo još jedna mala značajka“ pojedinačno je najčešći uzrok propuštenog datuma lansiranja.
• Stvarni podaci neurednij su od testnih; planirajte vrijeme za rubne slučajeve koje je vaša tablica tiho podnosila.
• Korisnički računi, plaćanja i obavijesti varljivo su duboki — uvijek koštaju više nego što izgledaju.
• Odobrenja i sadržaj koji dugujete timu (logotipi, tekstovi, pravni tekst) mogu zaustaviti izradu jednako sigurno kao i greška.

Faza 4: Testiranje i ispravljanje (2–4 tjedna)

Evo faze za koju ljudi zaborave da postoji, a zatim joj zamjere kad se pojavi. Kad je aplikacija izgrađena, mora se staviti na kušnju — na različitim telefonima, s lošim internetom, od strane ljudi koji je nisu izradili i koji će raditi stvari koje nitko nije predvidio. Testiranje nije formalnost. To je razlika između aplikacije kojoj vaši kupci vjeruju i one koju deinstaliraju nakon prvog rušenja.

Očekujte da će se ovdje pojaviti popis grešaka i neravnih rubova. To nije znak da je izrada loše prošla; to je čitava svrha faze. Neke su brzi popravci, neke otkrivaju odluku koju treba preispitati. Timovi koji ovo dobro vode tretiraju to kao normalan, planiran dio posla — ne kao hitan slučaj i ne kao nešto što treba preskočiti jer se lansiranje bliži. Preskakanje testiranja ne štedi vrijeme. Samo premješta greške s vašeg testnog telefona na telefone vaših kupaca, gdje njihovo ispravljanje košta deset puta više.

Faza 5: Lansiranje i čekanje na trgovinu aplikacija (1–2 tjedna, plus pregled)

Lansiranje je manje jedan trenutak, a više pažljivo postupno uvođenje. Ako je riječ o web-aplikaciji, vremenom u potpunosti upravljate vi — pritisnete prekidač kad ste spremni. Ako ide u Appleov App Store ili Google Play, dio rasporeda predajete njima: njihov proces pregleda može trajati od jednog dana do više od tjedan dana, a povremeno će vam je vratiti s nečim za ispraviti. To je vrijedno znati unaprijed kako ne bi iznenadilo datum lansiranja koji ste obećali kupcima.

Pametan način za lansiranje nije veliko bombastično otkrivanje cijeloj bazi kupaca. To je tiho izdanje za malu skupinu najprije — šačicu prijateljskih kupaca ili vlastite zaposlenike — kako biste uhvatili stvarne probleme prije nego što ih svi vide. Zatim širom otvarate vrata. Lansiranje koje se čini dosadno bezdogađajnim lansiranje je koje je dobro prošlo.

1. 1
   Tiho lansiranje maloj skupini

   Najprije izdajte šačici prijateljskih korisnika ili zaposlenika. Stvarno korištenje pronalazi ono što je testiranje propustilo, uz ulog smanjen do kraja.
2. 2
   Predajte rano ako idete u trgovine aplikacija

   Apple i Google upravljaju satom pregleda, ne vi. Predajte s rezervom kako spori pregled ili odbijanje ne bi srušili vaš obećani datum.
3. 3
   Pažljivo pratite prvi tjedan

   Držite nekoga pri ruci da brzo reagira. Prvi tjedan iznosi na vidjelo stvarne rubne slučajeve koje nijedno testno okruženje nikad ne iznosi.
4. 4
   Isplanirajte posao za dan nakon prije nego što lansirate

   Aplikacija nikad nije 'gotova' pri lansiranju. Dogovorite se unaprijed tko će se baviti neizbježnim malim popravcima i prvim krugom povratnih informacija.

Spajanje cijelog vremenskog okvira

Posloženo od početka do kraja, te vam faze daju realnu sliku. Nijedna od njih nije egzotična; ono što ljude spotakne jest zaboravljanje da su one neglamurozne — otkrivanje, testiranje, čekanje na trgovinu aplikacija — stvarno vrijeme u kalendaru, a ne pogreške zaokruživanja. Evo otprilike kako se fokusirana prva verzija obično raspoređuje kroz mjesece.

Zbrojite to i vidite zašto su tri do pet mjeseci iskren raspon za stvarnu prvu verziju i zašto oni koji obećavaju šest tjedana tiho redefiniraju što „aplikacija“ znači. To nije pesimizam — to je razlika između datuma koji ćete zaista ispuniti i onog zbog kojeg ćete se kroz cijeli projekt ispričavati.

Kako to istinski ubrzati (i kako ne)

Možete ići brže, ali stvarne poluge nisu one za kojima ljudi posežu. Bacanje više programera na napola definiran projekt obično ga čini sporijim, a ne bržim. Iskreni ubrzivači su neglamurozni: odlučite što izostaviti, brzo odgovarajte na pitanja i oduprite se porivu da dodajete stvari usred izrade.

Daleko najveći je nemilosrdan opseg. Što je vaša prva verzija manja i jasnija, to se prije lansira — a lansirana aplikacija koja zarađuje za sebe naučit će vas više u dva tjedna nego što će vas ikad naučiti još dva mjeseca planiranja. Uvijek možete dodati. Ne možete vratiti mjesece potrošene na izradu značajki koje na kraju nitko nije želio.

Postoji srodna istina koju vrijedi reći naglas: ne mora sve uopće biti aplikacija po mjeri. Ponekad je stvarni problem dionica ručnog rada kojom bi komad automatizacije mogao tiho upravljati, bez aplikacije. Dobar partner reći će vam kada je to slučaj umjesto da vam proda veću izradu — jer najjeftinija aplikacija ona je koju niste morali napraviti.

Česta pitanja