Kā norit darbs pie FoodSoul sistēmas: no idejas līdz rezultātam

Mēs augstu vērtējam mūsu partneru uzticību un tāpēc vēlamies būt maksimāli caurspīdīgi. Šajā rakstā pastāstīsim, kā ir organizēta komanda, kā idejas pārtop funkcionalitātē, kā mēs nosakām prioritātes un kas notiek aizkulisēs, kad kaut kas noiet greizi.

FoodSoul — tā ir dzīva sistēma

FoodSoul nav tikai lietotne. Aiz tās stāv liela infrastruktūra: CRM, datu glabāšana un aizsardzība, mājaslapu un mobilo lietotņu veidnes un tūkstošiem restorānu partneru, katrs ar savām vajadzībām un darba scenārijiem.

Mēs pastāvīgi klausāmies: vācām idejas no partneriem caur tehnisko atbalstu, tiešā saziņā ar klientiem un no mūsu IT nodaļas analītiķiem. Tas viss tiek apkopots backlogā — pastāvīgi atjaunināmā uzdevumu sarakstā, uz kura pamata tiek veidota produkta attīstības ceļa karte.

Kā ir organizēta komanda un darba struktūra

Pie FoodSoul strādā vairākas speciālistu grupas, un katrai no tām ir sava atbildības joma un sava mijiedarbības loģika ar pārējām.

Tehniskais atbalsts — pirmā saskarsmes līnija ar partneriem. Tā pieņem pieteikumus, izprot problēmas būtību un vai nu atrisina to uz vietas, vai nodod tālāk speciālistam, kurš pārzina attiecīgo sistēmas daļu.

Otrās līnijas speciālisti — tie ir inženieri, kuri dziļi pārzina konkrētus moduļus: integrācijas, mobilās lietotnes, CRM, maksājumus. Tieši viņi pārbauda, vai pieteikums ir funkcionalitātes īpatnība vai reāla kļūda.

Analītiķi apkopo un strukturē partneru vēlmes, novērtē, cik ļoti izmaiņas ir pieprasītas un kā tās ietekmēs citus klientus, pirms uzdevums nonāk izstrādē.

Izstrādātāji un testētāji realizē uzdevumus un pārbauda tos pirms izlaišanas — no nelielām izmaiņām līdz lielām funkcionalitātes uzlabojumiem.

Projektu vadītāji fokusējas uz prioritātēm: uzrauga backlogu, sadala uzdevumus starp komandām un atbild par to, lai svarīgais nepazustu starp tekošajiem uzdevumiem.

Darbs ir organizēts cikliski: komanda regulāri pārskata backlogu, izvērtē jaunus pieteikumus un vēlmes, plāno tuvākos uzdevumus un seko līdzi jau uzsākto darbu statusam. Šāds ritms ļauj nepazaudēt ne steidzamas problēmas, ne ilgtermiņa produkta attīstību un vienlaikus saglabāt prognozējamību: partneris vienmēr var uzzināt caur tehnisko atbalstu, kādā posmā atrodas viņa pieteikums.

Kā mēs nosakām prioritātes

Kad rodas problēma, mēs rīkojamies pēc viena no scenārijiem.

Masveida kļūme — kļūda, ar kuru dienas vai dažu stundu laikā vienlaikus saskārušies vairāki klienti. Tā ir augstākā prioritāte: testētājs un izstrādātāji pieslēdzas nekavējoties.

Kritiska kļūda vienam klientam — ja kļūda tieši ietekmē partnera ieņēmumus vai reputāciju, prioritāte ir tikpat augsta. Mēs piesaistām galvenos resursus un atrisinām problēmu īsā laikā.

