Već godinama su telefoni predominantni uređaji za online kupovinu, pretrage, upotrebu softvera i gotovo svega što vam padne na pamet. Za razliku od aplikacije za kapetane (partnere) koju smo razvili još 2017, iskustvo pretrage i bukiranja pecanja je ostalo na web-u. Logičan nastavak je bio da razvijemo mobilnu aplikaciju. Naravno, da stvari budu zanimljivije, nismo imali nijednog senior React Native inženjera da se pozabavi ovom problematikom, te smo se oslonili na staru dobru fleksibilnost. U nastavku Olga priča kako je to sve izgledalo iz Lead Engineer ugla.
Prve skice
Krenuli smo od onoga što nam je bilo najlakše, a to je da odaberemo u čemu ćemo da pišemo aplikaciju. S obzirom da frontend tim koristi React i da već imamo kapetansku aplikaciju napisanu u React Native-u, odlučili smo se da tako bude i ovog puta. To je otvorilo vrata ljudima iz frontend tima da se oprobaju u mobile-u (kasnije i obrnuto).
Prvo smo oformili mali tim koji će učestvovati u planiranju i izradi aplikacije (produkt menadžer, dizajneri, programeri, testeri), a zatim definisali skup funkcionalnosti koje će prva verzija aplikacije imati. Funkcionalnosti smo podelili na 3 tipa:
- essentials – logovanje, upravljanje rezervacijama i dopisivanje, odnosno, ono što će korisniku najviše značiti i zbog čega će nastaviti da koristi aplikaciju;
- must have – pretraga kapetana i brodova, uvid u njihovu ponudu i na kraju, rezervisanje željene opcije. Praktično, ono bez čeka aplikacija nema smisla da postoji.
- nice to have – pamćenje omiljenih brodova za pecanje (Wishlist), in-app help center i sl.
Dovoljno dobro, ne savršeno
Ovo su nam bile glavne smernice u razvoju aplikacije. Dogovorili smo se da po završetku prve i druge faze pustimo aplikaciju live.
Prvenstveno smo se usredsredili na realizaciju funkcionalnog prototipa. Nismo odmah pravili sve i nismo se opterećivali da sve bude pod konac, već da funkcioniše kako treba. Dakle, ideja je bila da pustimo dovoljno dobru aplikaciju (ne savršenu) kako bismo što pre učili, slušajući komentare korisnika, a zatim je i unapredili na osnovu istih. To je “Lean” pristup koji se prožima kroz skoro sve projekte u FishingBooker-u. Cela firma i proizvod su nastali iz takvog pristupa, i to je usađeno duboko u sve nas.
Na početku je samo jedna osoba radila na aplikaciji – ja :)). Moj posao je bio da postavim dobar kostur aplikacije i da omogućim da kroz 2 meseca imamo postavljenu navigaciju i sistem za logovanje kako bi ostali članovi tima mogli da se priključe. Iako sam samo ja kodirala, rađene su česte konsultacije i detaljni code review-ovi kako bi svi članovi tima bili “on the same page”. Dva meseca kasnije, planirano je i urađeno.
“Error-handling” i praćenje događaja
Pored karakteristika koje vide krajnji korisnici, identifikovali smo i tehničke stvari koje će se provlačiti kroz sve funkcionalnosti. To su bili “error-handling” i praćenje događaja. Ovo se ispostavilo kao sjajna stvar jer smo odmah imali uniforman sistem za identifikovanje grešaka. Prvo smo uradili analizu šta je sve u opticaju, a zatim izbor sveli na Bugsnag i Crashlytics.
Bugsnag već koristimo na postojećoj (kapetanskoj) aplikaciji i radi dobar posao, a Crashlytics je deo Firebase-a koji koristimo i izgledalo je zanimljivo iskoristiti i tu funkcionalnost. Međutim, na kraju smo se opredelili za Bugsnag jer nam Crashlytics nije pružao jednostavno dodavanje sourcemap-a, što bi otežalo ili onemogućilo pristupim detaljima o tome kako je došlo do određene greške.
3 meseca nakon puštanja i praćenja grešaka revidirali smo još jednom alat koji koristimo i odlučili da probamo Sentry jer je dosta bolji interfejs. Zbog dobro postavljene infrastrukture smo sa lakoćom zamenili Bugsnag i samo smo morali da vodimo računa o Sentry-ju, a ne i o tome kako će promena da utiče na ostatak aplikacije.
Muke development procesa
Kada je na red došla implementacija komponente za plaćanje, shvatili smo da ne postoji zvanična React Native biblioteka. Postojao je zvaničan iOS i Android SDK i to smo videli kao jedinu bezbednu opciju. Ušli smo u native programiranje kako bi rešenje bilo najbolje implementirano
Povučeni prethodnim iskustvom, napravili smo razliku u radu na aplikaciji koja je u izradi u odnosu na kapetansku koja je live na store-ovima. Kod smo mergovali na master čim prođe code review i nismo čekali da prodju QA i design review – što nije slučaj za aplikaciju koja je live na store-ovima. Ovim načinom rada smo brže mogli da vidimo izmene koje su kolege pravile i da brže razvijamo proizvod, dok nam je kvalitet koda ostajao na visokom nivou. Treba pomenuti da nismo ukinuli QA i dizajn review, samo je to pomereno da se radi nakon što se umerguje u glavnu granu.
Poslednja 3-4 meseca pred puštanje radili smo na high fidelity dizajnu, iscrpnom testiranju i rešavanju bagova. High fidelity je išao brzo zahvaljujući dobro organizovanom kodu, deljenim komponentama i prethodno jako bliskoj saradnji dizajnera i programera. Svakodnevno smo radili interno testiranje unutar tima koji je radio na aplikaciji. Imali smo takođe i 2-3 velika testiranja gde je cela firma testirala aplikaciju i prijavljivala bagove i svako čudno ponašanje. Ovo nam je mnogo pomoglo, zato što je core tim posle 2 godine gledanja iste aplikacije navikao na određen način njenog korišćenja i teško je bilo pristupiti joj indiferentno.
Svaki bag je revidiran i prioritizovan. Bagove smo organizovali u git projektu i tu smo lako mogli da pratimo u kojoj se fazi nalazi bag, da li je rešen ili je potrebno da se testira.
Tihi launch ili šta kada je aplikacija gotova
Samo puštanje aplikacije je bilo svečano unutar kompanije, sa celim timom, šampanjcem i velikim enter dugmetom. 🙂
Eksterno smo se odlučili za tihi launch. U praksi to znači da je aplikacija dostupna na svim “store”-ovima, ali da ne postoje marketinške kampanje (plaćene i neplaćene) koje je na bilo koji način plasiraju korisnicima. Samo oni koji izvrše pretragu na “store”-u će i naći aplikaciju.
Zahvaljujući ovom pristupu, mogli smo brzo da reagujemo na bagove i predložene promene bez da preveliki broj korisnika ima negativno iskustvo. Samim tim što aplikacija radi bolje svakoga dana, verujemo da će App i Google store recenzije imati bolju prosečnu ocenu i dodatno “pogurati” uspeh nove aplikacije.
Sada, 3 meseca nakon puštanja, aplikacija je stabilna i spremni smo da krenemo sa marketinškim kampanjama i pokažemo FishingBooker Customer app celom svetu! 🙂
Toliko od mene do sledećeg podviga. 🙂