Како функционише рад на систему FoodSoul: од идеје до резултата

Cenimo poverenje naših partnera i zato želimo da budemo maksimalno transparentni. U ovom članku ćemo ispričati kako je organizovan tim, kako se ideje pretvaraju u funkcionalnost, kako postavljamo prioritete i šta se dešava iza kulisa kada nešto pođe po zlu.

FoodSoul — živi sistem

FoodSoul nije samo aplikacija. Iza nje stoji velika infrastruktura: CRM, skladištenje i zaštita podataka, šabloni sajtova i mobilnih aplikacija i hiljade restorana-partnera, svaki sa svojim potrebama i radnim scenarijima.

Stalno slušamo: prikupljamo ideje od partnera putem tehničke podrške, iz direktne komunikacije sa klijentima i od sopstvenih analitičara IT-odseka. Sve to se akumulira u beklog — stalno ažuriranu listu zadataka, na osnovu koje se formira mapa puta za razvoj proizvoda.

Kako je organizovan tim i struktura rada

Na FoodSoul-u radi nekoliko grupa stručnjaka, i svaka od njih ima svoj deo odgovornosti i svoju logiku interakcije sa ostalima.

Tehnička podrška — prva linija kontakta sa partnerima. Ona prima zahteve, razume suštinu problema i ili ga rešava na licu mesta, ili prosleđuje dalje stručnjaku koji poznaje odgovarajući deo sistema.

Stručnjaci druge linije — to su inženjeri koji duboko poznaju određene module: integracije, mobilne aplikacije, CRM, plaćanja. Upravo oni proveravaju da li je zahtev karakteristika funkcionisanja ili prava greška.

Analitičari prikupljaju i strukturiraju želje partnera, procenjuju koliko je izmena tražena i kako će uticati na druge klijente, pre nego što zadatak ode u razvoj.

Programeri i testeri realizuju zadatke i proveravaju ih pre objave — od manjih ispravki do velikih unapređenja funkcionalnosti.

Projektni menadžeri drže prioritete u fokusu: prate beklog, raspoređuju zadatke među timovima i odgovorni su da važno ne bude izgubljeno među tekućim zadacima.

Rad je organizovan ciklično: tim redovno preispituje beklog, procenjuje nove zahteve i želje, planira naredne zadatke i prati status onih koji su već u radu. Ovakav ritam omogućava da se ne izgube iz vida ni hitni problemi, ni dugoročni razvoj proizvoda, a pritom se zadržava predvidljivost: partner uvek može saznati preko tehničke podrške u kojoj je fazi njegov zahtev.

Kako postavljamo prioritete

Kada se pojavi problem, postupamo po jednom od scenarija.

Masovni kvar — greška sa kojom se u toku dana ili nekoliko sati susrelo više klijenata istovremeno. To je najviši prioritet: tester i programeri se odmah uključuju.

Kritičan bag kod jednog klijenta — ako greška direktno utiče na prihod ili reputaciju partnera, prioritet je takođe visok. Uključujemo ključne resurse i rešavamo problem u najkraćem roku.

Standardni bag — zahtev koji je primila tehnička podrška, a ne izgleda kao katastrofa. Njega preuzima stručnjak druge linije koji dobro poznaje sistem. Moguća su dva ishoda: ili se ispostavi da je to karakteristika funkcionisanja koju nismo uzeli u obzir, tada se klijentu objašnjava rešenje; ili problem zaista postoji, tada odlazi projektnom menadžeru, beleži se u sistemu zadataka sa prioritetom i odgovornim i realizuje se po redu. Stručnjak tehničke podrške prati status i obaveštava klijenta kada je zadatak završen.

Manji bag — greška koja ne utiče na rad sistema, ali zahteva ispravku: tipografska greška, pomeren element interfejsa, pogrešna boja dugmeta. Takvi zadaci se preuzimaju kada nema prioritetnijih zahteva iz prethodnih tačaka.

Želje — pažljivo pratimo šta partneri traže. Kada isti zahtev stigne od više klijenata, prioritet raste i uzimamo ga u analizu. Svaka izmena utiče na sve partnere odjednom, a ne samo na onog ko je tražio, zato pre realizacije prikupljamo povratne informacije od različitih klijenata, kako bi unapređenje za jedne ne stvorilo neugodnosti za druge. To je dodatni korak, ali upravo on čini konačno rešenje promišljenijim.

Zašto nastaju bagovi

Razvoj svakog složenog proizvoda je takav da su greške redovan deo procesa, a ne izuzetak. Evo od čega se sastoji ta složenost.

Sistem raste. Što je više funkcija, integracija i scenarija korišćenja, to je više tačaka gde različiti delovi sistema međusobno deluju. Tim testira najtipičnije scenarije, ali je fizički nemoguće unapred pokriti sve kombinacije čak i za najiskusniji tim.

Svaki partner koristi sistem na svoj način. Hiljade objekata — to su hiljade jedinstvenih radnih procesa. Ponašanje korisnika u realnim uslovima je uvek bogatije nego što se može predvideti u testnim scenarijima, i deo odstupanja se pojavljuje tek na stvarnim podacima.

Jedna izmena utiče na drugu. Kada programer unapredi jedan modul, to može uticati na povezanu funkcionalnost. Što je sistem veći, to su duži lanci zavisnosti između njegovih delova i to pažljivije treba proveravati svaku izmenu.

Okruženje se stalno menja. Ažuriraju se pretraživači, operativni sistemi, eksterni servisi sa kojima smo integrisani. Ono što je radilo juče, može se ponašati drugačije nakon ažuriranja na strani treće kompanije, i mi pratimo takve promene kako bismo brzo reagovali.

Zahtevi se preciziraju u procesu. Ponekad je funkcija realizovana baš onako kako je zamišljeno, ali se u realnoj upotrebi ispostavi da ideju treba doraditi. Tako proizvod postaje precizniji sa svakom iteracijom.

Na to gledamo kao na normalan deo rasta složenog sistema i stalno radimo na tome da on postane stabilniji, brži i udobniji za svakog partnera — kroz dublje testiranje, jasnu strukturu tima i stalnu povratnu vezu sa klijentima.

Ako ste naišli na problem ili želite da podelite ideju, pišite tehničkoj podršci FoodSoul. Svaki zahtev dolazi do pravog stručnjaka i ne gubi se. Tu smo za vas!

S poštovanjem,

Project Manager FoodSoul