Standarta kļūda — pieteikums, ko pieņēmis tehniskais atbalsts, kas neizskatās pēc katastrofas. To apstrādā otrās līnijas speciālists, kurš labi pārzina sistēmu. Iespējami divi iznākumi: vai nu izrādās, ka tā ir funkcionalitātes īpatnība, kas nav ņemta vērā, tad klientam izskaidro risinājumu; vai arī problēma tiešām pastāv, tad tā nonāk pie projektu vadītāja, tiek fiksēta uzdevumu sistēmā ar prioritāti un atbildīgo un tiek realizēta rindas kārtībā. Tehniskā atbalsta speciālists seko līdzi statusam un informē klientu, kad uzdevums ir izpildīts.

Neliela kļūda — kļūda, kas neietekmē sistēmas darbu, bet prasa labojumu: drukas kļūda, nobīdīts interfeisa elements, nepareiza pogas krāsa. Šādi uzdevumi tiek ņemti darbā, kad nav augstākas prioritātes pieteikumu no iepriekšējiem punktiem.

Vēlmes — mēs rūpīgi sekojam līdzi tam, ko lūdz partneri. Kad viena un tā pati vēlme tiek saņemta no vairākiem klientiem, prioritāte pieaug, un mēs to nododam analīzei. Jebkuras izmaiņas ietekmē visus partnerus uzreiz, ne tikai to, kurš lūdza, tāpēc pirms realizācijas mēs apkopojam atgriezenisko saiti no dažādiem klientiem, lai uzlabojums vieniem neradītu neērtības citiem. Tas ir papildu solis, bet tieši tas padara gala lēmumu pārdomātāku.

Kāpēc rodas kļūdas

Jebkura sarežģīta produkta izstrāde ir tāda, ka kļūdas ir regulāra procesa daļa, nevis izņēmums. Lūk, no kā veidojas šī sarežģītība.

Sistēma aug. Jo vairāk funkciju, integrāciju un lietošanas scenāriju, jo vairāk punktu, kur dažādas sistēmas daļas mijiedarbojas savā starpā. Komanda testē tipiskākos scenārijus, bet pilnībā aptvert visas kombinācijas iepriekš fiziski nav iespējams pat vispieredzējušākajai komandai.

Katrs partneris izmanto sistēmu savā veidā. Tūkstošiem iestāžu — tās ir tūkstošiem unikālu darba procesu. Lietotāju uzvedība reālos apstākļos vienmēr ir bagātāka, nekā var paredzēt testēšanas scenārijos, un daļa noviržu parādās tikai uz dzīviem datiem.

Viena izmaiņa ietekmē citu. Kad izstrādātājs uzlabo vienu moduli, tas var ietekmēt blakus funkcionalitāti. Jo lielāka sistēma, jo garākas atkarību ķēdes starp tās daļām, un jo rūpīgāk jāizvērtē katra izmaiņa.

Vide pastāvīgi mainās. Tiek atjaunināti pārlūki, operētājsistēmas, trešo pušu servisi, ar kuriem mēs esam integrēti. Tas, kas strādāja vakar, var uzvesties citādi pēc atjauninājuma trešās puses pusē, un mēs sekojam šādām izmaiņām, lai reaģētu ātri.

Prasības precizējas procesā. Dažreiz funkcija ir realizēta tieši tā, kā bija iecerēts, bet reālajā lietošanā izrādās, ka ieceri vajadzētu uzlabot. Tā produkts kļūst precīzāks ar katru iterāciju.

Mēs to uztveram kā normālu sarežģītas sistēmas izaugsmes daļu un pastāvīgi strādājam pie tā, lai tā kļūtu stabilāka, ātrāka un ērtāka katram partnerim — pateicoties dziļākai testēšanai, skaidrai komandas struktūrai un pastāvīgai atgriezeniskajai saitei ar klientiem.

Ja esat saskāries ar problēmu vai vēlaties dalīties ar ideju, rakstiet tehniskajam atbalstam FoodSoul. Katrs pieteikums nonāk pie attiecīgā speciālista un nepazūd. Mēs esam blakus!

Ar cieņu,

Project Manager FoodSoul