Kuidas toimub töö FoodSoul süsteemiga: ideest tulemuseni

Hindame oma partnerite usaldust ja soovime seetõttu olla võimalikult läbipaistvad. Selles artiklis räägime, kuidas on üles ehitatud meie meeskond, kuidas ideed muutuvad funktsionaalsuseks, kuidas me seame prioriteete ning mis toimub kulisside taga, kui midagi läheb valesti.

FoodSoul — see on elav süsteem

FoodSoul ei ole lihtsalt rakendus. Selle taga on suur infrastruktuur: CRM, andmete säilitamine ja kaitse, veebilehtede ja mobiilirakenduste mallid ning tuhanded partnerrestoranid, millest igaühel on oma vajadused ja tööstsenaariumid.

Kuulame pidevalt: kogume ideid partneritelt tugiteenuse kaudu, otsesuhtlusest klientidega ning oma IT-osakonna analüütikutelt. Kõik see koondub backlog’i — pidevalt uuenevasse ülesannete nimekirja, mille põhjal kujuneb toote arenguteekaart.

Kuidas on üles ehitatud meeskond ja tööstruktuur

FoodSouli kallal töötab mitu spetsialistide gruppi, kellest igaühel on oma vastutusala ja loogika koostööks teistega.

Tugiteenus — esimene kontaktliin partneritega. See võtab vastu pöördumised, selgitab välja probleemi olemuse ning kas lahendab selle kohapeal või suunab edasi spetsialistile, kes tunneb vastavat süsteemi osa.

Teise liini spetsialistid — need on insenerid, kes tunnevad põhjalikult konkreetseid mooduleid: integratsioone, mobiilirakendusi, CRM-i, makseid. Just nemad kontrollivad, kas pöördumine on funktsionaalsuse eripära või tegelik viga.

Analüütikud koguvad ja struktureerivad partnerite soove, hindavad, kui vajalik on muudatus ja kuidas see mõjutab teisi kliente, enne kui ülesanne jõuab arendusse.

Arendajad ja testijad viivad ülesanded ellu ja kontrollivad neid enne väljalaset — alates väikestest parandustest kuni suurte funktsionaalsuse täiendusteni.

Projektijuhid hoiavad fookuses prioriteedid: jälgivad backlog’i, jagavad ülesandeid meeskondade vahel ja vastutavad selle eest, et oluline ei kaoks igapäevaste ülesannete hulka.

Töö on üles ehitatud tsükliliselt: meeskond vaatab regulaarselt üle backlog’i, hindab uusi pöördumisi ja soove, planeerib lähiaja ülesandeid ning jälgib juba töös olevate ülesannete staatust. Selline rütm võimaldab mitte kaotada silmist ei kiireloomulisi probleeme ega pikaajalist toote arendust ning säilitada ennustatavuse: partner saab alati tugiteenusest teada, millises etapis tema pöördumine on.

Kuidas me seame prioriteete

Kui tekib probleem, tegutseme ühe järgmise stsenaariumi järgi.

Massiline tõrge — viga, millega on päeva või mõne tunni jooksul samaaegselt kokku puutunud mitu klienti. See on kõrgeim prioriteet: testija ja arendajad asuvad kohe tööle.

Kriitiline viga ühel kliendil — kui viga mõjutab otseselt partneri käivet või mainet, on prioriteet sama kõrge. Paneme võtmeressursid tööle ja lahendame probleemi lühikese ajaga.

Tavaline viga — tugiteenuse poolt vastu võetud pöördumine, mis ei tundu katastroofina. Selle võtab käsile teise liini spetsialist, kes tunneb süsteemi hästi. Võimalikud kaks tulemust: kas selgub, et see on funktsionaalsuse eripära, mida ei arvestatud, siis selgitatakse kliendile lahendus; või probleem on tõesti olemas, siis jõuab see projektijuhini, fikseeritakse ülesannete süsteemis koos prioriteedi ja vastutajaga ning viiakse ellu järjekorras. Tugiteenuse spetsialist jälgib staatust ja annab kliendile teada, kui ülesanne on täidetud.

Väike viga — viga, mis ei mõjuta süsteemi tööd, kuid vajab parandamist: kirjaviga, nihkunud liideselement, vale nupu värv. Sellised ülesanded võetakse töösse, kui kõrgema prioriteediga pöördumisi pole.

Soovid — jälgime hoolikalt, mida partnerid soovivad. Kui sama soov tuleb mitmelt kliendilt, kasvab selle prioriteet ja võtame selle analüüsi alla. Iga muudatus mõjutab kõiki partnereid korraga, mitte ainult seda, kes soovi esitas, seetõttu kogume enne teostust tagasisidet erinevatelt klientidelt, et ühe jaoks tehtud parandus ei tekitaks ebamugavusi teistele. See on lisasamm, kuid just see muudab lõpliku otsuse läbimõeldumaks.

Miks tekivad vead

Iga keeruka toote arendus on üles ehitatud nii, et vead on protsessi regulaarne osa, mitte erand. Siin on, millest see keerukus koosneb.

Süsteem kasvab. Mida rohkem on funktsioone, integratsioone ja kasutusstsenaariume, seda rohkem on punkte, kus süsteemi erinevad osad omavahel suhtlevad. Meeskond testib kõige tüüpilisemaid stsenaariume, kuid kõiki kombinatsioone pole füüsiliselt võimalik ette näha isegi kõige kogenumal meeskonnal.

Iga partner kasutab süsteemi omal moel. Tuhanded asutused — see on tuhat unikaalset tööprotsessi. Kasutajate käitumine pärisolukorras on alati rikkalikum, kui teststsenaariumides ette näha saab, ning osa kõrvalekalletest ilmneb alles reaalsete andmete peal.

Üks muudatus mõjutab teist. Kui arendaja täiustab üht moodulit, võib see mõjutada ka seotud funktsionaalsust. Mida suurem süsteem, seda pikemad on sõltuvusahelad selle osade vahel ning seda hoolikamalt tuleb iga muudatust kontrollida.

Keskkond muutub pidevalt. Uuenevad brauserid, operatsioonisüsteemid, kolmandate osapoolte teenused, millega oleme integreeritud. See, mis töötas eile, võib pärast kolmanda ettevõtte uuendust käituda teisiti, ning me jälgime selliseid muudatusi, et kiiresti reageerida.

Nõuded täpsustuvad protsessi käigus. Mõnikord on funktsioon realiseeritud täpselt nii, nagu oli mõeldud, kuid tegelikus kasutuses selgub, et ideed tuleb täiendada. Nii muutub toode iga iteratsiooniga täpsemaks.

Võtame seda kui keeruka süsteemi kasvu loomulikku osa ja töötame pidevalt selle nimel, et see muutuks iga partneri jaoks stabiilsemaks, kiiremaks ja mugavamaks — tänu põhjalikumale testimisele, selgele meeskonnastruktuurile ja pidevale tagasisidele klientidelt.

Kui teil tekib probleem või soovite jagada ideed, kirjutage FoodSouli tugiteenusele. Iga pöördumine jõuab õige spetsialistini ega lähe kaduma. Oleme teie kõrval!

Lugupidamisega,

FoodSoul projektijuht