Kaip organizuojamas darbas su FoodSoul sistema: nuo idėjos iki rezultato

Mes vertiname savo partnerių pasitikėjimą, todėl siekiame būti kuo atviresni. Šiame straipsnyje papasakosime, kaip organizuota komanda, kaip idėjos virsta funkcionalumu, kaip nustatome prioritetus ir kas vyksta užkulisiuose, kai kas nors vyksta ne taip.

FoodSoul — tai gyva sistema

FoodSoul — tai ne tik programėlė. Už jos slypi didelė infrastruktūra: CRM, duomenų saugojimas ir apsauga, svetainių ir mobiliųjų programėlių šablonai bei tūkstančiai restoranų-partnerių, kiekvienas su savo poreikiais ir darbo scenarijais.

Mes nuolat klausomės: renkame idėjas iš partnerių per techninę pagalbą, tiesioginį bendravimą su klientais ir iš savo IT skyriaus analitikų. Visa tai kaupiama į „backlog“ – nuolat atnaujinamą užduočių sąrašą, pagal kurį formuojama produkto vystymo kelio žemėlapis.

Kaip organizuota komanda ir darbo struktūra

Prie FoodSoul dirba kelios specialistų grupės, ir kiekviena jų turi savo atsakomybės sritį bei sąveikos su kitais logiką.

Techninė pagalba – pirmoji kontaktų linija su partneriais. Ji priima užklausas, aiškinasi problemos esmę ir arba išsprendžia ją vietoje, arba perduoda toliau specialistui, kuris geriausiai išmano reikiamą sistemos dalį.

Antrosios linijos specialistai – tai inžinieriai, kurie giliai išmano konkrečius modulius: integracijas, mobiliąsias programėles, CRM, mokėjimus. Būtent jie tikrina, ar užklausa yra funkcionalumo ypatybė, ar tikra klaida.

Analitikai renka ir struktūruoja partnerių pageidavimus, vertina, kiek pokytis yra reikalingas ir kaip jis paveiks kitus klientus, prieš užduočiai patenkant į kūrimą.

Kūrėjai ir testuotojai įgyvendina užduotis ir tikrina jas prieš išleidžiant – nuo nedidelių pataisymų iki didelių funkcionalumo patobulinimų.

Projektų vadovai stebi prioritetus: prižiūri „backlog“, paskirsto užduotis tarp komandų ir atsako už tai, kad svarbūs klausimai neprapultų tarp einamųjų darbų.

Darbas organizuotas cikliškai: komanda reguliariai peržiūri „backlog“, vertina naujas užklausas ir pageidavimus, planuoja artimiausias užduotis ir stebi jau pradėtų darbų būklę. Toks ritmas leidžia nepraleisti nei skubių problemų, nei ilgalaikio produkto vystymo, ir kartu išlaikyti nuspėjamumą: partneris visada gali sužinoti per techninę pagalbą, kuriame etape yra jo užklausa.

Kaip nustatome prioritetus

Kai iškyla problema, veikiame pagal vieną iš scenarijų.

Mastinis sutrikimas – klaida, su kuria per dieną ar kelias valandas susiduria keli klientai vienu metu. Tai aukščiausias prioritetas: testuotojas ir kūrėjai įsitraukia nedelsiant.

Kritinė klaida pas vieną klientą – jei klaida tiesiogiai veikia partnerio pajamas ar reputaciją, prioritetas toks pat aukštas. Skiriame pagrindinius resursus ir sprendžiame problemą per trumpą laiką.

Standartinė klaida – techninės pagalbos priimta užklausa, kuri neatrodo kaip katastrofa. Ją apdoroja antrosios linijos specialistas, gerai išmanantis sistemą. Galimi du variantai: arba paaiškėja, kad tai funkcionalumo ypatybė, kurios nebuvo numatyta, tuomet klientui paaiškinamas sprendimas; arba problema tikrai egzistuoja, tuomet ji perduodama projektų vadovui, fiksuojama užduočių sistemoje su prioritetu ir atsakingu asmeniu ir įgyvendinama pagal eilę. Techninės pagalbos specialistas stebi būklę ir informuoja klientą, kai užduotis įvykdyta.

Nedidelė klaida – klaida, kuri nedaro įtakos sistemos veikimui, bet reikalauja pataisymo: rašybos klaida, pasislinkęs sąsajos elementas, neteisinga mygtuko spalva. Tokios užduotys imamos, kai nėra aukštesnio prioriteto užklausų iš ankstesnių punktų.

Pageidavimai – atidžiai stebime, ko prašo partneriai. Kai ta pati užklausa gaunama iš kelių klientų, prioritetas auga ir imamės jos analizei. Bet koks pakeitimas iš karto paliečia visus partnerius, o ne tik tą, kuris paprašė, todėl prieš įgyvendinant renkame grįžtamąjį ryšį iš skirtingų klientų, kad patobulinimas vieniems nesukeltų nepatogumų kitiems. Tai papildomas žingsnis, bet būtent jis leidžia priimti labiau apgalvotą sprendimą.

Kodėl atsiranda klaidų

Bet kokio sudėtingo produkto kūrimas yra toks, kad klaidos – tai nuolatinė proceso dalis, o ne išimtis. Štai iš ko susideda šis sudėtingumas.

Sistema auga. Kuo daugiau funkcijų, integracijų ir naudojimo scenarijų, tuo daugiau taškų, kur sistemos dalys sąveikauja tarpusavyje. Komanda testuoja dažniausiai pasitaikančius scenarijus, bet visiškai apimti visas kombinacijas iš anksto fiziškai neįmanoma net pačiai patyrusiai komandai.

Kiekvienas partneris naudoja sistemą savaip. Tūkstančiai įstaigų – tai tūkstančiai unikalių darbo procesų. Vartotojų elgsena realiomis sąlygomis visada yra platesnė, nei galima numatyti testavimo scenarijuose, ir dalis nukrypimų pasireiškia tik su gyvais duomenimis.

Vienas pakeitimas veikia kitą. Kai kūrėjas patobulina vieną modulį, tai gali paveikti gretimą funkcionalumą. Kuo didesnė sistema, tuo ilgesnės priklausomybių grandinės tarp jos dalių, ir tuo atidžiau reikia tikrinti kiekvieną pakeitimą.

Aplinka nuolat keičiasi. Atnaujinamos naršyklės, operacinės sistemos, trečiųjų šalių paslaugos, su kuriomis esame integruoti. Tai, kas veikė vakar, gali elgtis kitaip po atnaujinimo kitoje įmonėje, ir mes stebime tokius pokyčius, kad galėtume greitai reaguoti.

Reikalavimai tikslinami procese. Kartais funkcija įgyvendinama būtent taip, kaip buvo sumanyta, bet realiame naudojime paaiškėja, kad idėją verta patobulinti. Taip produktas su kiekviena iteracija tampa tikslesnis.

Mes žiūrime į tai kaip į natūralią sudėtingos sistemos augimo dalį ir nuolat dirbame, kad ji taptų stabilesnė, greitesnė ir patogesnė kiekvienam partneriui – gilindami testavimą, aiškiai struktūruodami komandą ir nuolat palaikydami ryšį su klientais.

Jei susidūrėte su problema arba norite pasidalinti idėja, parašykite į techninę pagalbą FoodSoul. Kiekviena užklausa pasiekia reikiamą specialistą ir neprapuola. Mes šalia!

Pagarbiai,

FoodSoul projektų vadovas